List recent deliveries
Returns the last 90 days of delivery attempts for this endpoint, newest first. One row per attempt including retries - high volume; use limit=100 to drain faster.
Filters: status (pending / delivered / retrying / failed), event_type (catalog name), and created_after/created_before (unix seconds, inclusive - matches this row’s created_at). Compose with cursors.
Common pattern - audit all failures: ?status=failed&limit=100, follow starting_after until has_more=false. Each failed row carries the last response_code your receiver returned. Replay a failed delivery with POST /v1/webhook_endpoints/{id}/deliveries/{delivery_id}/retry, which enqueues a fresh attempt (a new delivery row).
Scope: webhooks:read.
There is intentionally no GET /v1/webhook_endpoints/{id}/deliveries/{delivery_id} - a single delivery is only reachable by paging this list (or via POST …/retry, which returns the new attempt). Do not build an integration that expects a single-delivery fetch. Only real event deliveries appear here. Test sends from POST /v1/webhook_endpoints/{id}/test are synchronous and create no delivery row, so an empty list right after a successful test send is expected, not a fault.
Authorizations
Your secret API key as a Bearer token: Authorization: Bearer vxn_sk_.... Keys are created and scoped in the dashboard - see Authentication.
Query Parameters
Filter by catalog event name.
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"
Response
The delivery record object.
Standard cursor-pagination envelope for list endpoints. See the Pagination guide.
Cursor for the next page in the direction you are already paging, or null when this page ends the collection. has_more: true always comes with a non-null next_cursor.
Feed it back to the SAME parameter you used: starting_after when paging forward (the default), or ending_before when paging backward. Treat it as opaque and do not parse it.
You no longer need to take the last object's id yourself. That still works and is unchanged, but deriving the cursor from the page put the burden of knowing the sort direction on you, and it broke silently on any endpoint whose cursor is not the object id.
"cus_iofv5j4hn6bphinmmyat27tc5y"