Skip to main content
POST
Re-sends a recorded delivery to your webhook URL — handy when you’re fixing a verifier or recovering from downtime, and you want real traffic without waiting for a real payment. The replay is logged as a new delivery id in the delivery log. But the x-liddie-delivery-id header your endpoint receives stays the same: it’s the idempotency key of the logical event, and retries and replays of that event reuse it. A consumer that dedupes on that header — as the Webhooks & IPN guide prescribes — won’t process the replay twice.

​
Who can call this

Dashboard only — not accessible with an API key. Send your dashboard JWT (browser session) as a Bearer token, with team role merchant_admin or merchant_member plus the webhooks:manage permission. Rate limit: 20 requests per minute. See the Authentication guide.

​
Path parameters

​
string
required
The delivery id to replay, from List deliveries.
Cookie-authenticated writes also need an Origin header. Any non-GET request that carries the liddie_access session cookie is checked against the allowed dashboard origins; a bare cURL that sends only the cookie is rejected with 403 {"ok":false,"error":{"code":"CSRF_ORIGIN_MISMATCH","message":"Forbidden"}} before the handler runs. The snippet below is shown for shape — from a browser the dashboard sends the origin for you; from a script, prefer an API key where the endpoint accepts one.
Dedupe on the x-liddie-delivery-id header, not on the delivery log’s row id. Replays and retries of the same logical event reuse that header, so a header-deduping consumer processes each event exactly once.

​
See also