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.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
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.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
How is this guide?
Last updated on