support.conversation.blocked
A creator silences a member's support messages.
When this fires
A creator blocks the member behind a support conversation:
- Dashboard: Block member in the thread's header menu in the support inbox.
- REST:
POST /v1/support/conversations/{conversation}/block. - MCP: the
block_support_contacttool.
It does not fire when:
- The conversation is already blocked. Blocking twice writes nothing the second time and emits nothing; the call is idempotent.
- A member is banned from the project. That is
member.banned, a different mechanism that removes access rather than silencing a thread. - The member's message is dropped because of rate limiting. Flood protection is automatic and raises no event.
A block lives on the conversation, not the member. It silences their support traffic only: the member keeps their subscription, their access and every other interaction with the bot, and they are given no indication that anything changed.
Caveats
- Blocking does not resolve the thread. Its
statusis whatever it was (open,pending,snoozedorresolved) and stays that way until someone changes it. If you keep a queue in sync, treat a blocked thread as one that will receive no new inbound messages, not as a closed one. - From this moment the member's messages are dropped at ingestion. No
support.message.receivedfires for them, and a blocked member's message cannot reopen a resolved thread, so nosupport.conversation.reopenedfires either. - The block is scoped to this thread. There is one conversation per member per channel, so a member who also writes in over another channel has a separate thread with its own block state.
- The member's history is untouched. Every message they sent before the block stays readable over the API and in the dashboard.
Related events
support.conversation.unblocked: the block is lifted.support.message.received: what stops arriving for this member while the block is in place.member.banned: removing a member's access, which is not what a block does.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Request Body
application/json
The signed JSON envelope posted to your endpoint.
TypeScript Definitions
Use the request body type in TypeScript.
The envelope every event is delivered in.
Response Body
Example Requests
/support.conversation.blockedHow is this guide?