---
title: "A member starts their first support conversation on a channel."
method: POST
path: "support.conversation.opened"
tags: ["support.* events"]
---

# A member starts their first support conversation on a channel.

`POST support.conversation.opened` (webhook)

### 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](https://docs.subscriby.net/api/v1/reference/support-inbox).
- 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.

## Headers

- `SB-Signature` string, required
- `SB-Event-Id` string, required
- `SB-Event-Name` string, required
- `Content-Type` string, required
- `User-Agent` string, required

## Payload

- object: The envelope every event is delivered in.
  - `id` string, 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.opened', required: The event name, always `support.conversation.opened` here.
  - `created_at` string, date-time, required: When the event was emitted, server time, ISO 8601.
  - `api_version` string, required: The contract version of the payload shape, `2026-05-01` today. A breaking change to a shape ships under a new version.
  - `project_id` string, uuid, nullable, required: The project the event belongs to; null for team-scoped and billing events.
  - `data` object, required: The event-specific payload. Keys that do not apply to a given emission are omitted rather than sent as null, so check for presence.
    - `conversation_id` string, uuid, required: The new conversation. Use it against the support API to read the message.
    - `project_id` string, uuid, required: Mirrors the envelope `project_id`.
    - `subscriber_id` string, uuid, required: The member's project-scoped user id.
    - `channel` string, required: The key of the connector the member wrote through (`telegram` for the Telegram connector). A member who writes through two connectors has two conversations.

## Acknowledgement `2XX`

Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.

## Other responses

- `default`: 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.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)