Recover Missed Webhooks

Use these APIs to inspect persisted notifications from the last 30 × 24 hours and request a replay. A replay resends the saved notification; it never repeats the deposit, transfer, or other business action. Keep your own event history for longer reconciliation.

Find the event. Use List Webhook Events with status=FAILED, an account_id, or an event-name prefix such as deposit.*. If you already have X-Webhook-Event-Id, use Get Webhook Event. FAILED means all targets have finished and at least one failed; use PROCESSING to monitor targets still in progress. NOT_SUBSCRIBED means the event matched no subscription, so no notification was sent or automatically retried.
Inspect the targets. The event's subscriptions show the latest state per target; active=false means a historical target is no longer selectable. Use List Webhook Deliveries at /v2/webhooks/events/{event_id}/deliveries for lifecycle diagnostics. List Webhook Subscriptions shows active targets.
Request a replay. Replay Webhook Event requires a Standard API credential and a UUID Idempotency-Key. Omit the body to select all active subscriptions, set subscription_id to select one, or set status=FAILED to select only currently failed active targets. A replay can also target an event with no prior delivery. An empty selection returns 409 and writes nothing. If any selected target has an active delivery, the whole request returns 409; status=FAILED skips targets still in progress. 202 means all selected deliveries were durably accepted, not sent; keep the returned replay ID and delivery IDs.
Poll the result. Get Webhook Replay returns each selected delivery's current outcome. It remains available for 30 × 24 hours after acceptance even if the event expires. If the POST times out, returns 503, or its response is lost, retry the same request with the same key to recover the same receipt. A different request with the same key returns 409. After an existing receipt expires, that key returns 404 rather than starting new work; use a new key for a new request.

If a replay request is rejected, inspect errors[0].type:

HTTP status / type	What to do
`409 DELIVERY_IN_PROGRESS`	Poll existing deliveries. To replay only other failed targets, retry with `status=FAILED` and a new key.
`409 IDEMPOTENCY_CONFLICT`	Reuse the original request with that key, or use a new key for an intentional new request.
`409 NO_ELIGIBLE_TARGETS`	Check the selected targets and their current status; no replay was created.
`409 TARGET_INACTIVE`	Choose an active subscription from List Webhook Subscriptions.
`429`	Respect `Retry-After` and retry the same request and key. This can mean API rate limiting or exhausted active manual-delivery capacity.

Each target has at most one active delivery lifecycle at a time. PENDING has not been sent. PROCESSING is owned by a worker. For manual replay, RETRYING can mean waiting for platform sending capacity before any HTTP attempt; avoid submitting a new key simply because it is waiting. SUCCESS means your endpoint returned 2xx. PERMANENTLY_FAILED means this lifecycle ended unsuccessfully. A manual replay makes one HTTP send attempt after sending starts; automatic notifications retain their existing retry policy. A worker crash after a possible send but before storing its result can still cause a duplicate.

Events and deliveries are ordered by creation time descending, then ID descending. Continue while has_more is true even if a page is empty; restart at the first page periodically to find late-committed events. Event and delivery reads use the 30-day event window, and an accepted replay may keep running after the event leaves that window.

Verify signatures and process every webhook idempotently. X-Webhook-Event-Id stays the same across automatic retries and manual replays; the delivery ID changes for each replay lifecycle. Check the current resource state before applying a delayed notification.