Theme

Broadcasts API

A one-off send: its own email, a segment, and a time. Membership is resolved when it sends, not when it's scheduled.

Method & pathWhat it does
GET /api/v1/broadcastsAll of them. Filter with ?status=.
POST /api/v1/broadcastsCompose one. Body: name, segment_id, email_source, email_id, delivery.
GET /api/v1/broadcasts/:idOne, with its email, segment and stats.
PATCH /api/v1/broadcasts/:idUpdate name, segment_id, delivery.
DELETE /api/v1/broadcasts/:idOnly a draft or a canceled one. 409 otherwise.
POST /api/v1/broadcasts/:id/replace_emailSwap the email, while it's still a draft or scheduled.
POST /api/v1/broadcasts/:id/scheduleBody: send_at.
POST /api/v1/broadcasts/:id/send_nowSend it. Answers with the recipient count.
POST /api/v1/broadcasts/:id/cancelCancel it and everything it has queued.

A broadcast never shares its email

email_source is required and accepts only scratch or copy. shared is refused with 422, on the server, rather than trusted to whichever client is asking.

POST /api/v1/broadcasts
{ "email_source": "copy", "email_id": 42, "segment_id": 3, "name": "July announcement" }

What one broadcast sent should stay what it sent. If a broadcast pointed at a shared library row, editing a sequence step months later could silently rewrite the record of a send that already went out — so every broadcast gets a row of its own, blank or copied. This is also why emails/ in a definitions repo fills up with rows that exist for one send: expected, not drift, and the used-in filter is how you tell them apart.

The email can only be swapped or forked while the broadcast is still a draft or scheduled. Once it's sending or sent, its email is history.

Delivery

ValueWhat happens
mimeo Fans out through the ordinary paced queue. Guards, send windows and tracking all apply, and the broadcast gets a full report. Works with any adapter.
provider Hands off to the provider's own bulk pipeline, where offered — it arrives as an unapproved draft to review and send there. Because the provider does the sending, it records opens and clicks, so this broadcast's report here stays empty.

Only offered when the configured adapter declares broadcast_send. An adapter without a bulk pipeline isn't a limitation — the fan-out path is the one with the better reporting anyway.

Audience

Resolved at send time from the segment's live rules, not stored when you schedule. A segment that grows between now and Friday means more recipients on Friday. Unsubscribed people are excluded, and the standing suppression guard checks again for every individual send.

Broadcasts are runtime rather than authoring, so they don't appear in a definitions repo — though the emails they mint do.

See also: Emails API · Segments API · Broadcasts, for humans