Diagnosing Trello Webhook Callbacks That Stop, Lag, or Duplicate

A Trello board integration that previously delivered card and member events in near real time can fail in three distinct patterns: callbacks stop arriving, arrive late in bursts, or repeat the same payload. Manual API reads still succeeding means the board, token, and network path are healthy, so the fault sits in webhook registration, endpoint responsiveness, or receiver idempotency. The fastest path to resolution is to check those layers in order rather than guessing.

Recognizable condition

Use the symptom to narrow the layer before running commands.

Symptom	Likely cause	First diagnostic
No callbacks for new actions	Webhook marked inactive, or idModel points to the wrong object	Fetch the webhook and inspect active and idModel
Callbacks arrive minutes late, in batches	Endpoint is slow to return 200, so Trello retries and backs off	Time a HEAD/GET request to callbackURL
Identical action payload delivered 2+ times	Retry after a transient failure; receiver lacks deduplication	Search receiver logs for duplicate action.id values
Only some event types arrive	Token scope or trigger model is narrower than expected	Compare token permissions and model against the actions you need

Ordered checks

1. Fetch the webhook object

Run this from a server or admin workstation, not from browser code, because it requires your API token.

curl -s "https://api.trello.com/1/webhooks/{webhookId}?key={apiKey}&token={apiToken}"

Expected check: the response contains "active": true, an idModel equal to the board ID you intend to monitor, and a callbackURL that exactly matches your public HTTPS endpoint. If active is false or the model is wrong, delivery will not start. Risk: the token appears in shell history; prefer environment variables.

2. Probe the callback endpoint

Trello expects a fast success response. Measure both status and latency:

curl -o /dev/null -s -w "%{http_code} %{time_total}" -X HEAD "{callbackUrl}"

Expected check: HTTP 200 returned in well under a second. A timeout, connection refusal, or 5xx status explains inactivity and late batches. If your host blocks HEAD, repeat with GET. Risk: probing with real payloads can trigger side effects; use a lightweight health path.

3. Match the trigger model and token scope

Confirm the token used at registration still has read access to the target board and that idModel is the board ID—not a list or card—unless you deliberately subscribed to that narrower model. A token that lost board access produces silent non-delivery.

4. Audit receiver logs

Look for timeouts, 500 responses, and repeated action.id values. Duplicate IDs confirm that Trello retried and your application processed the same event twice.

Fixes tied to findings

Inactive or mismatched webhook: delete and re-register

When the object shows active=false or the wrong model, remove it and create a fresh webhook with the exact callback URL and board ID.

curl -X DELETE "https://api.trello.com/1/webhooks/{webhookId}?key={apiKey}&token={apiToken}"

curl -X POST "https://api.trello.com/1/webhooks/?key={apiKey}&token={apiToken}" -d "callbackURL={callbackUrl}" -d "idModel={boardId}"

Expected check: the POST returns a webhook object with active=true. Risk: events that occurred between failure and re-registration are not replayed; backfill them immediately using the actions endpoint described below.

Slow endpoint: acknowledge before processing

Long synchronous work inside the callback is a common cause of missed deliveries. Return 200 as soon as the payload is received, then hand the work to a background queue. For example, in a Node/Express receiver the pattern is:

app.post('/trello-webhook', (req, res) => {
  res.sendStatus(200);
  queue.add('process-action', req.body);
});

This is an illustrative pattern, not tested output. The key decision is that no database write, external API call, or heavy computation sits between receiving the request and sending 200.

Duplicate payloads: deduplicate on action id

Every Trello action carries a stable id. Persist a processed-set of these IDs and skip any payload whose ID is already present. A short-TTL cache works if your replay window is small; a durable store is safer if duplicates can arrive after a restart.

Recovering missed events

Trello does not guarantee replay of every dropped callback, so the webhook stream is not a complete audit log. Reconcile gaps by polling the board actions endpoint with a stored cursor:

curl "https://api.trello.com/1/boards/{boardId}/actions?key={apiKey}&token={apiToken}&since={lastProcessedDate}&before={currentDate}"

Store lastProcessedDate as an ISO 8601 timestamp or the date of the newest action you have handled. Compare the returned actions against your webhook log to find and process anything missed.

When to escalate to Atlassian support

• A webhook shows active=true, your endpoint returns a fast 200, yet events are dropped across multiple boards.
• Registration itself returns errors despite a valid key, token, and model.
• Observed behavior contradicts the current published Trello API reference.

Include the webhook ID, board ID, approximate timestamps, and redacted sample payloads so support can trace delivery.

Verifying the repair

1. Create a test board and register a webhook to a local tunnel. Perform one known card action and confirm exactly one callback arrives.
2. Stop the receiver, generate several actions, restart it, then confirm the actions endpoint backfill matches what the webhook missed.
3. Replay the same captured payload twice and assert your downstream system records it only once.

Limitations

• Webhook semantics, callback timeout, and retry policy are version-sensitive; confirm current values against the live Trello API reference before coding around them.
• Treat callbackURL as a security-sensitive endpoint: validate payload structure and never expose the webhook token in client-side code or logs.
• Because replay is not guaranteed, polling remains necessary for correctness even when webhooks appear healthy.