WhatsApp Cloud API Explained: Why On-Premises Is Gone

If you ran WhatsApp support before 2024, there's a good chance you hosted the Business API yourself: Docker containers, a database to babysit, and an ops person who dreaded every version upgrade. That setup is now gone. As of October 2025, Meta retired the On-Premises API, and the Cloud API is the only supported way to run WhatsApp at business scale.

What the WhatsApp Cloud API actually is

The Cloud API is Meta's hosted version of the WhatsApp Business Platform. Instead of running the messaging client on your own servers, you send and receive messages by calling Meta's Graph API endpoints, and Meta runs all the infrastructure behind them. No servers, no container upgrades, no scaling headaches on your side.

It's worth being precise about what this is not. The Cloud API is part of the WhatsApp Business Platform, the API product built for medium and large businesses. It is not the free WhatsApp Business app you download on a phone. With the Cloud API you get a registered phone number, a WhatsApp Business Account, and programmatic access: inbound messages arrive at a webhook you control, and you reply by posting to the messages endpoint.

Cloud vs on-premises: the split that stopped mattering

For years the Business Platform came in two flavors, and picking between them was one of the first architecture decisions a team made. Now it's a history lesson. But it's a useful one, because it explains why Cloud won and what you gave up in the process.

What on-premises asked of you

• You hosted the client. Meta shipped the WhatsApp Business API as a Docker image that you ran on your own cloud or data center.
• You owned everything around it. Uptime, scaling, database backups, and every version upgrade were yours, and a missed upgrade could break messaging outright.
• You waited for features. New WhatsApp capabilities often landed on-premises months late, if they arrived at all.
• It fit a narrow profile: large enterprises with strict data-residency rules and an ops team with the appetite to run it.

What the Cloud API changed

Meta took all of that on itself. Hosting is free, scaling is automatic, and new features ship to Cloud first. A team can register a number and start sending within a day instead of standing up infrastructure for a week. The one tradeoff you accept is that messages pass through Meta's cloud rather than your own, which matters for a small set of regulated buyers and almost nobody else.

Why Meta retired self-hosting

Two reasons, mostly. Maintaining a self-hosted client that thousands of businesses ran in thousands of slightly different environments was a support burden Meta didn't want to keep carrying. And Meta wanted a single, current platform it could ship features to without waiting for everyone to upgrade first.

The shutdown was staged, not sudden. Meta stopped adding features to on-premises, then closed onboarding for new numbers, and set October 2025 as the end of support. After that point, self-hosted deployments stopped receiving updates and security patches, which in practice meant anyone still on it had to migrate or watch service quietly degrade. If you're reading this and you're somehow still on-premises, the migration isn't optional anymore.

What migrating off on-premises actually involved

For the teams that had to move, the migration was more paperwork than engineering. The core steps were familiar: register the phone number on the Cloud API, run Meta's number migration flow so you kept the same number and, in most cases, your verified display name, re-point your webhook to the Cloud endpoints, and re-test your templates. The messaging logic on your side barely changed, because the API surface is largely the same between the two. What went away was the infrastructure you no longer had to run. Sensible teams ran both in parallel for a short window, cut over once the Cloud side was verified, then decommissioned the old client.

“The API is free” is true, and also misleading

Here's a point that trips up first-time buyers. Cloud API access really is free. Meta doesn't charge you to use the endpoints or to host the client. What you pay for is messaging, billed per message by category, with user-initiated service replies falling in a free window. If you go through a Business Solution Provider, they add a platform fee on top of Meta's charges.

So “free API” is accurate and beside the point. The API is free; running a support operation on it is not. Budget for the messaging and the software layer, not the API access.

How you get access: Tech Provider or BSP

There are two doors to the Cloud API. You can go direct as a Tech Provider, registering with Meta and managing the WhatsApp Business Account yourself, which is the right call if you have engineers who want raw API control. Or you go through a Business Solution Provider, a BSP like Gupshup, Wati, or AiSensy, which handles onboarding, number registration, and billing, and usually layers a dashboard on top.

Most businesses take the BSP route because it removes the Meta-side paperwork and gives you a place to manage templates and team inboxes. Either way, the underlying pipe is the same Cloud API. The BSP is a convenience layer, not a different product.

Where AI agents sit on top of the Cloud API

This is the part people get wrong. The Cloud API is transport. It delivers a customer's message to your webhook and lets you send one back. It has no idea what the customer wants, no memory of the conversation, and no ability to check an order or issue a refund. Everything that makes WhatsApp support actually work lives in a layer above the API.

That layer is where an AI agent for WhatsApp runs. When a message hits the webhook, the agent reads it, works out intent, and if it needs to act, it calls into your systems through write-access integrations and then replies through the same Cloud API endpoint. An order-status lookup is a good example: the customer asks where their package is, the agent queries your order system, and the answer goes back over WhatsApp without a human touching it. The API is the road. The agent is the driver.

If you want the fuller picture of what that agent layer does, our guide on what a WhatsApp AI agent does walks through intent handling, escalation, and the difference between an agent and a scripted bot.

Where the Cloud API stops (the honest limits)

Two things are worth knowing before you assume Cloud solves everything.

First, data residency. Cloud API messages are processed on Meta's infrastructure, historically routed through US data centers, though Meta has since added local data storage options for some regions. If you operate in a regulated industry with strict in-country processing requirements, confirm the current residency options before you commit. This is the one area where the old on-premises model had a genuine edge, and losing it is a real cost for a small number of teams.

Second, the Cloud API gives you nothing usable on its own. No bot, no routing, no analytics, no human handoff. It's plumbing. To actually automate WhatsApp support, you still need the agent layer and the integrations that let it take action. The API is a solved problem now. What you build on top of it is the part that still matters.

Ready to put an AI agent on top of your WhatsApp Cloud API setup? Robylon resolves 60–80% of incoming conversations autonomously, with agents that take real action across your order system, CRM, and 60+ other integrations. Start free at robylon.ai