Replays

A replay sends stored events again to the destinations you choose, and only to them: after a destination’s outage, after fixing a mapping, or to fill a new destination with recent history. Destinations you do not choose receive nothing.

Replayed events keep their IDs. The message ID and event ID are the original ones, so a destination that de-duplicates by event ID drops events it already has.

Consent is checked again, for each destination. A replay uses the consent the visitor gave with the event, and never reaches a destination the visitor did not consent to. Bot rules apply per destination in the same way.

Replays read the event store (recent events a pipeline stored) or, for long history, the event archive in your own object storage, where the pipeline archives its events. In the Management UI, open Replays under Observe.

How a replay runs

You choose a pipeline, a time range, the destinations, the configuration and a rate. Filters are optional.
Count events shows how many stored events match and the first few. A replay starts only after a count. The archive is in your object storage, not the database, so an archive replay is counted as it reads.
The replay reads the events in the order they were received (from the archive, hour by hour), at the rate you set, and delivers each one to the chosen destinations. Its progress, and what each destination received, update as it runs.
Cancel stops it within a few seconds. Events already delivered stay delivered.

A replay runs alongside live traffic and does not queue in front of it. It does share each destination’s own rate limit, so set a rate the destinations can take on top of their live traffic.

Configuration

Choice	Delivers with
Current (default)	The destinations’ published mappings and parameters now, for example after a fix.
As published when each event was received	The mappings and parameters of the pipeline version that was live when the event was received.

Consent settings (the consent mode and the defaults for categories the visitor did not choose) and bot rules are pipeline settings, not part of a version, so they are always the current ones. The visitor’s own consent choices are the ones stored with the event. A destination that did not exist, or was not in the version live at an event’s time, does not receive that event.

What a replay leaves alone

A replayed event is not collected again. It is not added to analytics, the event store, identity, attribution or delivery statistics, and pipeline derivations and brand fan-out do not run for it. Replayed deliveries are counted on the replay instead. Failed deliveries follow the destination’s normal retry policy and dead letter queue.

Filters

Filter	Selects
Event types	`track`, `page`, `screen`, `identify` or `group`. None selected means every type.
Event names	Events with one of these names, such as `purchase`.
Event IDs	Events with one of these message IDs (up to 10,000).
Attributes	Up to 10 conditions on a field of the stored event, such as `properties.currency` is one of `EUR, GBP`. A field starts with `properties`, `context`, `traits`, `user_id`, `anonymous_id`, `event`, `type`, `event_id`, `group_id` or `device_id`.
Delivery outcome	Events that never reached a destination (their dead-letter entry is pending or was discarded), or that failed at least once to it.

Every filter you set must hold.

Results

For each destination a replay shows:

Figure	Meaning
Delivered	Delivered to the destination.
Failed	Sent to the retry schedule or the dead letter queue, and not delivered since.
Filtered by the blueprint	The destination’s blueprint does not send this event.
No consent	The event’s consent does not allow this destination.
Bot	The destination’s bot rule excludes the event.
Not configured	The destination has no configuration for the event: it is not live now, or was not in the version live at the event’s time.

API

`POST /v1/admin/replays`

Creates a replay, or with "dry_run": true only counts what it selects.

Field	Type	Description
`pipeline_id`	string	The pipeline.
`source`	string	`event_store` (default) or `archive`, where the installation has an event archive.
`from`, `to`	string	RFC 3339 times. Events received at or after `from` and before `to`.
`destinations`	string[]	Integration IDs of the pipeline. With `"config": "current"` they must be live now; with `"original"`, published in some version.
`config`	string	`current` (default) or `original`.
`rate_per_second`	integer	Events read per second. Default 100, at most 1,000 unless the deployment raises `REPLAY_MAX_RATE`.
`filters`	object	`event_types`, `event_names`, `message_ids`, `match` (`[{ "path", "op": "eq" \| "neq" \| "in" \| "exists" \| "not_exists", "value" or "values" }]`) and `delivery` (`{ "integration_id", "status": "undelivered" \| "failed" }`).
`dry_run`	boolean	Count only.

curl -X POST "http://localhost:8084/v1/admin/replays" \
  -H "Authorization: Bearer {access_token}" \
  -H "Content-Type: application/json" \
  -d '{
    "pipeline_id": "pip_abc123",
    "from": "2026-09-10T00:00:00Z",
    "to": "2026-09-11T00:00:00Z",
    "destinations": ["int_meta"],
    "config": "current",
    "rate_per_second": 200,
    "filters": {
      "event_names": ["purchase"],
      "delivery": { "integration_id": "int_meta", "status": "undelivered" }
    },
    "dry_run": true
  }'

A dry run returns 200 with matched (or null when there are too many events to count in time), a sample of the first events, and any warnings. A replay returns 201 with the job. An organisation can have 5 replays queued or running at once (REPLAY_MAX_OPEN_JOBS).

Status	When
`400`	The request is not valid. `validation_errors` names each defect.
`404`	The pipeline was not found.
`409`	Too many replays are already queued or running.
`422`	No stored events match.

`GET /v1/admin/replays`

Lists replays, newest first, with their progress and each destination’s figures. ?pipeline_id= narrows the list.

`GET /v1/admin/replays/{id}`

One replay: status (queued, running, completed, cancelled or failed), matched, published (events read so far), destinations with the figures above, and error when it failed.

`POST /v1/admin/replays/{id}/cancel`

Stops a queued or running replay. Returns 409 when it has already finished.

Permissions and audit

Replays are part of the event store, so they are available where the licence includes it. Creating and cancelling a replay needs permission to replay dead-letter events, which org_admin and source_admin have. Reading replays needs read access to the dead letter queue. Each replay is recorded in the audit log as replay.created, with its range, filters, destinations, configuration and rate, and replay.cancelled.

Dead Letter Queue Users & RBAC