Replay stored events

Queues a new delivery to this endpoint for every stored event created between from and to (inclusive) that matches the endpoint’s current events and filters. Use it after a receiver outage, or to backfill a newly created endpoint. Each replayed event keeps its original id, so the webhook-id header matches the original delivery and existing deduplication applies.

Events are retained for 30 days, and only events from the last 30 days can be replayed. A range containing more than 1000 events is rejected; narrow it or filter by types. Test events (webhook.test, and the examples sent with POST /api/webhooks/{webhookId}/test) are never replayed. Events are stored only while the workspace has at least one webhook (active or disabled), so events from before the first webhook cannot be replayed.

Replayed deliveries are processed by the standard dispatcher (same retries, same headers), are marked manual: true in the log, and do not affect endpoint health. A disabled endpoint cancels them; enable it first.

Side effects. Inserts one delivery per matching event; they are sent within seconds.

Idempotency. Not idempotent: calling it twice queues every event twice (with the same webhook-id, so a deduplicating receiver is unaffected).

Access

• Required scope: full. Human users need the owner or admin role.
• Rate limit: General API (120–600 requests/min per workspace, by plan) plus the configuration-mutations limit — 10 requests/min per workspace, shared with other configuration changes. See Rate limits.
• Plan: Requires an active subscription (active, trialing or past_due); without one the request is refused with 403 BILLING_ERROR (metadata.kind: subscription_required). See Billing and usage.