Browse API docs
Webhooks
Manage webhooks through the same /admin/webhooks URLs used by the dashboard. Send Authorization: Bearer TOKEN and Accept: application/json. Writes require a write token.
Account tokens manage the account’s webhooks. A co-organizer’s personal token can list, view, create, edit, reactivate and delete only webhooks belonging to that same team membership. New personal webhooks automatically cover all events currently assigned to the membership. The API does not accept an account, membership or event assignment in webhook parameters.
Endpoints
| Method | URL | Response |
|---|---|---|
| GET | /admin/webhooks |
200, { "webhooks": [...] } |
| GET | /admin/webhooks/:id |
200, one webhook including its signing secret |
| POST | /admin/webhooks |
201, created webhook and Location header |
| PATCH | /admin/webhooks/:id |
200, updated webhook |
| DELETE | /admin/webhooks/:id |
204, empty body |
| POST | /admin/webhooks/:id/activation |
200, reactivated webhook |
Missing or foreign webhook IDs return 404. A read token attempting a write returns 401. Validation errors return 422 with { "errors": { "field": ["message"] } }.
Create
{
"webhook": {
"name": "CRM updates",
"url": "https://example.com/usetix",
"subscribed_actions": ["order.paid", "ticket.redeemed"]
}
}
The URL must use HTTP or HTTPS and resolve to a public IP at delivery time. The URL is immutable after creation; create a new webhook to change destinations. PATCH accepts name and subscribed_actions. An empty subscription array stops new deliveries.
Personal webhooks support order.paid, order.refunded, order.cancelled, event.published, event.unpublished and ticket.redeemed. Account-wide voucher subscriptions are rejected for personal webhooks.
Response
{
"id": 42,
"name": "CRM updates",
"url": "https://example.com/usetix",
"active": true,
"scope": "assigned_events",
"subscribed_actions": ["order.paid", "ticket.redeemed"],
"created_at": "2026-09-08T12:00:00Z",
"updated_at": "2026-09-08T12:00:00Z",
"signing_secret": "YOUR_SIGNING_SECRET"
}
scope is account or assigned_events. The collection omits signing_secret; individual responses include it for verification setup. Keep this secret private.
Personal webhook access is checked again when queued work runs. Deactivation, a role change away from co-organizer, or removal of an event assignment stops affected deliveries. Adding an event assignment automatically includes future updates for that event. Re-enabling a membership does not replay discarded deliveries.
See Webhook delivery and payloads for signing, event types, and the restricted personal payload format.
Trigger samples and delivery history
GET /admin/webhook_events?action_name=order.paid returns { "events": [...] }
using the same payload serializer and access restrictions as live webhooks.
An optional event_slug filters by an accessible event before selecting the
latest 25 records. Unsupported actions return 422; foreign events return 404.
GET /admin/webhooks/:id/deliveries returns the latest 100 delivery records with
id, state, attempts_count, next_attempt_at, response, created_at, and
redelivery_of_id. States are pending, in_progress, retrying, completed
and errored. Completion records the final HTTP result; it does not itself mean
that the receiver returned a successful status.
POST /admin/webhooks/:id/deliveries/:delivery_id/redelivery returns 202 and
creates a new delivery for a failed attempt. Repeating the request returns the
same redelivery. The old record remains intact. The webhook, membership and
original event scope must still be authorized; otherwise the request is rejected.
GET /admin/webhooks/:id/deliveries/:delivery_id with the original
X-Webhook-Signature returns the exact signed JSON payload. Bearer authentication
and current webhook ownership are required in addition to the signature. This
allows automation platforms to verify the original bytes even if they transform
incoming JSON. A missing/bad signature, disabled subscription or revoked event
access returns 404. Delivery records are retained for seven days from creation;
pending retries remain until they finish.
OAuth clients can manage only the subscriptions owned by their own connection. Disconnecting a connection deactivates those subscriptions and revokes all its authorization grants and access/refresh tokens.