support.conversation.opened
A member starts their first support conversation on a channel.
When this fires
A member sends your project bot a message it does not recognise as a command, an access code, or an answer the bot was waiting for, and they have no conversation on that channel yet. Subscriby creates the conversation and emits this event, immediately followed by support.message.received for the message itself.
The message can be text, a photo, a document, a voice note or any other supported media. A bare photo with no caption opens a conversation just as text does.
It does not fire when:
- The member already has a conversation on that channel, even a resolved one. A resolved thread reopens and raises
support.conversation.reopenedinstead. - The message was a recognised bot command, or an answer the bot was waiting for during a guided setup step.
- The member is blocked, or has tripped the inbound rate limit.
- Support is switched off for the project.
This fires once per member, per channel, ever. It is a "new contact" signal, not a "new question" signal. For every question a member asks, listen to
support.message.received.
Caveats
- The payload carries no message body and no member name. Fetch them with the conversation messages endpoint.
- The member may be a lead rather than a subscriber. Anyone who can reach the bot can open a conversation, including someone who has never paid:
data.subscriber_idresolves to a project user whose status may belead. - Opening a conversation is not the same as the creator being notified. Notification is throttled to one bot DM per conversation per five minutes, so a burst of messages produces one ping but many events.
Related events
support.message.received: fires alongside this event, for the message itself.support.conversation.reopened: the returning-member counterpart.
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