support.conversation.reopened
A resolved support conversation becomes active again.
When this fires
A conversation that was resolved goes back to open. Two paths:
- The member writes again. Their inbound message reopens the thread automatically, raising this event alongside
support.message.received. This is the usual cause. - A creator reopens it explicitly: from the dashboard inbox, with
POST /v1/support/conversations/{id}/reopen, with thereopen_support_conversationMCP tool, or through the Reopen Support Conversation action in Zapier and n8n.
It does not fire when:
- The member writes into a thread that is already
open,pendingorsnoozed. Only a resolved thread reopens on inbound. A creator reopening a thread by hand fires the event whatever the thread's previous status was, includingopen. - The member is blocked. A blocked contact's message is dropped and cannot push their thread back into the queue.
- The member edited an older message rather than sending a new one.
The common path here is not a creator reopening a thread by hand; it is a member writing back after you resolved it. If you page an on-call rota on anything in this family, this is the event that catches the "we thought this was done" case.
Caveats
- On the member-writes-back path this event and
support.message.receivedfire for the same action. If you post to a channel on both, you will post twice; pick one as the trigger and enrich from the API. - The payload does not say which path caused the reopen. Compare the newest message's
directionover the API if it matters:inboundmeans the member came back,outboundor no new message means a creator reopened it by hand. first_response_atis not reset by a reopen. It is stamped once, for the first human reply ever in that thread, so SLA reporting across a reopen needs message timestamps rather than that field.
Related events
support.conversation.resolved: the state this event reverses.support.message.received: fires alongside on the member-writes-back path.
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.reopenedHow is this guide?