Retry (resend) a webhook delivery
Manually re-send a past delivery - the manual counterpart to the automatic 12-attempt retry. A new delivery attempt is created for the SAME event: it carries the same webhook-id (event id) as the original, so an idempotent receiver de-duplicates it against the first delivery. The original delivery record is never modified. Works on any endpoint status; retrying a disabled endpoint records the attempt but does not re-enable it (re-enable via PATCH first). Scope: webhooks:manage. Send an Idempotency-Key. Rate limit: 10 retries per endpoint per minute.
Authorizations
Your secret API key as a Bearer token: Authorization: Bearer vxn_sk_.... Keys are created and scoped in the dashboard - see Authentication.
Headers
Required on every mutating POST. See Idempotency.
8 - 255Path Parameters
Endpoint identifier (whk_ prefix).
^whk_[A-Za-z0-9]+$Delivery identifier (whd_ prefix) of the delivery to resend.
^whd_[A-Za-z0-9]+$Response
Retry accepted - a new delivery attempt (same event id) has been queued.
One delivery attempt record. Retained 90 days. High-volume listing: one row per attempt including retries. We store the response STATUS CODE only. No response headers, no response body bytes, and no request-body hash are retained, by design: see the privacy note in the Webhooks guide. Each attempt records its number, timestamp, status code, error string and duration. Replay is available over the API: POST /v1/webhook_endpoints/{id}/deliveries/{delivery_id}/retry. There is intentionally no single-delivery GET-by-id endpoint - list + retry only.
Delivery record id (whd_ prefix). Used as the pagination cursor.
^whd_[A-Za-z0-9]+$"whd_01HW9RCZ4HJ7N8MTX1RVWHDDEF"
Always "webhook_delivery".
"webhook_delivery"The endpoint this delivery targeted.
"whk_01HW9RBZ4GH7N8MTX1RVWHKDEF"
The event ULID - stable across retries; your receiver deduplicates on this.
^evt_[A-Za-z0-9]+$"evt_01HW9RDZ4JK7N8MTX1RVEVTDEF"
The locked v1 event catalog - 22 events across 9 subjects. Names follow resource.action with past-participle actions (transaction.created), never the dotted verb-stems used by transaction types - the two vocabularies never mix. product.created/product.updated fire for dashboard and API-created catalog changes; POS-synced catalog changes do not emit (they mirror the till, and a first sync would flood your endpoint).
customer.created, customer.updated, customer.deleted, customer.pass_installed, customer.pass_uninstalled, card.created, card.updated, card.deleted, custom_field.created, custom_field.updated, custom_field.deleted, product.created, product.updated, transaction.created, transaction.reversed, notification.sent, notification.delivery_updated, location.updated, team_member.added, team_member.updated, team_member.removed, webhook_endpoint.delivery_failed "transaction.created"
delivered = receiver returned 2xx within 10 s. retrying = on the backoff curve. failed = all 12 attempts exhausted (also fires webhook_endpoint.delivery_failed to other subscribed endpoints).
pending, delivered, retrying, failed "delivered"
Attempt count so far (max 12 across 24 hours).
1
Unix seconds when the event was first dispatched to this endpoint.
1750691720
HTTP status the receiver returned on the most recent attempt. Null when the attempt never got a response (timeout, TCP/TLS error).
200
Unix seconds of the next scheduled attempt. Null when delivered or failed.
null
Unix seconds of successful delivery. Null otherwise.
1750691720