support.conversation.resolved

Resolving is not closing. The thread and its full history are kept, and it reopens by itself the moment the member writes again — which raises support.conversation.reopened.

When this fires

A conversation is marked resolved from the dashboard inbox, the REST API, Zapier, n8n, or the resolve_support_conversation MCP tool.

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.resolved",
  "created_at": "2026-08-20T10:12: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.resolved` 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 was resolved.
`data.project_id`	string ULID	Mirrors the envelope `project_id`.
`data.subscriber_id`	string ULID	The member the conversation belongs to.

Caveats

Resolving does not notify the member. If you want them to know the matter is closed, send a reply before resolving.
The event fires even if the conversation was already resolved. Deduplicate on id.
A resolved conversation still counts toward the member's history and still appears under the Resolved tab in the inbox — it is filtered out of the open queue, not deleted.

support.conversation.reopened — what happens when the member writes back.
support.message.sent — the reply that usually precedes resolving.
Support events overview — back to family overview.