Replays
The Replay API lets you re-trigger delivery for any stored event. This is useful when your webhook endpoint was temporarily unavailable, when you need to re-process historical data after a configuration change, or when you want to recover from bulk failures. All replay endpoints are asynchronous — they return202 Accepted immediately and process in the background. Monitor progress via the Events API.
All endpoints require a valid JWT session token.
Replay a single event
Re-delivers one specific event by ID.Request body
Example
Response
Status codes
Replay by time range
Re-delivers all events ingested within a specific time window.Request body
Example
Response
202 Accepted with an empty body. Events are processed in batches of 1,000 in the background.
Replay all events
Re-delivers every event in your account history.Request body
Example
Response
202 Accepted with an empty body.
Note: On accounts with large event histories, full replays may take significant time. Consider using the timeline or failed replay options to target a narrower set of events.
Replay failed events
Re-delivers all events currently in theFAILED state. This is the most common replay scenario after a period of webhook downtime.
Request body
Example
Response
202 Accepted with an empty body.
Choosing a replayGroupId
The replayGroupId is a string you define to identify a batch of replayed events in your own systems. It is attached to each replayed event in the delivery pipeline. Recommended patterns:
"recovery-<date>"— for post-outage recovery runs"backfill-<feature>"— for re-processing after a new feature is deployed"manual-<eventId>"— for one-off single-event retries