Skip to main content

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 return 202 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 the FAILED 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
The value is not validated beyond being a non-empty string.