Pre-1.0 · one maintainer · Stripe and cards only · no SDKs (client libraries) yet · no production users yet. Docs describe v0.9.1 (29 Oct 2026) · What’s new →

Resend one delivery to its endpoint

POST

/v1/webhook-endpoints/endpoints/{id}/deliveries/{deliveryID}/replay

const url = 'http://localhost:8080/v1/webhook-endpoints/endpoints/example/deliveries/example/replay';
const options = {method: 'POST', headers: {Authorization: 'Bearer <token>'}};

try {
  const response = await fetch(url, options);
  const data = await response.json();
  console.log(data);
} catch (error) {
  console.error(error);
}

curl --request POST \
  --url http://localhost:8080/v1/webhook-endpoints/endpoints/example/deliveries/example/replay \
  --header 'Authorization: Bearer <token>'

Sends the delivery’s event again to this one endpoint only. Other endpoints are not contacted. Hardcount copies the event to a new event (replay_of points to the original) and queues a new delivery. The message sent carries the original event’s id and created_at. The original delivery is not changed. Sending happens in the background, so status is always queued. Writes an audit row.

Authorizations

BearerAuth

Parameters

Path Parameters

required

string

Endpoint id.

deliveryID

required

string

Delivery id. It must belong to this endpoint.

Header Parameters

Idempotency-Key

string

Makes the call safe to retry. Send a unique value (a UUID works) and the same value on every retry. For 24 hours, a repeat with the same key, method, path and body gets the first response again, with an Idempotent-Replayed: true header, instead of running again. The error cases are in docs/api-surface.md. The usage routes do not take it: each usage event carries its own idempotency_key.

Responses

200

Replay queued

application/json

object

event_id

required

The new event created by the replay.

string

replay_of

required

The original event.

string

delivery_id

required

The new delivery to this endpoint.

string

status

required

string

Allowed values: queued

Example

{
  "status": "queued"
}

404

No such delivery, the delivery belongs to another endpoint, or the endpoint was deleted

application/json

object

error

object

type

One of invalid_request_error, authentication_error, rate_limit_error or api_error. Every error the API answers has this shape, including an unknown path (404, code route_not_found) and a method the path does not take (405, code method_not_allowed, with an Allow header). The few exceptions are listed in docs/api-surface.md.

string

code

string

message

string

request_id

string

param

The request field the error is about. Sent only when the error names one. A request body may hold only the fields its operation lists, spelled and cased as listed: any other field, or one the server sets (such as id), is refused with 422 and param naming it. An operation with no request body lists no fields: send no body, {} or null. The Stripe and Postmark webhooks and the LiteLLM callback take their sender’s body as it comes.

string

Example

{
  "error": {
    "type": "invalid_request_error"
  }
}

409

The endpoint is paused (active is false). Resume it first. Code invalid_state.

application/json

object

error

object

type

string

code

string

message

string

request_id

string

param

string

Example

{
  "error": {
    "type": "invalid_request_error"
  }
}