List events

Account-wide feed of domain events that fanned out to at least one enabled webhook endpoint, newest first. Each row carries the same envelope content a subscribed receiver was pushed - useful for reconciliation, backfilling a receiver that was down, or building your own audit trail without inspecting every endpoint’s deliveries individually.

This feed only contains events that had a live, enabled subscriber at the moment they fired. An event emitted while your organization had zero enabled webhook endpoints is never recorded here - registering your first endpoint does not retroactively surface earlier activity.

Filters: type (catalog event name) and created_after/created_before (unix seconds, inclusive). Scope: webhooks:read - this endpoint now carries its own least-privilege scope (previously it rode the coarser webhooks:manage, the pre-2026-08-02 registry’s documented least-privilege caveat for this exact route).

GET /v1/events

List events

cURL

curl --request GET \
  --url https://api.vexioncards.one/v1/events \
  --header 'Authorization: Bearer <token>'

200

Events

{ "object": "list", "data": [ { "id": "evt_01HW9RDZ4JK7N8MTX1RVEVTDEF", "object": "event", "type": "transaction.created", "created_at": 1750691720, "data": { "object": { "id": "txn_01HW9RCZ4HJ7N8MTX1RVWHDDEF", "object": "transaction" } } }, { "id": "evt_01HW9RDZ4JK7N8MTX1RVEVTDEH", "object": "event", "type": "customer.updated", "created_at": 1750691600, "data": { "object": { "id": "cus_01HW9RCZ4HJ7N8MTX1RVWHDMAG", "object": "customer" }, "previous_attributes": { "first_name": "Jan" } }, "request": { "id": "req_01HW9RDZ4JK7N8MTX1RVREQDEF", "idempotency_key": null } } ], "has_more": false, "url": "/v1/events" }

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.

Query Parameters

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 events at or after this time (inclusive).

created_before · integer string<date-time>

Only events 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.

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

ending_before · string

Walk backward. Send the first id from the current page's data[].

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

Response

200

application/json

Paginated event list.

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.