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.

GET /v1/webhook_endpoints/{id}/deliveries

List recent deliveries

cURL

curl --request GET \
  --url https://api.vexioncards.one/v1/webhook_endpoints/{id}/deliveries \
  --header 'Authorization: Bearer <token>'

200

Mixed statuses

{
  "object": "list",
  "data": [
    {
      "id": "whd_01HW9RCZ4HJ7N8MTX1RVWHDDEF",
      "object": "webhook_delivery",
      "webhook_endpoint_id": "whk_01HW9RBZ4GH7N8MTX1RVWHKDEF",
      "event_id": "evt_01HW9RDZ4JK7N8MTX1RVEVTDEF",
      "event_type": "transaction.created",
      "status": "delivered",
      "response_code": 200,
      "attempts": 1,
      "next_retry_at": null,
      "delivered_at": 1750691720,
      "created_at": 1750691720
    },
    {
      "id": "whd_01HW9RCZ4HJ7N8MTX1RVWHDDEG",
      "object": "webhook_delivery",
      "webhook_endpoint_id": "whk_01HW9RBZ4GH7N8MTX1RVWHKDEF",
      "event_id": "evt_01HW9RDZ4JK7N8MTX1RVEVTDEH",
      "event_type": "customer.pass_installed",
      "status": "retrying",
      "response_code": 502,
      "attempts": 4,
      "next_retry_at": 1750691910,
      "delivered_at": null,
      "created_at": 1750691600
    }
  ],
  "has_more": true,
  "url": "/v1/webhook_endpoints/whk_01HW9RBZ4GH7N8MTX1RVWHKDEF/deliveries"
}

Authorizations

Authorization · string · header · required

Your secret API key as a Bearer token: Authorization: Bearer vxn_sk_.... Keys are created and scoped in the dashboard - see Authentication.

Path Parameters

id · string · required

Endpoint identifier (whk_ prefix).

Pattern: ^whk_[A-Za-z0-9]+$

Query Parameters

status · enum<string>

Filter: pending, delivered, retrying, failed.

Available options: pending, retrying, delivered, failed

event_type · enum<string>

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).

Available options: 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

Example:

"transaction.created"

created_after · integer string<date-time>

Only delivery attempts created at or after this time (inclusive).

created_before · integer string<date-time>

Only delivery attempts created at or before this time (inclusive).

limit · integer · default: 25

Page size, 1-100. Default 25.

Required range: 1 <= x <= 100

starting_after · string

Walk forward. Send the last id from the previous page's data[]. Numeric offset or page parameters are not supported; cursors are the only supported paging mechanism.

ending_before · string

Reverse cursor - returns deliveries before this whd_ id.

Pattern: ^whd_[A-Za-z0-9]+$

Response

200

application/json

The delivery record object.

Standard cursor-pagination envelope for list endpoints. See the Pagination guide.

object · string · required

Always "list".

Allowed value: "list"

data · object[] · required

Array of the requested resource type.

Show child attributes

has_more · boolean · required

True when more pages exist - pass the last item id as starting_after.

next_cursor · string | null

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.

Example:

"cus_iofv5j4hn6bphinmmyat27tc5y"

url · string

Stable collection URL.