Webhook Retry Policy
The provider's schedule for re-attempting failed deliveries, and the contract the receiver must be built against.
Providers typically retry with exponential backoff over hours or days, giving at-least-once delivery. Three consequences for the receiver, and each is a source of production bugs:
Duplicates are normal. A successful delivery whose acknowledgement was lost will be retried, so handlers must be idempotent on the event ID.
Order is not guaranteed, and retries make it worse — a retried earlier event can arrive after a later one. Handlers should carry a timestamp or sequence number and ignore regressions.
Your downtime becomes their backlog, delivered in a burst on recovery. Accept fast, enqueue, process asynchronously — a slow handler causes timeouts, which the provider interprets as failure and retries, multiplying load exactly when you are struggling.
Return 2xx immediately on receipt and validate asynchronously; returning 4xx for a business-logic problem usually causes the provider to stop retrying and drop the event permanently.