WhatsApp Cloud API: What Running It Yourself Takes

Cloud API is the part of the WhatsApp Business Platform that lets software message and call on WhatsApp. Meta hosts it, so there is no server of yours in the message path. It is built on the Graph API and speaks ordinary HTTPS: you POST JSON to send, and Meta POSTs JSON back to a URL of yours when something happens. Meta documents three capabilities under it — messaging, calling and group conversations (Meta, About the WhatsApp Business Platform, 2026, retrieved 2026-10-19).

One thing worth settling early, because older guides still argue about it. As of 2026-10-19, Meta's own platform overview lists three APIs — Cloud API, the Business Management API and the Marketing Messages API for WhatsApp — and does not document a self-hosted messaging option alongside them. Which hosting model to pick is therefore no longer a decision you have to make. If a comparison you are reading spends half its length on it, the page is older than it looks.

Encryption is not something you give up by going through Meta's servers. Messages are still protected by Signal protocol encryption before they leave the device, and the API traffic itself runs over HTTPS protected by TLS. If you want the layer above this — what the platform is for and which stores need it at all — that is what the WhatsApp Business API is and who needs it. This post starts where that one stops: with what it actually takes to run.

Four Meta objects, plus credentials. None is difficult on its own; the cost is that they belong to different parts of Meta's admin surface and have to stay consistent with each other.

1. A business portfolio. The container for everything else. You cannot use the platform without one, and its verification status feeds directly into how much you are allowed to send.
2. A WhatsApp account. Your presence on WhatsApp: phone numbers, display name, usernames and the partner access configuration.
3. A Messaging account. Separate from the above, and the one that carries your message templates, billing and payment method. Confusing the two is the most common source of a setup that looks finished and cannot send.
4. A business app. Associated with the portfolio, holding the access tokens and permissions your code authenticates with.

Two rules apply from the first message, not from the first campaign. You must obtain opt-in before sending a template, and the opt-in has to name your business and state the intent. And every template needs approval before it can be sent at all. A pilot hides both of these, because Meta creates test accounts and a test business phone number for you automatically, with relaxed messaging limits and no payment method required. That is a reasonable way to learn the API and a misleading way to estimate the work.

If you would rather see what the same sequence looks like when a provider runs it, our help centre documents it end to end in connecting your WhatsApp account — about fifteen minutes of active work, plus up to two working days while Meta reviews your business.

Three different ceilings, and stores meet them in a predictable order.

The messaging limit comes first. It is the number of unique WhatsApp users you may message outside an open customer service window in a moving 24-hour period. New business portfolios start at 250. It rises to 2,000 by completing a scaling path, then to 10,000, 100,000 and finally unlimited through automatic scaling. It is set at portfolio level and shared by every business phone number inside it, so one number can consume the whole allowance (Meta, Messaging Limits, 2026, retrieved 2026-10-19).

Meta documents three ways to reach 2,000, and you only need one of them.

• Verify your business yourself.
• Have the partner who onboarded you verify it on your behalf.
• Deliver 2,000 messages to unique recipients outside customer service windows within a 30-day moving period, using templates with a high quality rating.

The third route has an obvious catch for a store starting from 250 a day, which is why verification is the one worth starting on day one rather than the day a campaign is blocked.

Throughput and pair limits come second. A business phone number sends up to 80 messages per second by default, with capacity upgrades available. Towards any single WhatsApp user the limit is far tighter: one message every six seconds, about ten a minute. You may burst up to 45 messages in six seconds, but the burst borrows from your future quota and you then have to wait it out. Exceed the rate and Meta returns a throttling error until you are back within it.

API request limits come third. Management calls are capped at 200 requests per hour, per app, per Messaging account by default, rising to 5,000 per hour once the account is active with a registered phone number. That is generous for sending and tight for anything that polls.

Rates, the current state of the 24-hour window and every figure above are kept with retrieval dates on one page: WhatsApp Business Platform prices, limits and rules. We do not restate prices inside articles, because Meta changes them on a quarterly calendar and a copy in a blog post goes stale without telling anyone.

This is the section that decides the project, and it is the one most Cloud API explainers leave out. The API moves messages. Everything a person or a shop actually works with, you build.

• There is no inbox. Every inbound message arrives as a JSON webhook payload at a URL you host. Storing it, threading it into a conversation, assigning it to a colleague, tracking read state and showing it in a usable interface is all yours. So is being reachable at three in the morning, because an endpoint that is down loses messages a customer believes they sent.
• There is no contact database. No segments, no lifecycle, no suppression list. A phone number in a webhook is a string, not a customer.
• There is no opt-in record. Meta requires opt-in before you message someone, but does not store it for you. Recording when and how each person consented, and being able to produce that record later, is your system's job.
• There is no Shopify connection. An abandoned checkout, a fulfilment event or an order status has to be wired from your shop to your sender, with its own queue, its own idempotency and its own failure handling.
• There is no template lifecycle. Templates need submitting, approving, versioning per language, and watching, because Meta re-checks categorisation and can move one from utility to marketing with short notice. A campaign that silently changes category changes price.
• There is no retry logic. Meta's guidance for a throttled send is to back off exponentially and try again. Somebody has to write that, and somebody has to be sure it does not send the same order confirmation twice.

One constraint narrows the options further: Meta's terms state that using unauthorised third-party tools is prohibited. The layer above the API has to be built by you or come from a route Meta sanctions. Picking something off a marketplace because it is cheap is not a third option. The Keaz feature overview is a reasonable way to see the size of that layer, whether or not you end up building it yourself.

Direct is the right answer in a narrow set of cases: you already run messaging infrastructure, you have engineers whose job it is, and WhatsApp is deep enough in your product that owning the integration is a feature rather than a cost. If that describes you, the documentation is good and the path is short.

For a Shopify store of one to ten people, the arithmetic rarely works. The API is not the expense; the inbox, the opt-in record, the Shopify wiring and the person who maintains them are. A provider has built that layer once and amortised it, and that is the entire economic argument — not that the API is hard to call.

We should be plain about where we stand: Keaz is on the provider side of this decision, and our WhatsApp access runs through 360dialog in Berlin. That means the comparison above is not neutral, so treat it as an argument to check rather than a verdict. If you want the criteria for picking a provider rather than the case for using one, that is a separate piece: how to choose a WhatsApp Business Solution Provider.

A note for agencies, since Meta documents it explicitly and it is easy to get wrong. Working on a client's behalf, you may either use the shared Messaging account you are given or create your own and link it to the client's shared WhatsApp account. The second keeps your templates and billing under your control; the first keeps them under theirs. Decide before onboarding, because unpicking it afterwards is genuine work.

Five that cost real time, roughly in order of how expensive they are to undo.

• Estimating the project from the test account. Test resources have relaxed limits and need no payment method. A prototype that worked in an afternoon tells you nothing about the messaging limit, template approval or the webhook endpoint you now have to keep alive.
• Planning the launch campaign before the limit is raised. A list of 4,000 subscribers meets a 250-recipient ceiling, and the fix is a business verification that takes days you have not budgeted.
• Adding a second number to raise capacity. The messaging limit sits on the portfolio and is shared across its numbers. A second number splits the same allowance; it does not double it.
• Treating templates as copy rather than assets. They are approved, categorised, priced by category and re-checked. A discount code dropped into a shipping notification turns a utility message into a marketing one, and Meta notices.
• Collecting opt-ins after the integration is live. The Cloud API arrives with no audience. Numbers are gathered at checkout, through chat-in links and in pop-ups, and that work gains nothing by waiting for the technical setup to finish.