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 ever received, 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 a window (an event, a range, a whole source) and Slashbin re-fires those stored payloads through your latest transform.
Retry is automatic redelivery when a destination rejects or times out. It runs per destination on its own backoff, and exhausted attempts go to a DLQ you can act on. See the Retry page for how the retry pipeline works.
How it works in Slashbin
- Select a window. Pick a single event, a time range, or every payload for a source.
- 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.
- Delivered in order, newest-wins. Replays are queued per destination, ordered by event timestamp, so a replay that overlaps live traffic never leaves your API in a stale state.
When you need it
Endpoint downtime
Your API was down for an hour. Replay the missed window instead of asking the vendor to resend.
Model changed
You fixed a mapping bug. Replay yesterday's events through the corrected transform to heal the downstream state.
New destination backfill
Pointing a new consumer at an existing source. 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. |
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.
DLQ Recovery
Dead-letter queue with self-service replay. Recover from outages without engineering intervention.
Historical Backfill
Re-trigger historical events to seed new integrations or validate new transformation logic.
Worked examples
Learn how replay and retry works.
View Setup Guides