Compliance · 5 min read
Broadcast Lists and API Broadcasts Are Not the Same Thing
Two completely different things are called broadcast, and almost every argument about broadcast automation is really two people describing different products to each other.
Getting this straight takes five minutes and saves a business from buying a platform to do something the free app already did, or — much worse — from assuming the platform behaves like the app and messaging a thousand people who never agreed to hear from them.
Product one: the Broadcast List in the Business app
The WhatsApp Business app is the free application a shop owner installs on a phone. Inside it there is a feature called a broadcast list: you pick contacts, you write a message, and each of them receives it as an ordinary individual message rather than as a group.
The important properties of that feature are the boring ones.
- It lives on one phone. The list is a thing on that device. It is not an account-level object, and it does not follow you to another handset by itself.
- Recipients must have the sending number saved in their own contacts for the message to reach them. That is Meta's rule for this feature, and it is the whole reason the feature is tolerable.
- There is no automation surface. No API, no trigger, no scheduler. A human opens the app and taps send.
- The size is capped, and the cap is Meta's to change. Do not plan a campaign around a number you read in an article.
- Replies come back as normal one-to-one threads, which is genuinely useful and genuinely unmanageable past a certain volume.
That saved-contact requirement is doing more work than most people notice. It is a crude consent proxy. Somebody who saved your number has, at some point, deliberately chosen to keep it. It is not consent in any legal sense, but it means the app cannot be used to reach strangers, which is why the feature survives.
Product two: template messaging on the Business Platform
The Business Platform — the Cloud API — is a different product with a different shape. There is no "broadcast list" object in it at all. What exists is the ability to send a pre-approved message template to phone numbers your system holds.
That difference matters in four ways.
Templates are submitted to Meta and approved or rejected. You do not write a message and send it. You write a template, wait, and then send instances of it. Free-form text is only permitted inside a conversation that the customer opened.
Messages are categorised, and the category decides both what is allowed and what it costs. The categories, their definitions and their rates are Meta's, and Meta revises them.
Sending is metered and rate-limited. How many people a business may message in a period is a number Meta assigns and adjusts, and it moves with how recipients react to what you send.
There is no saved-contact gate. Nothing stops the API from delivering to a number that has never heard of you except your own conduct and Meta's enforcement after the fact. The guardrail the free app had is gone, and it is replaced entirely by your consent record.
So the consent question stops being optional
On the free app, the person had your number saved. On the platform, you are holding a list, and the only thing that makes sending to it defensible is how the numbers got there.
A number is not permission. A number collected at checkout is permission to talk about that order. A number collected for a delivery is permission to talk about the delivery. Neither of those is permission to send an offer on Diwali.
A record you can defend
Not a record
The practical version of this is that opt-out has to work, immediately, and it has to work when somebody types STOP in Hindi, in Hinglish, in anger, or as band karo. A person asking to be left alone who then receives another message is the exact event that damages a business number, and there is no recovering the goodwill afterwards.
What people actually want when they ask for broadcast automation
Usually one of three things, and only one of them is broadcast.
They want to tell existing customers about a genuine service event — a shop closing early, a batch delayed, a class moved. That is a real use, it is about something those people are already involved in, and it is the case the channel handles best.
They want to send an offer. That is marketing, it needs marketing consent and an approved template, it costs money per conversation, and it is the use that gets numbers reported.
Or they want to reach people who have not bought yet — which is not broadcast at all, because those people never gave a number. That is an acquisition problem, and it is solved somewhere else entirely.
Where this stands today
PostEngage answers Instagram comments and DMs. There is no WhatsApp in the product, and there is no broadcast on any channel — nothing in it sends a message to a list of people. Everything the product does starts with somebody contacting the account first.
If the underlying question is about consent mechanics on this channel, opt-in practices deserve their own read. If it is about which of the two products above a business actually needs, the app-versus-API comparison is here, and the India overview sets out what governs both.
