Cloud API vs On-Premises: the decision almost no one understands that costs money every month

The differences that matter day-to-day

Putting technical vocabulary aside, six differences appear in operation:

• Who maintains the server. In Cloud API, Meta. In On-Premises, you or your provider — including version updates, which had deadlines and became urgent if forgotten.
• Updates and new features. New features arrive first on Cloud API. Those on the old model receive fewer and later updates.
• Peak scaling. In Cloud API, capacity is Meta’s. In On-Premises, large sends required scaling machines, and lack of capacity caused stuck queues.
• Infrastructure cost. Cloud API has no server cost. On-Premises added machine, database, backup, and maintenance team costs.
• Where messages pass through. In Cloud API, through Meta’s infrastructure. This was the main argument for those defending the old model in sectors requiring local data.
• Support. In Cloud API, platform problems are Meta’s problem. In On-Premises, the first question was always whether the error was in your container.

Who used On-Premises and why

Three reasons supported choosing the old model, and it’s worth understanding them because they explain some companies’ resistance to migrate.

The first was regulatory or internal requirements about where data travels and is stored, common in banking, healthcare, and public sectors. The second was latency and integration with internal systems: companies with heavy ERP and custom rules preferred having the WhatsApp component close to the rest of the architecture. The third was simply history — those who started before Cloud API existed built everything on that model and had no reason to change while it worked.

What changed is that the first two reasons lost strength over time as Meta expanded controls and processing options, while the cost of staying on the old model rose: fewer features, less support, and a running discontinuation deadline.

How to know which one you have today

Most companies don’t know because they hired a provider and never asked. Three quick ways to find out:

• Ask the provider directly, in writing: "Is my number on Cloud API or On-Premises?" The answer should be straightforward.
• Look at Meta’s dashboard. In the WhatsApp Business account manager, the number appears linked to the business account, and the configuration method gives clear clues.
• Observe the symptoms. If new features take a long time to arrive, if there was a container version update notice, or if the provider talks about "our WhatsApp server," it’s probably the old model.

Knowing this matters for a practical reason: if you are On-Premises, a migration is ahead, and it’s better to plan it than be caught by a deadline.

How migration works

Migrating from On-Premises to Cloud API is not changing your number or starting from scratch, but it’s not a button either. In general terms:

• the number is migrated within the same business account, keeping the same phone for the customer;
• approved templates are linked to the account, not the server, and remain available;
• the integration must point to the new address, and the webhook must be reconfigured;
• there is a short downtime window during the switch, which must be coordinated with operations;
• the number’s quality and sending limit follow the account, not the server.

The biggest point of attention is conversation history. It lives in the system you use, not the API — and that’s exactly why the choice of system matters more than hosting. Companies that handled conversations directly via API, without CRM, often discover during migration that they have no history to carry over.

What doesn’t change between the two models

This is the part that surprises those expecting Cloud API to solve problems that aren’t its responsibility. They remain exactly the same in both models:

• Meta’s rules. Approved templates to start conversations, service windows, message categories, and usage policies apply equally.
• Charging per conversation. Meta’s pricing model is the same and does not depend on hosting.
• Quality and sending limits. The number’s tier and quality rating follow the account and do not improve by switching models.
• Blocking and banning. The customer reports, and the consequences are the same.
• Opt-in. Permission to send is still required; it’s not a technical detail but a rule.

In other words: if your current problem is rejected templates, low-quality numbers, or blocked sends, switching from Cloud API to On-Premises or vice versa doesn’t solve anything.

Security and data: what each model really delivers

This was the strongest argument for On-Premises and remains the most misunderstood. The intuitive idea is that keeping the server in-house means data "doesn’t leave the company" — and that was never true. In either model, messages travel through WhatsApp’s network, are delivered by Meta’s infrastructure to the client’s device, and are subject to platform policies.

What changed in On-Premises was where the component that intermediated sending was located and where content was processed in that specific segment. For sectors with regulatory requirements about local processing, this made a real legal difference. For the vast majority of companies, it made no practical difference, and the feeling of control came with a greater risk: poorly maintained servers without updates and with improvised backups are less secure than managed infrastructure.

Today, the useful conversation about security has shifted. It’s no longer about API hosting but about who has access to conversations in the system you use: is there user permission control, can agents export the entire database, what happens when a salesperson leaves the company, who can see another agent’s conversations, and how is the audit trail recorded. That’s where leaks really happen — through unauthorized access from insiders, not the network segment between you and Meta.

Why the provider matters more than the hosting

From the user’s perspective, Meta’s hosting is invisible. What you see every day is what’s on top of it: the service interface, history, automation, reports, support speed, and integration stability.

Two companies can be on the same Cloud API and have opposite experiences because one has a system that stores conversations, distributes leads, automates responses, and shows results, while the other has a generic inbox that loses messages when the browser closes. The hosting is the same; the business is not.

When choosing, the questions that really change the outcome are: is the history mine and can I export it; how many agents can use the same number; is there real automation or just auto-reply; does the system show first response time and conversion; and how long does support take to respond when sending stops on a Friday night.

Coexistence, QR Code, and why that’s another conversation

A common confusion mixes three different things: Cloud API, On-Premises, and unofficial solutions based on QR Code scanning. The first two are official API hostings. The third is not an official API at all — it’s software that connects to WhatsApp as if it were a paired phone.

The practical difference is big. With the official API, there is a contract, approved templates, charging per conversation, support, and predictability. With QR Code connection, there is no prior message approval or cost per conversation, which attracts many, but there is also no guarantee: the number can be blocked at any time, without notice or appeal, and the sending behavior is exactly what triggers blocks most.

There is also coexistence, which allows using the WhatsApp Business app and the official API on the same number, with rules defined by Meta. It solves a specific problem — keeping history and mobile use while the company transitions to the API — and does not replace the hosting decision.

The correct way to see it is two independent axes. One is the channel: official or unofficial. The other, within official, is hosting: Cloud or On-Premises. Mixing the two axes leads to bad decisions, like choosing QR Code thinking it’s "the cheap version of the official API" when it’s actually a different category, with different risks and none of the guarantees that make a company choose the official path.

The real cost of each model

Comparison for an average operation, with one number and about six thousand conversations per month:

• Cloud API: cost of conversations charged by Meta + monthly fee for the service system. Infrastructure: zero.
• On-Premises: cost of conversations charged by Meta + monthly fee for the system + server and database + backup + technical team time for updates and monitoring.

In a real operation with a modest dedicated server, backup, and about four hours of technical work per month, the old model added between R$ 600 and R$ 1,400 per month in costs that simply don’t exist in Cloud API — without delivering anything extra for customer service. For companies with specific data processing requirements, this cost was justified. For all others, it was pure cost.

The most common mistakes in this decision

• Thinking hosting solves number quality or rejected template problems.
• Choosing a provider based on monthly price without asking if history is exportable.
• Delaying On-Premises migration until it becomes an urgent deadline.
• Migrating without reconfiguring the webhook and going days without receiving messages.
• Not coordinating downtime window with the service team.
• Confusing Cloud API with the WhatsApp Business app, which are completely different things.

Where to start

If you’re starting now, the answer is simple: Cloud API, with a provider that delivers your history and exportability. If you already operate, find out in writing which model you have; if it’s On-Premises, ask the provider for a migration plan with date, window, and who will reconfigure the webhook; and use the migration to review what really matters — if your system stores history, if automation works, and if you can measure response time and conversion. Hosting is a one-time decision; the system on top is what you use every day.