Retries & Delivery
Delivery guarantees
- At-least-once. Network blips and brief outages can produce duplicate deliveries — dedupe by
event.id. - Ordered per resource. Events for the same card, user, or account are delivered in creation order.
- Timeouts. You have 10 seconds to respond
2xx. Longer responses are treated as failures and retried.
Retry schedule
Failed deliveries are retried with exponential backoff, up to 10 attempts across 3 days:
| Attempt | Delay |
|---|---|
| 1 | Immediate |
| 2 | 1 minute |
| 3 | 10 minutes |
| 4 | 1 hour |
| 5 | 3 hours |
| 6 | 6 hours |
| 7 | 12 hours |
| 8 | 24 hours |
| 9 | 48 hours |
| 10 | 72 hours |
After attempt 10 the endpoint is automatically disabled and an endpoint.failed event is emitted (to your other endpoints, if any).
What counts as failure
- Any non-
2xxstatus code. - Connection errors (DNS, TLS, connection refused).
- Responses that don’t complete within 10 seconds.
Replaying events manually
From the dashboard (or via POST /v1/webhooks/events/{event_id}/redeliver) you can re-send any historical event to a single endpoint.
Best practices
- Respond
200immediately after signature verification, then process in a background job. - Dedupe by
event.id(store in a short-lived set with TTL ≥ 24h). - Keep your endpoint idempotent — process the same event twice should leave your system in the same state.