Two ways to send WhatsApp from software, and how to choose
There are two ways to send a WhatsApp message from software, and they are not variants of each other. Meta's Cloud API is official, needs your business verified, needs a dedicated number, and charges per conversation. The Web protocol is what WhatsApp Web speaks, works with the number already in your pocket, needs no approval, and carries no per message fee. Almost everything else follows from those two sentences.
Most comparisons of the two are written by somebody selling one of them. This one is written by people who run both, so it says what each is bad at.
The short version
| Web protocol | Cloud API | |
|---|---|---|
| Approval needed | None. Link a number by scanning a QR code. | Business verification with Meta. Days to weeks. |
| The number | One you already own and your customers already message. | A dedicated number that cannot also be on the WhatsApp app. |
| Cost per message | None from Meta. | Meta charges per 24 hour conversation, by category. |
| Sending outside 24 hours | Possible, and the fastest way to get a number banned if you abuse it. | Only with a template approved in advance. |
| Official support | None. Meta does not certify or support it. | Yes, it is Meta's own product. |
| Stability | Meta can change the protocol. Providers follow. | Versioned, deprecated on a schedule. |
| Green tick | No. | Possible, separately, after verification. |
What the Cloud API actually costs you
The per conversation fee is the part people quote, and it is usually the smallest part. The real costs are the ones that come before you send anything.
Business verification
Meta wants a legal entity, a matching website, and documents that agree with each other. Businesses that are real and small fail this regularly - not because they are suspect, but because their registration name and their trading name differ by a word, or their utility bill is in a landlord's name. Budget weeks, not days, and budget for a rejection.
A number your customers have never messaged
This is the one that surprises people. A number on the Cloud API cannot also be signed in to the WhatsApp app. If the number on your posters is the one your staff answer on their phone, you cannot move it to the Cloud API and carry on. You get a second number, and then you have the problem of telling several thousand people to use it.
Templates, in advance
Outside a 24 hour window opened by the customer's own message, the Cloud API will only send a template you registered in advance and Meta has reviewed. That is fine for "your order has shipped". It is useless for "sorry, I misread your message, the blue one is in stock" - which is most of what a real conversation is. See the article on templates for what they can and cannot contain.
What the Web protocol actually costs you
The honest answer is: certainty. Nobody at Meta has promised it will work tomorrow.
- It is not official. No SLA, no support queue, no roadmap. When Meta changes the protocol, your provider has to catch up, and until they do you are down.
- The number carries the risk. Behaviour that looks like bulk marketing gets numbers banned, and the ban lands on your number rather than on your provider. What actually triggers it is worth reading before you send anything at volume.
- It needs the phone to stay linked. A linked device is a session. Sessions end - the phone is reset, somebody logs out all devices, the number is re-registered elsewhere - and sending stops until it is linked again.
- No green tick, ever. The verified badge is a Cloud API and Business Manager matter.
Meta does not certify the Web protocol, and no vendor can honestly tell you it does. Anyone implying it is official is either confused or hoping you are. What is true is that it uses a number you own, linked the same way you would link WhatsApp Web on a laptop, and that millions of people speak that protocol every day through Meta's own clients.
How to choose, in three questions
- Is the number your customers already use the one you want to send from? If yes, the Cloud API cannot do it. That decides it more often than anything else on this page.
- Are you sending to people who did not write to you first? If yes, you want templates and the Cloud API, and you want to read Meta's rules on opt-in properly. Doing this on the Web protocol is how numbers die.
- Does an outage cost you more than the setup? A bank, a hospital, an airline: take the Cloud API and the verification pain. A shop answering forty conversations a day: the Web protocol is the one that will actually be running next week, because it needed nothing from Meta to start.
The thing both rails share
Whichever you pick, the 24 hour window is the shape of business messaging. On the Cloud API it is enforced by Meta and priced. On the Web protocol it is enforced by consequences: message people who did not ask and the number goes. The window is not a technical limitation to route around. It is the product working as intended, and building on the assumption that you can broadcast whenever you like is how a messaging project fails six months in.
Njiwa runs both rails behind one API, which is a position that lets us say all of the above without a stake in the answer. The rails page has the same comparison in product terms, and the docs show the code, which is identical either way.
Questions people actually ask
Is the WhatsApp Web protocol against WhatsApp's rules?
It is not the official Business API and nobody should tell you it is. It is the protocol WhatsApp Web and the desktop app speak, using a number you own and have linked yourself. Meta does not certify it, does not support it, and can change it. That is the trade, and you should make it knowingly rather than because a vendor implied there was no difference.
Can I move from one rail to the other later?
Yes, and the code does not change if your provider abstracts both behind one API. What changes is the number: the Cloud API needs a number that is not already on the WhatsApp app, so moving usually means a new number and telling your customers about it.
Which one do I need for order notifications?
Either sends them. The question is whether the customer wrote to you in the last 24 hours. Outside that window the Cloud API needs an approved template and the Web rail is messaging from a number that has to behave like a person. Neither is a licence to send unsolicited bulk.
Njiwa
One inbox for WhatsApp, Facebook and Instagram, and an API that sends over either WhatsApp rail. 7 days free, no card.