List the tenant's webhook endpoints
const url = 'https://api.pixonaut.app/v1/webhooks';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://api.pixonaut.app/v1/webhooks \ --header 'Authorization: Bearer <token>'Operation ID: webhookEndpoints.list
Authorizations
Section titled “Authorizations”Responses
Section titled “Responses”The endpoints
object
The key that owns the endpoint, and alone of the tenant’s keys manages it: the secret key that registered it, or the integration key of the store it was given to. Null for one registered in the studio.
The connected store the endpoint was registered for; null for one registered on its own. Such an endpoint is deleted by disconnecting the store.
Whether the store’s webhook address answered when it was last checked: when the store was approved, or when the address was last sent to PATCH /v1/webhooks/{id}. A sandbox store whose address did not (a local machine, a private address) is connected anyway, but no delivery is enqueued for it, and it reads its events by pulling them with GET /v1/events. Always true for a live store, which is refused an address that does not answer. Always true for an endpoint no store was given, which is not checked.
Examples
Example
[ { "active": true, "apiKeyId": "d4c3b2a1-0f9e-4d8c-9b7a-6e5f4d3c2b1a", "connectionId": null, "createdAt": 1760000000000, "cursor": "1042", "eventTypes": [ "design.committed", "order.status_changed" ], "failedCount": 0, "failing": false, "id": "wh_5f2a9c1d7e3b4a6f8c0d2e4a", "reachable": true, "tenantId": "acme", "url": "https://shop.acme.example/wp-json/pixonaut/v1/webhook" }]Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: unauthorized
object
Examples
unauthorized
{ "error": "unauthorized"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: origin_forbidden, forbidden, feature_disabled
object
The feature the tenant does not have. Always sent with feature_disabled.
Examples
feature_disabled
{ "error": "feature_disabled", "feature": "api"}forbidden
{ "error": "forbidden"}origin_forbidden
{ "error": "origin_forbidden"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: db_error. A request that failed unexpectedly answers as text instead.
object
Examples
db_error
{ "error": "db_error"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Questions? Write to [email protected].