GET/v1/webhook-endpoints
List webhook endpoints
Returns the merchant's webhook endpoints, oldest first. A merchant registers where its events are delivered, and a third party that needs to know reads this.
Parameters
-
cursorquery · stringOpaque cursor from a previous page's
next_cursor. Omit to start from the beginning.Pass it back exactly as received. It is base64 and its structure is not part of this contract — decoding it, or constructing one by hand, will break without notice.
-
limitquery · integer · int32Maximum items to return. The server may return fewer, so always drive the loop from
has_morerather than from the size of the page you got back.
Responses
-
200
A page of webhook endpoints.
WebhookEndpointPage · application/json
has_morebooleanRequired
-
itemsarray of WebhookEndpointRequired
idstring · uuidRequiredRead only
created_atTimestampRequiredRead only
Server-assigned RFC 3339 timestamp, always UTC.
Server-assigned because device clocks drift and cannot be trusted for ordering — a till that has been powered off for a week may come back with a clock hours out. Where the device's own view of time matters it is carried separately in
client_created_at.eventsarray of stringThe event types this endpoint wants. Empty means all of them.
secretstringRead only
The key the receiver verifies signatures with (RFC 9421,
hmac-sha256), used as these characters. Sent only in the answer that creates the endpoint or rotates its secret, and never again: only the sealed copy is kept.statusstring · enumRequiredRead only
activeis receiving deliveries.disabledis one we stopped retrying after it kept failing;inactiveis set by a merchant. An endpoint the merchant deletes is absent rather than shown as inactive.activeinactivedisabledurlstring · uriRequired
The callback URL. Must be
https.≤ 2048 chars
versionVersionRequiredRead only
Optimistic concurrency version, raised by the server on every write. A version is never lower than one already returned for the resource, though it may rise by more than one.
Returned in the
ETagresponse header as well as in the body. Send it back inIf-Matchon an update and the write is rejected with412if anyone else has written since — which is what stops two tills silently overwriting each other's edit to the same product when both come back online at once.≥ 1
next_cursorstringRequired
Opaque cursor to pass to the next request.
-
400
The request could not be parsed. Malformed JSON, a bad query parameter, or a header that failed to decode, among them an
API-Versionlater than the server speaks or not a date (api-version-unknown, with the server's own inapi_version).Distinct from
422: a400never reached validation, soinvalid_paramsis absent. Retrying without changing the request will fail again, except that a request refused for itsAPI-Versiongoes once the server is updated. -
401
No credentials, or credentials that could not be verified — missing bearer token, malformed JWT, expired token, or a signature that failed against the issuer's JWKS.
Refresh the token and retry once. Repeated
401after a refresh means the device needs to re-enrol. -
403
Authenticated, but not permitted. The token is valid and its merchant was resolved, but the caller's role does not allow this operation, or the target belongs to a different merchant.
Cross-tenant access is reported as
403on a resource the caller may not see, and as404where even confirming existence would leak information. Retrying will not help. -
410
The request names an
API-Versionthis server no longer serves (docs/decisions/0011). Nothing in it was read.api_versionnames the version the server speaks: the client is behind, and sends the request again once it is updated. -
429
Rate limit exceeded. Honour
Retry-Afterrather than applying your own backoff.A fleet of tills coming back online together after an outage is the realistic cause, which is exactly when uncoordinated client-side retry turns a brief outage into a sustained one. The limit is per process, and per site for what records trade there — a request spends its site's budget, and a till's own smaller one inside it — and per
(client, merchant)for everything else; noRateLimitfield is sent, so this response and itsRetry-Afterare the whole of the contract. -
500
Something failed on our side.
trace_ididentifies the request in our tracing — quote it in a support ticket.The body never carries internal detail: no SQL, no stack traces, no upstream error strings. Safe to retry with the same
Idempotency-Key. -
503
Temporarily unable to serve the request — a dependency is down or the service is shedding load.
Retry with the same
Idempotency-KeyafterRetry-After. This is always safe: a request that did take effect before the failure will be recognised as a replay.