---
title: "A broadcast finished sending, carrying the delivered and failed tallies."
method: POST
path: "broadcast.completed"
tags: ["broadcast.* events"]
---

# A broadcast finished sending, carrying the delivered and failed tallies.

`POST broadcast.completed` (webhook)

### When this fires

Every recipient in a broadcast has been attempted and the send is over. The payload carries what actually happened.

> `sent` means **the platform accepted the message**, not that a human read it. There is no read receipt, and a delivered message sitting in a muted chat counts as sent.

### Reading the failure count

A steady trickle of failures is normal and not actionable: the overwhelming majority are members who blocked the bot or deleted their account on the platform. Those are permanent; the sender detects them and stops retrying that recipient rather than burning attempts.

What *is* worth alerting on is a sudden change in the ratio. `failed` climbing from ~2% to ~40% between two broadcasts usually means the bot's credentials were revoked or the bot was removed from the project's resources, not that forty percent of an audience left at once.

`sent + failed` can be lower than the `recipient_estimate` reported by `broadcast.queued`: a recipient with no chat row is skipped without counting as either.

### Caveats

- Fires once per broadcast, at the end. A broadcast the platform rate-limits heavily can take minutes to finish; there is no progress event in between.
- If the sending job is released and retried after a long rate-limit, the tallies count the **completed run** only.
- A broadcast aborted before sending (no connected bot, an unknown audience, an empty body after sanitisation, or an audience the plan no longer includes) emits neither this nor `broadcast.queued`. Nothing was sent, so nothing is announced. The REST API refuses those cases up front with a `422` rather than accepting a send that will never leave.

### Related events

- `broadcast.queued`: the start, with the recipient estimate.

## 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.completed', required: The event name, always `broadcast.completed` 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.
    - `pass_window_id` string, uuid, nullable, required: Set only for the two single-window pass segments.
    - `plan_id` string, uuid, nullable, required: The plan the segment was narrowed to, if any. `null` when unnarrowed.
    - `expiring_within_days` integer, nullable, required: The horizon used, set only for `expiring_soon`.
    - `sent` integer, required: Messages the platform accepted.
    - `failed` integer, required: Recipients that could not be reached after the per-message retries were exhausted.

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