A broadcast is one message sent to a large list. It sounds simple, and it is, until something goes wrong halfway through. This recipe covers how to send one that is safe to retry and honest about what happened.
Prerequisites
- An active account with a messaging service and enough capacity for the send.
- A contact list you have permission to message.
- A way to record which batch you have already sent.
A single send accepts up to fifty recipients. That is the unit you work in. A broadcast to ten thousand people is two hundred sends, not one.
- Split the list into batches of fifty or fewer.
- Give each batch an idempotency key derived from the broadcast and the batch number.
- Send the batches in sequence or with modest concurrency, and handle a failed batch by retrying it with the same key.
{
"recipients": ["+15555550100", "+15555550101", "+15555550102"],
"body": "Reminder: the office is closed on Monday. We reopen on Tuesday at 9am.",
"type": "sms"
}Idempotency-Key: broadcast-2025-06-batch-001One send is one message, not one per recipient
A send returns a receipt per recipient, so you can see which recipients were accepted. It does not tell you that each one arrived — that comes from the delivery webhook.
- It does not skip people for you beyond opt-out. There is no built-in quiet-hours window, so if you want to send only during certain hours, enforce that in your own scheduler.
- It does not schedule itself. Time the batches from your side.
- It does not segment. If you need to message a subset, build the subset before you send.
The first few words appear in the notification preview. Put the reason for the message there, not your organisation's name.
A message that fits in a single segment costs less and reads better. Long messages are split, and the split can fall in an awkward place.
A broadcast with no reply path is a dead end. If you want responses, say which keyword to use. If you do not, say that replies are not monitored.
Furcata does not restrict when you send, but recipients do. Send during the hours your audience is likely to be awake and, where the message is not urgent, during working hours.
Test on yourself first
Send the exact message to your own number before the broadcast. Reading it on a phone catches problems that a preview in a dashboard does not.
Use the reports to check what was accepted, what was delivered and what it cost. A gap between accepted and delivered is the signal worth investigating — it usually means numbers that cannot receive messages rather than a problem with the send.
For an urgent announcement, a voice message reaches people who would not look at a screen. Voice is configured in the app rather than through the REST API, and it is billed per minute.
Go further
The compliance section covers consent, opt-out and sender registration — the rules that govern who you may broadcast to.
Compliance and best practices