---
title: "Replay failed deliveries"
method: POST
path: "/v1/webhooks/{webhook_id}/replay"
tags: ["webhooks"]
---

# Replay failed deliveries

`POST /v1/webhooks/{webhook_id}/replay`

## 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`

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](/docs/api/reference/update-webhook)
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](/docs/api/reference/list-webhook-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`.

## Headers

- `Idempotency-Key` string
- `X-Workspace-Id` string
- `X-Organization-Id` string

## Request body

- WebhookReplayRequest
  - `since` string, date-time: Replay events whose delivery attempt failed at or after this timestamp. The bound is inclusive and applies to attempt time, not to when the event occurred, so a retry that trailed its event by a day falls in the window by the hour it was attempted. Defaults to 24 hours before the request when omitted. Attempts are retained for three days, so that is the oldest history a replay reaches: an earlier `since` widens the window without recovering anything older.
  - `until` string, date-time: Replay events whose delivery attempt failed at or before this timestamp, on the same attempt-time bound as `since`. Omitted, it resolves to the time of the request.

## Response `202`

Replay queued. Events are redelivered asynchronously; no count or task ID is returned.

## Other responses

- `400`: Bad request
- `401`: Authentication required
- `403`: Insufficient permissions
- `404`: Resource not found
- `422`: The request has invalid field values, violates a business rule, or carries a query parameter the endpoint does not declare. Field validation errors use `type: validation_error` and include the affected fields in `details`. Business-rule errors identify the failed rule in `type`.
- `429`: Rate limit exceeded
- `500`: Internal server error
- `503`: The service is temporarily unavailable. If `Retry-After` is present, wait for that delay before retrying; otherwise, retry with exponential backoff. Reuse the same idempotency key and request when retrying a mutation.

---

[API](https://skmtc.dev/messagebird/apis/bird-api.md) · [All operations](https://skmtc.dev/messagebird/apis/bird-api/llms.txt) · [OpenAPI document](https://skmtc.dev/messagebird/apis/bird-api/revisions/6dfce1179799?raw)