support.conversation.opened

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.reopened instead.
• 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_id resolves to a project user whose status may be lead.
• 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.

Header Parameters

The signed JSON envelope posted to your endpoint.

Response Body