The official WhatsApp API: what it actually requires, and what it only looks like it requires

For a long time the cheapest way to put a business on WhatsApp was to not ask WhatsApp. You run an open-source gateway, it speaks the same protocol the phone app speaks, and from the outside it looks like a very fast employee. I did this. The order flow behind El Camioncito — customer message in, ticket on the kitchen screen ninety seconds later — ran on Evolution API, which speaks Baileys. It worked. It worked well enough that I wrote a whole post about the plumbing.

I don't build on it anymore. The gateway isn't the problem — the ownership is. When the number is a client's livelihood, "this is unofficial and the platform may object" is not a footnote you get to leave in the appendix. So the question became the boring, correct one: what does the official path actually cost you?

The answer surprised me, and most of the surprise is that Meta's own onboarding flow overstates it. You are walked past four things that look mandatory. Two of them are.

The two that are theater, and the two that aren't

Create an app in the Meta developer console and the interface will herd you toward publishing it — a permissions checklist, a review submission, a green banner promising your app will go live. Alongside that, your business portfolio sits there marked unverified, which reads like a countdown.

Neither blocks you. A business portfolio does not need to be legally registered or verified by Meta to send and receive on the Cloud API. The app does not need to be published or reviewed as long as the number you connect is your own. What you genuinely cannot skip is smaller than the interface implies:

1. A phone number with no WhatsApp account on it. Not "a number you own" — a number that is clean. If it has ever had the consumer app or WhatsApp Business on it, you delete that account first and wait a few hours before the API will take it. The alternative is coexistence mode, which keeps the app and the API on the same number, at the cost of the API no longer being the sole owner of the conversation.
2. A display name Meta approves. This is the name your customers see. It goes through review, it can be declined, and it is subject to the same brand policies as everything else on the platform.

That's the floor. Number, name, done.

The requirement that actually gates an agency

Here is where the reading changes if you do this for other people rather than for yourself.

The exemption above — no app review needed — holds because you are the business. The moment you connect someone else's number to your app, you are onboarding a business customer, and Meta's mechanism for that is Embedded Signup. That flow is explicit: you cannot onboard business customers until your app is approved for advanced access. In development mode you can test; the moment the app goes live, only permissions cleared through App Review appear in the flow at all. The relevant ones are whatsapp_business_management, whatsapp_business_messaging, and, if you're sharing credit lines as a Solution Partner, business_management.

So there are two architectures, and picking one is a business decision disguised as a technical one:

• One app and one portfolio per client. Repeat the setup every time. Nobody verifies anything, no review, no advanced access. A number that degrades only burns that client. This is the path that stays inside the exemption.
• One app of yours, every client's number underneath it. One setup, central control, per-client provisioning through Embedded Signup — and App Review, advanced access, and a platform relationship you now have to maintain. Your blast radius is also every client at once.

The first looks like more work because it is. It's also the one that doesn't put your whole book of business behind a single app's standing.

The cap almost nobody reads correctly

New business portfolios start at 250. The number is right; the unit is what people get wrong. It is 250 unique conversations you initiate in a rolling 24 hours — not 250 messages, and not 250 conversations total.

For an inbound business this distinction is close to everything. A restaurant taking orders does not initiate conversations; customers do. Those don't count against the cap, and once a thread is open you can send freely inside it. The 250 ceiling binds outbound — reminders, campaigns, follow-ups — and a business whose traffic is customers walking up to the counter can run a long time without ever touching it.

Getting past 250 has three doors, and only two of them involve paperwork:

• Verify your business with Meta.
• Have a partner verify it for you.
• Send 2,000 delivered messages to unique users in 30 days using high-quality templates.

That third one is worth sitting with. You can reach the 2,000 tier purely by behaving well at volume, without submitting a document to anyone. Above 2,000 it stops being a form entirely: keep quality high across all your numbers, use at least half your current limit inside seven days, and the platform raises you — within about six hours — through 10,000, 100,000, and unlimited.

The window is a rolling timer, not a deadline

When a user messages you — or calls you — a 24-hour customer service window opens. Inside it you can send anything: text, images, documents, interactive flows, no pre-approval. When it closes, you can send only pre-approved templates.

The part that gets misread is that it isn't a one-shot countdown from first contact. Every time the customer replies, the timer resets to a fresh 24 hours. A conversation that keeps breathing never closes. It's a silence timer, not a session timer.

This is also the only place money enters. Templates cost, so sending them requires a payment method on the account — and if you're outside the US, put your tax ID into the payment settings, because its absence is what quietly adds tax to the bill. If your business is purely inbound and you never send a template, you can run the whole thing without ever attaching a card.

The webhook does not behave like a webhook

Most platforms hand you a URL field and start firing events. Meta does not. Three things are required and each one fails silently if you skip it:

• HTTPS. Plain HTTP is rejected outright, which means no localhost — you cannot verify the endpoint until something is actually deployed. Plan the order of operations around that, because it's a genuine chicken-and-egg during first setup.
• A challenge handshake. Meta calls your URL with a verify token and expects you to echo back the challenge value. Until that round-trip succeeds, the subscription doesn't exist.
• An explicit subscription to the messages field. This is the one that burns people. The webhook can be verified, green, and correctly configured, and you will still receive nothing, because subscribing the URL and subscribing to the event are two separate actions.

You may also see a notice saying events will only arrive once the app is published. In practice, for your own number under the exemption above, they arrive anyway.

The failure mode worth designing against

Numbers carry a quality rating — green, yellow, red — computed from how recipients react to you. Sustained spam walks it down that ladder, and past red the number is restricted: dead for the API and the consumer app, for three to six months, with an appeals process that mostly says no.

The useful thing to know is that the ladder is escalating, not binary, so it gives you warning. Yellow is a signal, not a verdict. And there's a maneuver available before the end: a degrading number can be moved to a different business portfolio, which resets its standing. That only works while it's still degrading — once it's restricted, nothing moves it but time.

If you want to see all of this from the outside, the Graph API will report a number's state, and it's worth pulling more than one field. status is what the WhatsApp Manager UI calls the number's state; code_verification_status only tells you the SMS code passed; platform_type tells you whether it's actually running on Cloud API or sitting on some legacy path; quality_rating is the ladder above; messaging_limit_tier is the cap. Read any one of them alone and you'll build a confident, wrong picture — a number can be VERIFIED on its code and still PENDING overall, which is exactly the report that makes an operator stop trusting your dashboards.

What this actually buys

Nothing here is difficult. It's a clean number, a name someone approved, a webhook with a handshake, and an honest reading of a cap that is mostly about outbound. The cost of the official path is a few afternoons and a repeated setup per client. What it buys is that the platform knows you exist and has agreed to the arrangement — which, when the number is how a business gets paid, is the entire point.

The unofficial gateway is faster to stand up and it does not survive contact with anyone asking who's responsible when it stops. That question comes up eventually. It's better to have already answered it.