---
title: "A member sends a message into a support conversation."
method: POST
path: "support.message.received"
tags: ["support.* events"]
---

# A member sends a message into a support conversation.

`POST support.message.received` (webhook)

### When this fires

Every time a member sends an inbound message that lands in the support inbox, including the very first one, which also raises `support.conversation.opened`.

This is the workhorse of the family. If you are routing member questions into a helpdesk, an ops channel or an on-call rota, this is the event to subscribe to.

It does **not** fire when:

- The text was a recognised bot command, or an answer the bot was waiting for mid-setup.
- The member is blocked. Their messages are dropped without a trace in the inbox.
- The member has tripped the inbound rate limit. Excess messages are dropped silently rather than queued.
- The member **edited** an earlier message. The stored message is updated in place and no new event fires.

> The message body is **not** in the payload. Webhook deliveries are logged and retried, and member text does not belong in a delivery log. Fetch it with [the conversation messages endpoint](https://docs.subscriby.net/api/v1/reference/support-inbox).

### Caveats

- **No body, no name, no file ids.** Everything human-readable is behind the API on purpose. Platform file ids are effectively credentials for downloading the file and are never sent in a webhook.
- An **album** (several photos sent together) arrives as one event per part, each with its own `message_id`. They share a `media_group_id` visible through the API, not in the payload.
- A captioned photo has `type: "photo"`, and the caption is the message body; it is not a separate text message.
- A caption that starts with `/` is parsed as a bot command upstream and never reaches the inbox.

### Related events

- `support.conversation.opened`: fires alongside on the member's first message.
- `support.message.sent`: your side of the exchange.
- `support.conversation.reopened`: fires alongside when the message revives a resolved thread.

## 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.message.received', required: The event name, always `support.message.received` 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.
    - `message_id` string, uuid, required: The stored message.
    - `conversation_id` string, uuid, required: Thread the message belongs to.
    - `project_id` string, uuid, required: Mirrors the envelope `project_id`.
    - `subscriber_id` string, uuid, required: The member's project-scoped user id.
    - `type` 'text' | 'photo' | 'video' | 'audio' | 'voice' | 'document' | 'sticker' | 'animation' | 'location' | 'contact', required: What kind of message arrived.
    - `has_attachments` boolean, required: Whether the message carried a structured attachment. True for media, and also for `location` and `contact`, whose attachment rows carry `file_id: null` and no file to fetch. Check `data.type` before assuming a download.

## 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)