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 →

Replay an event to all matching endpoints

POST

/v1/webhook_events/{id}/replay

const url = 'http://localhost:8080/v1/webhook_events/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_events/example/replay \
  --header 'Authorization: Bearer <token>'

Copies the event to a new event and queues it for every active endpoint in the same mode that subscribes to its type. Endpoints that already received it get it again, with the original event’s id and created_at. The original event and its deliveries are not changed. Each call makes a new copy.

replay_of is always the original event, even when id is a replay. status is queued, or no_matching_endpoints when no endpoint will receive it. Sending happens in the background. Writes an audit row. Needs only the apikey:read permission.

Authorizations

BearerAuth

Parameters

Path Parameters

required

string

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 created

application/json

object

event_id

required

The new event created by the replay.

string

replay_of

required

The original event.

string

status

required

string

Allowed values: queued no_matching_endpoints

Example

{
  "status": "queued"
}

403

Caller lacks the apikey:read permission

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"
  }
}

404

No such event in this mode

application/json

object

error

object

type

string

code

string

message

string

request_id

string

param

string

Example

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