How do you retry a webhook?
Retrying a webhook means automatically re-attempting a delivery when the destination rejects it or fails to respond — with backoff, per-destination isolation, and a terminal failure surface so nothing dies silently. Slashbin runs retries for every destination automatically, so your API handler never has to.
Retry vs replay — the distinction
Retry is automatic redelivery after a failure. Slashbin owns the schedule: when a destination returns a retryable error or times out, the gateway backs off and tries again on its own, per destination, until the delivery succeeds or the attempt budget is exhausted.
Replay is manual re-processing of history. You pick a window — an event, a time range, an entire source — and Slashbin re-delivers those stored payloads through your latest transform. See Replay & Retry for the full replay surface.
Webhook retry logic — what good retries require
- Backoff, not tight loops. Immediate retries pile onto a struggling destination and turn a blip into an outage. The retry schedule spaces attempts out so a slow endpoint gets room to recover.
- Per-destination circuit breaking. When one destination starts failing consistently, retries to that destination pause without touching the others. A downed CRM never blocks deliveries to your warehouse.
- Idempotent, no duplicate sends. The gateway acks with the destination before marking a delivery successful. If a retry races an in-flight ack, the state model makes duplicate delivery impossible for the same delivery attempt.
- Terminal failures are visible. When retries exhaust, the delivery lands in a dead-letter queue you can see and act on — never a swallowed error in a log line no one reads.
Webhook retry after failure — what happens when the endpoint comes back
When a destination recovers, its backlog drains in order. Deliveries queued during the outage go out first, in event-timestamp order, so downstream state moves forward without seeing yesterday overwrite today. If any deliveries landed in the DLQ during the outage, you can replay them explicitly — they re-run through the current transform, exactly as the vendor originally sent them.
Because retry is per destination, one destination's recovery doesn't wait for another. Analytics can catch up while your fulfillment DLQ is still being triaged.
Why hand-rolling retries in your API is a trap
| Approach | What breaks |
|---|---|
| Retry in the webhook handler | The vendor's own timeout fires first. The sender gives up, you retry, and the vendor sends the same webhook again — now you have two in-flight attempts and no way to reconcile them. |
| A cron job that re-sends from a table | You now own a delivery table, a scheduler, a backoff policy, a DLQ surface, and a runbook — plus every destination has to be added to it by hand. |
| Ask the vendor to resend | Not every vendor supports it; those that do rate-limit, batch, or omit events you already acknowledged. |
| Retry in Slashbin | The stored payload, the destination state, and the backoff schedule are already there. Failures retry themselves; terminal failures go to a DLQ you can see. |
Feature detail
Per-Destination Backoff
Each destination retries on its own schedule — one slow endpoint never delays another.
Circuit Breaking
A destination that fails consistently pauses without affecting deliveries to any other destination.
DLQ on Terminal Failure
Exhausted retries land in a dead-letter queue with the original payload and full attempt history — self-service replay when the endpoint recovers.
No Duplicate Sends
Retries never race in-flight acknowledgements — a successful delivery is not retried, and a retry does not create a second in-flight attempt.
Worked example
Learn how retry and replay work together.
View Setup Guides