Signed webhooks

A failing delivery is retried up to 5 times with increasing backoff before it's given up on

Lead delivery is a persistent queue, not a fire-and-forget fetch: each lead creates an attempt row that the worker claims, sends, and either settles or reschedules with backoff.

The lifecycle#

An attempt starts PENDING with maxAttempts: 5. A worker claims due rows (up to 10 per cycle) by atomically incrementing attemptCount, then POSTs the signed payload:

Any 2xx → SENT, deliveredAt set, lastError cleared. Done.
Failure (non-2xx, network error, blocked URL) → lastError recorded, and either rescheduled or dead-lettered:
after attempt 1 → wait 30 seconds
after attempt 2 → wait 2 minutes
after attempt 3 → wait 10 minutes
after attempt 4 → wait 30 minutes
after attempt 5 → DEAD_LETTER — terminal, no further tries.

The sequence is fixed at 30s, 2m, 10m, 30m; five total attempts span roughly 42 minutes of wall-clock time plus request durations.

Edges worth knowing#

If the connection or the lead disappears mid-flight, the attempt fails with CRM integration or lead no longer exists. and follows the same backoff path. Because deliveryId never changes across attempts, your receiver can safely answer 2xx to a duplicate without re-processing — see Verifying the signature. Dead-lettered attempts keep their lastError, which is the first place to look when events stop arriving.

Back to Signed webhooks