How do you replay a webhook?
Replaying a webhook means re-delivering a stored payload — through your latest transform — without asking the sender to resend. Slashbin keeps every payload it receives for your plan's retention window — 3 days on Free, 7 on Lite, 30 on Pro — so the source of truth for a replay is the byte-for-byte event, not a reconstruction.
Replay vs retry — the distinction
Replay is manual re-processing of history — you pick what to re-run (one entity, a time range, a whole source) and Slashbin re-fires those stored payloads through your latest transform. Replaying a range or a whole source is a Lite and Pro feature.
Retry is automatic redelivery when a destination rejects or times out. It runs per destination on its own backoff, and attempts are bounded — when they run out, that delivery is permanently failed for that destination and shows in its delivery status. To send the event again you replay it, which re-runs it through the current model to every active destination and replaces the delivery records for that event. Replay needs the stored payload, so nothing outside your plan's retention window — 3 days on Free, 7 on Lite, 30 on Pro — can be replayed at all: past the window the stored webhook and its delivery records are gone and there is nothing to re-send. Replaying a range or a whole source is a Lite and Pro feature. On Free you can re-run one entity at a time, and only when your Golden Model flags a primary-key field — without one there is no entity to replay. See the Retry page for how the retry pipeline works.
How it works in Slashbin
- Select what to re-run. Pick one entity by its primary-key value, a time range, or every payload for a source — replaying a range or a whole source is a Lite and Pro feature.
- Replay through your latest transform. The stored raw payload is re-processed by whatever model is live now, not the one that ran when it first arrived.
- Every matched event, re-sent. Replay re-delivers each stored payload in the window — it does not skip one because a newer version already reached you, so keep your receiver tolerant of out-of-order versions.
When you need it
Endpoint downtime
Your API was down for an hour. On Lite and Pro, replay the missed window instead of asking the vendor to resend.
Model changed
You fixed a mapping bug. On Lite and Pro, replay yesterday's events through the corrected transform to heal the downstream state.
New destination backfill
Pointing a new consumer at an existing source. On Lite and Pro, replay historical payloads to seed it — no export scripts.
vs hand-rolled alternatives
| Approach | What breaks |
|---|---|
| Ask the vendor to resend | Not every vendor supports it; those that do rate-limit, batch, or omit events you already acknowledged. |
| DIY event table + re-send job | You now own storage, retries, ordering, and transform versioning — plus a new deploy every time the model changes. |
| Replay in Slashbin | The stored payload and the live transform are already there. Pick a window, replay — a Lite and Pro feature. |
Feature detail
Full Payload Fidelity
Every webhook is stored exactly as received — replay the original payload, not a reconstruction.
Destination Fault Isolation
Failed deliveries to one destination never affect others. Retry independently.
Failed Delivery Recovery
When attempts run out the delivery shows in its delivery status, and on Lite and Pro you re-send the event yourself with a replay, within your plan's retention window (3 days Free, 7 Lite, 30 Pro). Replaying a range or a whole source is a Lite and Pro feature; on Free, replay covers one entity at a time and needs a primary-key field flagged on your Golden Model.
Historical Backfill
Re-trigger historical events to seed new integrations or validate new transformation logic — a Lite and Pro feature.
Worked examples
Learn how replay and retry works.
View Setup Guides