Replay failed deliveries
Queues redelivery of deliveries that failed. The window runs from since (default: the last 24 hours) to until, and events the endpoint already received successfully are skipped, so a replay never double-delivers.
Only failed attempts are replayed, and the window selects on attempt time rather than on when the event occurred. An event the endpoint was never sent, such as one that arrived while it was paused, has no failed attempt to replay, so a replay does not recover it. Replay reads the delivery-attempt log, which retains three days, so that is the oldest history it reaches: an earlier since widens the window without recovering anything older. A paused endpoint redelivers nothing at all: re-enable it with Update a webhook endpoint first.
The 202 response means the replay is queued. Each redelivery then takes a single attempt rather than the retry schedule a live delivery follows, so a replay into an endpoint that is still broken costs one request per event; fix the endpoint and replay again. No count or task ID is returned, so track results with List delivery attempts.
One replay redelivers at most the oldest 10,000 events in the window, and replays are limited to 20 per organization per UTC day; beyond that the request returns a 429 WebhookReplayQuotaExceeded.
Request
- Base URL: https://us1.platform.bird.com
- URL: https://us1.platform.bird.com/v1/webhooks/{webhook_id}/replay
- Auth: one of:
- HTTP bearer
- API key in cookie bird_session
Headers
Client-supplied key. On operations supporting request deduplication, a retained response is replayed for duplicate requests with the same key within the idempotency window (3 hours by default). This protection requires a workspace, organization, or staff-account scope. User-only and unscoped unauthenticated operations, streams, and operations with a separate replay contract do not use this response replay.
On a supported operation, if idempotency protection is unavailable before execution, the API returns 503 IdempotencyUnavailable (E01033) without executing this attempt. Retry with backoff using the same key and request. An operation that takes effect before its response is retained can still execute again on retry.
Two distinct 409 errors signal misuse:
- request_in_progress (E01004): The same key is currently being processed by a concurrent request. Wait briefly and retry. The lock expires within 30 seconds.
- idempotency_key_reuse (E01005): The same key has already completed against a different request body or method. Generate a new key.
Recommended key format is <event-type>/<entity-id> (for example welcome-user/usr_abc123).
Workspace context for the request. Required for dashboard authentication and master keys. Workspace keys and access tokens already identify their workspace; send that workspace or omit the header. A different one is rejected.
Organization context for the request. Required for dashboard authentication. An API key or access token carries its own organization, so send either that organization or no header at all; a different one is rejected.
Request body
Example request
{
"since": "2026-05-07T00:00:00Z",
"until": "2026-05-07T23:59:59Z"
}Response
Replay queued. Events are redelivered asynchronously; no count or task ID is returned.
Changes
No recorded changes to this operation across all 2 revisions of this API.