support.conversation.reopened

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.

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, the REST API, Zapier or n8n.

It does not fire when:

The conversation was already open, pending or snoozed. Only a resolved thread can reopen.
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.

Required ability

support-conversation:view — token must carry this at mint time to subscribe an endpoint to this event.

Payload

{
  "id": "evt_01HX...",
  "type": "support.conversation.reopened",
  "created_at": "2026-08-20T14:30:00Z",
  "api_version": "2026-05-01",
  "project_id": "prj_01HX...",
  "data": {
    "conversation_id": "sup_01HX...",
    "project_id": "prj_01HX...",
    "subscriber_id": "usr_01HX..."
  }
}

Field reference

Field	Type	Notes
`id`	string ULID	Unique event id, prefixed `evt_`. Use for idempotent processing.
`type`	string	Always `support.conversation.reopened` for this event.
`created_at`	ISO 8601 timestamp	Server-side emission time.
`api_version`	string	Webhook API contract version.
`project_id`	string ULID	Project this event belongs to.
`data.conversation_id`	string ULID	The conversation that reopened.
`data.project_id`	string ULID	Mirrors the envelope `project_id`.
`data.subscriber_id`	string ULID	The member the conversation belongs to.

Caveats

On the member-writes-back path this event and support.message.received fire 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 direction over the API if it matters: inbound means the member came back, outbound or no new message means a creator reopened it by hand.
first_response_at is 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.

support.conversation.resolved — the state this event reverses.
support.message.received — fires alongside on the member-writes-back path.
Support events overview — back to family overview.