support.* events
Member support inbox — conversations opened, replied to, assigned and resolved.
A member who sends your project bot something it does not recognise opens a support conversation. These events are how that traffic reaches a helpdesk, an ops channel or an on-call rota instead of sitting in the dashboard waiting to be noticed.
No support.* payload carries the message body. That is deliberate — webhook
deliveries are logged and retried, and member text does not belong in a
delivery log. Fetch the body from the support conversations
API or with the
get_support_conversation MCP tool.
Events
support.conversation.opened
A member starts their first conversation on a channel.
support.message.received
A member sends a message into an existing conversation.
support.message.sent
Your side of the exchange goes out to the member.
support.conversation.assigned
A conversation is handed to a team member, or cleared.
support.conversation.resolved
A conversation leaves the open queue.
support.conversation.reopened
A resolved conversation becomes active again.
| Event | Fires when |
|---|---|
support.conversation.opened | A member messages a project bot for the first time on a given channel. |
support.message.received | Any inbound member message, including the one that opened the conversation. |
support.message.sent | A reply is recorded and queued for delivery. Never fires for internal notes. |
support.conversation.assigned | A conversation is assigned to a team member, or an assignment is cleared. |
support.conversation.resolved | A conversation is marked resolved from the dashboard, the API or an MCP tool. |
support.conversation.reopened | A resolved conversation goes active again — usually because the member wrote back. |
One conversation per member, per channel
There is exactly one conversation per (project, member, channel). It is a durable thread, not a per-session ticket, so:
support.conversation.openedfires once per member per channel, ever. Their second message and every message after it raisessupport.message.receivedonly.- Resolving does not close the thread. The next inbound message reopens it and raises
support.conversation.reopened. - A workflow that wants "every new member question" should listen to
support.message.received, notopened.
Example payload
Every support.* event uses the standard envelope and a flat data object of identifiers:
{
"id": "evt_01HX...",
"type": "support.message.received",
"created_at": "2026-08-20T10:05:00Z",
"api_version": "2026-05-01",
"project_id": "prj_01HX...",
"data": {
"message_id": "smg_01HX...",
"conversation_id": "sup_01HX...",
"project_id": "prj_01HX...",
"subscriber_id": "usr_01HX...",
"type": "text",
"has_attachments": false
}
}Guarantees
- The member's message body, their Telegram identity and any attachment file ids are never in the payload. Resolve them over the API with
data.conversation_id. support.message.receivedandsupport.conversation.openedboth fire on a member's first message, in that order of significance — treatopenedas the "new contact" signal andreceivedas the "new question" signal.- Internal notes raise no event at all. They are private remarks for your team and never reach the member or a webhook.
- A message from a blocked member is dropped before any event fires, and cannot reopen a resolved thread.
- Rate-limited inbound messages are dropped silently. A member flooding the bot produces no event storm.
Required abilities
Tokens subscribing to support.* events must carry support-conversation:view.
Related
- Support conversations API
- Support inbox guide
- Contacting support — the member's side
How is this guide?