Retries, ordering and replay

Delivery is repeatable

A receiver can get the same event more than once, including after a timeout where its first response never reached Calberry. Persist event_id from the verified body and make each downstream effect idempotent. A replay is another delivery attempt, not a new business event.

Return 2xx after durable acceptance. Do not acknowledge a request you will lose on a process restart. If you enqueue work, monitor and retry that downstream queue separately: Calberry's delivered status ends at your HTTP acknowledgement.

Automatic retries

Failures and uncertain attempts use backoff. The code defaults to one initial attempt plus five retries, with delays starting at 30 seconds and doubling, capped at one hour. The request timeout defaults to ten seconds. These are configurable defaults, not a delivery-time SLA; the dashboard's next attempt is the useful operational value.

HTTPS destinations must be public and must not redirect. DNS failures, network errors, timeouts and non-success HTTP results appear in the history. Once automatic attempts are exhausted, the delivery reaches Dead-Letter.

Investigate and replay

1. Open Development → Webhooks → Delivery history.
2. Filter by endpoint and status, then open View attempts and payload.
3. Check the HTTP result, error and attempts. Verify the receiver URL, secret, availability and payload mapping.
4. Fix the cause and activate a paused endpoint if needed.
5. Choose Replay delivery. Check the new attempt and your destination's own execution log.

Replay keeps the original event_id and exact body, with a fresh signature timestamp. It can repeat an event already processed at the destination. Do not use replay as a way to bypass consent checks or create a second CRM activity.

Ordering guarantee

For the same endpoint and lead, booking.created waits for a recorded 2xx delivery of its selected lead.captured. Retry, backoff and dead letter do not release this dependency. A successful replay of that capture can release the waiting booking. The UI shows Waiting for lead.captured.

There is no capture dependency if the endpoint originally selected only booking events or if the capture preceded endpoint creation. Replays retain their original dependency; later filter changes do not recreate history. A later failed replay does not undo an earlier successful capture delivery.

There is no global ordering guarantee across events, leads or endpoints. The guarantee concerns starting the HTTP delivery after capture acceptance; it does not order parallel work inside your destination. Compare timestamps and store event history instead of assuming that the latest-arriving request is the latest state.

Pauses and gaps

There is no backfill for events before endpoint creation or while Pro access is paused. Use the API's documented list/delta operations for reconciliation if your application needs it. The event snapshot itself stays unchanged; use current booking reads for current state.