List per-recipient deliveries

Returns the per-recipient, per-device delivery rows for one broadcast - the answer to “did customer X receive it, on which device, and why not”.

A customer holding the pass on two platforms appears twice (one row per device). Rows settle from pending to delivered/failed as the fan-out drains; a cleanup sweep marks anything stranded as failed, so the collection always reaches a terminal state.

Common patterns:

• Failed-only audit: ?status=failed - each row carries the provider error
• Per-customer check: ?customer_id=cus_...
• Re-target failures: collect customer_ids from failed rows and send a follow-up broadcast with audience.customer_ids

See Pagination.

Scope: notifications:read.

GET /v1/notifications/{id}/deliveries

List per-recipient deliveries

cURL

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

200

Mixed devices

{
  "object": "list",
  "data": [
    {
      "id": "ntd_01J9P0G7K9C0RYHXJ2K7AD0001",
      "object": "notification_delivery",
      "customer_id": "cus_01HW9R4P2ZK7N8MTX1RVABCDEF",
      "device": "apple_wallet",
      "status": "delivered",
      "error": null,
      "updated_at": 1782134460
    },
    {
      "id": "ntd_01J9P0G7K9C0RYHXJ2K7AD0002",
      "object": "notification_delivery",
      "customer_id": "cus_01HW9R4P2ZK7N8MTX1RVMNOPQR",
      "device": "google_wallet",
      "status": "delivered",
      "error": null,
      "updated_at": 1782134462
    },
    {
      "id": "ntd_01J9P0G7K9C0RYHXJ2K7AD0003",
      "object": "notification_delivery",
      "customer_id": "cus_01HW9R4P2ZK7N8MTX1RVGHIJKL",
      "device": "google_wallet",
      "status": "failed",
      "error": "device unregistered",
      "updated_at": 1782134470
    }
  ],
  "has_more": false,
  "url": "/v1/notifications/ntf_01J9P0G7K9C0RYHXJ2K7A4N5MZ/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

Notification identifier (ntf_ prefix).

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

Query Parameters

status · enum<string>

Filter: pending, delivered, failed.

Available options: pending, delivered, failed

device · enum<string>

Filter: apple_wallet, google_wallet.

Available options: apple_wallet, google_wallet

customer_id · string

One recipient's rows.

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

limit · integer · default: 25

Page size, 1-100. Default 25.

Required range: 1 <= x <= 100

starting_after · string

Cursor - the ntd_ id of the last row on the previous page (forward). Numeric offset or page parameters are not supported; cursors are the only supported paging mechanism.

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

ending_before · string

Reverse cursor - rows before this ntd_ id.

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

Response

200

application/json

Paginated delivery rows.

Cursor-paginated per-recipient delivery rows.

object · string · required

Always "list".

Allowed value: "list"

data · object[] · required

Delivery rows.

Show child attributes

has_more · boolean · required

True when more pages exist.

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.

Example:

"/v1/notifications/ntf_01J9P0G7K9C0RYHXJ2K7A4N5MZ/deliveries"