Replay is on the roadmap and not yet available. This page documents the planned API shape so customer technical teams and Recurr’s implementation team can align on the contract.
Use cases
- Backfill a new warehouse — switched BI tools (BigQuery → Snowflake, or onboarding to a new product analytics platform); replay the last 12 months to populate baseline data
- Recover from a downstream incident — your webhook receiver was down for 4 hours, queue drained; replay the gap window to catch up
- Audit / compliance — generate a clean event stream for a specific period (auditor request, internal review, regulatory inquiry)
- New integration onboarding — wire up a new destination (e.g., adding Amplitude alongside existing BigQuery); replay last 30 days to populate baseline
- Bug recovery — found gaps in your data downstream; replay a specific window to fix
Request shape
POST https://api.recurr.dev/v1/replay
Authorization: Bearer <recurr_api_key>
Content-Type: application/json
{
"destination_id": "dest_01HQX...",
"event_types": ["subscription.activated", "subscription.renewed"],
"from": "2026-04-01T00:00:00Z",
"to": "2026-05-01T00:00:00Z",
"dedupe_strategy": "skip_existing"
}
Request fields
| Field | Type | Required | Description |
|---|
destination_id | string | Yes | Target destination (registered via Destinations) |
event_types | string[] | No | Event-type filter (e.g., ["subscription.activated"]). Omit to include all types. |
from | string (ISO 8601) | Yes | Start of replay window (inclusive). Must be within 24 months of current time. |
to | string (ISO 8601) | Yes | End of replay window (exclusive). Must be after from. |
dedupe_strategy | string | No | "skip_existing" (default — relies on event_id dedup at receiver) or "force_redeliver" (re-send regardless) |
subscriber_ids | string[] | No | Filter to specific subscriber IDs. Useful for “replay one subscriber’s history” debugging. |
cohort_ids | string[] | No | Filter to specific cohort IDs. Useful for migration-cohort audit. |
Response shape
{
"replay_id": "rep_01HQX9K2M3N4P5R6T7Y8U9W0V",
"status": "queued",
"estimated_event_count": 1284,
"estimated_completion_at": "2026-05-22T14:00:00Z",
"destination_id": "dest_01HQX...",
"from": "2026-04-01T00:00:00Z",
"to": "2026-05-01T00:00:00Z"
}
Replayed event delivery
Each replayed event is delivered to your endpoint with:
- Original
id, created_at, schema_version, data — same payload as the first delivery
- Original signature (signed at original creation time; still valid for HMAC verification)
- Additional header:
X-Recurr-Replay-Id: rep_01HQX... indicating which replay batch this delivery belongs to
- Additional header:
X-Recurr-Replay-Attempt: 1 (or 2, 3 if your endpoint failed on this replay)
Your idempotency layer (see Overview § Idempotency) handles dedup naturally if dedupe_strategy: skip_existing is set — your receiver will see the same event_id it already processed and skip.
If dedupe_strategy: force_redeliver is set, your receiver will see the same event_id twice. Force-redeliver should only be used when you’ve explicitly cleared your dedup table for the replay window (e.g., dropped + rebuilding the warehouse).
Monitoring a replay
GET replay status
GET https://api.recurr.dev/v1/replay/rep_01HQX9K2...
Authorization: Bearer <recurr_api_key>
{
"replay_id": "rep_01HQX9K2...",
"status": "in_progress",
"events_delivered": 847,
"events_failed": 12,
"events_pending": 425,
"started_at": "2026-05-22T13:34:56Z",
"estimated_completion_at": "2026-05-22T14:00:00Z"
}
Status values
| Status | Description |
|---|
queued | Replay accepted, waiting to start |
in_progress | Currently delivering events |
completed | All events delivered successfully |
completed_with_errors | Finished, but some events failed permanently (see events_failed) |
cancelled | Cancelled by user via DELETE |
failed | Replay job failed before completion (rare; contact support) |
Cancel a replay
DELETE https://api.recurr.dev/v1/replay/rep_01HQX9K2...
Authorization: Bearer <recurr_api_key>
Limits
| Constraint | Limit |
|---|
| Replay window | Up to 24 months back from current time |
| Concurrent replays per tenant | 3 |
| Maximum events per replay | No hard cap; large replays may take hours to complete |
| Replay-call rate limit | 3 invocations per minute per API key |
Pricing
Replay is a tier-paid feature when generally available. Pricing TBD; expected shape:
- Replay is included in Enterprise tier (when launched)
- Standard tier: ad-hoc replay available at per-batch fee (~$50-200 per replay job depending on event volume)
- Auditing replays (compliance / regulator response) priced at cost
Final pricing communicated at general availability.