A support conversation is marked resolved and leaves the open queue.
When this fires
A conversation is marked resolved from the dashboard inbox, the REST API, Zapier, n8n, or the resolve_support_conversation MCP tool.
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.
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.
Related events
- support.conversation.reopened: what happens when the member writes back.
- support.message.sent: the reply that usually precedes resolving.
Headers
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
Response
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
Changes
Webhooks have no change history: a webhook is keyed by its event name rather than a path and method, so no recorded change can name it.