Trello webhook not firing? Ask Trello what it sees first

Trello webhooks fail differently from most providers'. They are not registered to an app — each webhook belongs to the API token that created it, they run a reachability probe before the webhook even exists, and the signature covers your callback URL as well as the body. Each of those is a distinct way to end up staring at a handler that never runs. Here is the debugging order that resolves nearly every case.

Step 0: read the webhook object

Before touching your server, ask Trello for its side of the story. Every webhook object reports its own health:

curl "https://api.trello.com/1/tokens/{token}/webhooks?key={key}&token={token}"

[ { "id": "…", "description": "Sprint board sync",
    "idModel": "…", "callbackURL": "https://…",
    "active": true,
    "consecutiveFailures": 0,
    "firstConsecutiveFailDate": null } ]

Three outcomes, three different problems:

• Empty array → the webhook is gone (see cause 1 — token death — and cause 3 — the 410 rule).
• consecutiveFailures climbing → Trello is calling you and your endpoint is failing; skip to cause 4.
• Everything green → deliveries are happening but not reaching your handler — point the callbackURL at a capture bin (below) and watch what actually arrives.

Cause 1: the token died — and took the webhook with it

This is the #1 cause of “the webhook worked for months and then silently stopped”. A Trello webhook lives and dies with the token that created it: when that token is revoked (user deauthorizes the Power-Up/app, an admin rotates credentials) or expires, the webhook stops firing — silently. No error, no email, nothing to see on your server, and the webhook no longer appears under /1/tokens/{token}/webhooks.

Fix: mint a fresh token, recreate the webhook with it, and monitor. If your integration creates tokens with an expiry, put webhook recreation in the token-refresh path — not just the token.

Cause 2: it never existed — “400: URL not reachable”

Webhook creation runs a synchronous probe: Trello sends a plain HEAD request to your callbackURL and the creation call fails with 400: URL not reachable unless it gets a 200 back during the POST. Two common ways to fail it:

• Your route only answers POST. Many frameworks 404 or 405 a HEAD to a POST-only route. Add an explicit HEAD/GET handler that returns 200 on the exact callback path.
• Bad SSL. An invalid certificate fails creation too. (Plain HTTP is allowed, but HTTPS delivery is port-443 only.)

A capture bin answers HEAD with 200 out of the box, so creating the webhook against a bin URL always succeeds — useful to separate “my creation call is wrong” from “my endpoint is wrong”.

Cause 3: you returned 410 — Trello deleted the webhook

Responding 410 Gone to a delivery doesn't just fail it — Trello deletes the webhook outright. A misconfigured proxy, a framework that maps a missing route to 410, or a copy-pasted “gone” handler will permanently unhook you. If your webhook keeps vanishing shortly after creation, grep your edge logs for 410s before suspecting anything else.

Cause 4: failures — the (short) retry schedule and the (long) disable rule

• Retries: 3, at 30 s / 60 s / 120 s. After that the delivery is gone — Trello has no replay API and no dead-letter queue. If your endpoint was down for ten minutes, those events are simply lost; re-sync via the REST API.
• Auto-disable is nearly impossible to hit by accident: it takes both 30 days of consecutive failures and 1,000+ failed deliveries, and any single success resets the counter. So active: false almost always means something was broken for a full month — check firstConsecutiveFailDate for when it started, then fix the endpoint and recreate the webhook.

Deliveries arrive but verification fails? The URL is part of the signature

Trello signs every delivery with base64 HMAC-SHA1 over the raw body concatenated with the callbackURL, in the X-Trello-Webhook header, keyed by your application secret:

expected = base64( HMAC_SHA1( key = app_secret, message = raw_body + callbackURL ) )

Two traps follow directly from that construction:

• The URL must byte-match the callbackURL the webhook was created with. Verify against the registered string — not req.url after a proxy rewrote the host, stripped a query parameter, or changed the scheme.
• HMAC the raw bytes. Trello's own docs sample verifies JSON.stringify(req.body), which only matches while your JSON parser round-trips byte-identically (key order, unicode escapes, big numbers). Use the raw request body.

A Hookden bin can verify this scheme live — it knows its own URL, so selecting the Trello scheme in bin settings shows a ✓/✗ badge per delivery, something generic HMAC testers structurally can't do. There's also a client-side signature debugger with a Trello mode for offline checking.

Debugging flow with a bin

1. Create a bin (button below) and register a webhook against it:

   curl -X POST "https://api.trello.com/1/webhooks/?key={key}&token={token}" \
     -d "callbackURL=https://hookden.pages.dev/h/YOUR-BIN" \
     -d "idModel={board_id}" -d "description=debug"

   If this fails, the problem is your key/token/idModel — not your server.
2. Move a card. Within seconds the bin shows the full delivery — the action/model/webhook envelope, the X-Trello-Webhook header, exact bytes. (See a realistic sample payload.)
3. Replay the capture to your real endpoint with one click — byte-identical body, so once you verify against your bin's URL-adjusted signature logic, the same code works in production.

Also worth knowing: deliveries come only from 104.192.142.240/28 if you allowlist, and if your own code writes to Trello, pass X-Trello-Client-Identifier on API calls and skip actions that echo it back — otherwise your webhook handler and your API writes can loop.

Related: retry-schedule comparison across 26 providers, webhooks to localhost for developing the handler behind the bin, and the Trello payload example with a verifying signature.

← All guides · Signature debugger · Payload examples · Docs · Hookden vs webhook.site