support.* events

A resolved support conversation becomes active again.

When this fires

A conversation that was resolved goes back to open. Two paths:

  1. The member writes again. Their inbound message reopens the thread automatically, raising this event alongside support.message.received. This is the usual cause.
  2. A creator reopens it explicitly: from the dashboard inbox, with POST /v1/support/conversations/{id}/reopen, with the reopen_support_conversation MCP 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, pending or snoozed. Only a resolved thread reopens on inbound. A creator reopening a thread by hand fires the event whatever the thread's previous status was, including open.
  • 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.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.

Related events

  • support.conversation.resolved: the state this event reverses.
  • support.message.received: fires alongside on the member-writes-back path.
postWebhooksupport.conversation.reopened

Headers

SB-Signaturestring required

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=.

SB-Event-Idstring required

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.

SB-Event-Namestring required

The event name, the same as the envelope's type.

Content-Typestring required

Always application/json.

User-Agentstring required

Always Subscriby-Webhooks/1.0.

Payload

idstring required

A ULID unique to the event, prefixed evt_. Every retry carries the same id, so it is the key to deduplicate on.

type'support.conversation.reopened' required

The event name, always support.conversation.reopened here.

created_atstring date-time required

When the event was emitted, server time, ISO 8601.

api_versionstring required

The contract version of the payload shape, 2026-05-01 today. A breaking change to a shape ships under a new version.

project_idstring uuid nullable required

The project the event belongs to; null for team-scoped and billing events.

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.