---
title: "Retry every recent dead delivery"
method: POST
path: "/v1/webhook-deliveries/retry-dead"
tags: ["Webhook Deliveries"]
---

# Retry every recent dead delivery

`POST /v1/webhook-deliveries/retry-dead`

## Request

- Base URL: `https://api.subscriby.net`
- URL: `https://api.subscriby.net/v1/webhook-deliveries/retry-dead`
- Auth: HTTP bearer

Once the consumer is fixed, replay everything the team dead-lettered since an instant in one call.

```bash
curl -X POST https://api.subscriby.net/v1/webhook-deliveries/retry-dead \
  -H "Authorization: Bearer $SUBSCRIBY_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"since": "2026-09-05T22:00:00Z"}'
```

`retried` is how many rows were reset and queued. Only `dead` rows are touched: a `failed` row is still on its ladder and will be posted again on its own. The replay is capped at 500 rows per call so one request after a long outage cannot flood the queue or the target; call it again if the count comes back at the ceiling.

Each replayed row posts its event again, so confirm the consumer is healthy first; see [replaying bulk dead deliveries](https://docs.subscriby.net/webhooks/v1/retries-and-delivery#replaying-bulk-dead-deliveries).

## Headers

- `Idempotency-Key` string, uuid, required

## Request body

- RetryDeadWebhookDeliveriesRequest: How far back to replay. Optional: omitted, the last 24 hours are replayed, the dashboard's Replay window.
  - `since` string, date-time, nullable: ISO 8601, not in the future. Only rows dead-lettered **at or after** this instant are replayed. Omit it for the last 24 hours.

## Response `200`

How many rows were re-queued and the instant the window opened at.

- object
  - `data` object, required: The response's payload.
    - `retried` integer, required: How many dead rows were reset to pending and queued, at most 500 per call.
    - `since` string, required: The instant the window opened at, ISO 8601: as sent, or 24 hours ago when omitted.

## Other responses

- `400`: `IDEMPOTENCY_KEY_MISSING`: every write needs an `Idempotency-Key` header. Send a fresh UUID per distinct operation.
- `401`: `AUTHENTICATION_REQUIRED`: the request carries no bearer token, or one that is revoked, malformed, or minted for another environment (an `sbt_test_` token on production).
- `403`: `TOKEN_MISSING_ABILITY`: the token is valid but does not carry the ability this endpoint requires; `error.context.required_ability` names the one to grant. An endpoint that also checks who owns a row or which tier the account is on answers `FORBIDDEN`, `TEAM_TIER_REQUIRED` or `CONNECTOR_TIER_REQUIRED` with the same status, and says so in its own description.
- `409`: `IDEMPOTENCY_KEY_REUSED`: the key was already used in the last 24 hours with a different request body.
- `422`: `VALIDATION_FAILED`: the payload broke a rule, and `error.fields` maps each offending key to its messages. A refusal from the domain, such as a plan that cannot go on sale or a member who cannot be removed, uses the same code with `error.message` saying why and no `fields`. On this endpoint: `VALIDATION_FAILED`: when `since` is malformed or in the future.
- `425`: `IDEMPOTENCY_REPLAY_IN_PROGRESS`: the first request with this key is still running; retry in a few seconds and the original response is replayed.
- `429`: `RATE_LIMITED`: the token has spent its 300 requests a minute or 10,000 an hour; `Retry-After` says when the next one is accepted.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)