Skip to main content
You subscribe by passing an array of event names to subscriptions when you create or update a webhook:
Any name outside the real allowlist is rejected with a 422 (Invalid events) — see Errors.
The published OpenAPI schema’s subscriptions enum lists 8 events. The server actually accepts 12. inbox_created, inbox_updated, conversation_typing_on, and conversation_typing_off are real, whitelisted, subscribable events — they’re just missing from the generated reference’s enum. conversation_typing_on/off at least show up as checkboxes in the dashboard’s own webhook form; inbox_created and inbox_updated don’t appear there either, so the only way to know they exist is to send them and see them accepted. The table below is the real list, taken from the model validation that actually enforces it.

​
The 12 events

conversation_status_changed is the only status-related event you can subscribe to. The app has finer-grained internal events for “opened” and “resolved” specifically, used for other internal notifications — they aren’t on the webhook allowlist, so don’t try to subscribe to them by name.

​
The message gate: not every message fires an event

message_created and message_updated only fire for messages that are incoming, outgoing, or a template. Activity messages (join/leave notices, assignment changes) and private notes never trigger a webhook. If you’re trying to build an integration off internal agent notes, this event stream isn’t where that data comes from — you’d need to poll the messages endpoint and filter differently.

​
Subscriptions aren’t scoped by inbox, even if you set inbox_id

The webhook create/update payload accepts an inbox_id, and it’s stored. It doesn’t do anything to delivery. Every account-level webhook receives every event that matches its subscriptions, from every inbox in the account, regardless of what inbox_id you set on the webhook itself. If you need per-inbox filtering, do it in your own handler by reading inbox_id off the payload — see Payload schemas.
There’s a separate mechanism for a single inbox’s own webhook URL — the webhook_url configured directly on an API-channel inbox — but it isn’t managed through this endpoint and isn’t what inbox_id on a Webhook record controls.

​
Next

Payload schemas

What’s actually in the body for each of these.

Signature verification

What Tied does — and doesn’t — do to prove a payload is genuine.