---
title: "A broadcast started sending, carrying the audience it resolved to and how many members it will reach."
method: POST
path: "broadcast.queued"
tags: ["broadcast.* events"]
---

# A broadcast started sending, carrying the audience it resolved to and how many members it will reach.

`POST broadcast.queued` (webhook)

### When this fires

A broadcast began sending. The audience has been resolved to a concrete set of recipients and the first message is on its way.

This fires for broadcasts started **anywhere**: the dashboard, the bot, the REST API, a Zap or an n8n workflow. The event is emitted by the sending job itself rather than by each entry point, so every route announces a broadcast identically.

> **This is the start, not the outcome.** Delivery runs at roughly 28 messages a second to stay inside the platform's rate limit, so a large broadcast is still sending long after this arrives. Subscribe to `broadcast.completed` for the tallies.

### Caveats

- `recipient_estimate` is the count **at the moment sending began**. Someone who joins mid-send is not included, and someone who blocks the bot mid-send is still counted here but will appear in `failed` on completion.
- A member is only a recipient if they have a linked chat **on that project's bot**. A member with no chat, or one attached to a different bot, is silently excluded, which is why the estimate can be far lower than the project's member count.
- The message body is **not** in the payload. Broadcasts are not persisted, and a body can be up to 4096 characters of arbitrary creator content; repeating it on every subscribed endpoint would leak it to integrations that only need to know a send happened.
- If the audience resolves to zero recipients this still fires, immediately followed by `broadcast.completed` with `sent: 0`.

### Related events

- `broadcast.completed`: the outcome, with sent and failed tallies.
- [Broadcasts](https://docs.subscriby.net/api/v1/reference/broadcasts): send one programmatically.

## 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` 'broadcast.queued', required: The event name, always `broadcast.queued` 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.
    - `project_id` string, uuid, required: Same project, repeated inside `data` so a consumer reading only the data object is self-sufficient.
    - `audience` string, required: The segment addressed. One of the values in the audience segments table above.
    - `pass_window_id` string, uuid, nullable, required: Set only for the two single-window pass segments; `null` for every other audience.
    - `plan_id` string, uuid, nullable, required: The plan the segment was narrowed to, if any. `null` when unnarrowed or when the segment cannot be narrowed.
    - `expiring_within_days` integer, nullable, required: The horizon used, set only for `expiring_soon`; `null` for every other audience.
    - `recipient_estimate` integer, required: How many members the resolved query matched at send time.

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