WhatsApp Cloud API vs On-Premises vs Session API

Three names turn up whenever someone searches how to integrate WhatsApp programmatically, and only two of them still send a message today. Knowing which one died, and exactly when, matters more than any feature comparison, because content describing a live three-way choice is simply out of date.

On-Premises API: the one that no longer works

Meta's own developer documentation gives the dates plainly. New On-Premises registrations stopped on July 1, 2024, with attempts returning error code 1005. The final supported client version, v2.63, expired on October 23, 2025. After that date, messages to or from numbers still registered for On-Premises stopped being delivered, full stop.

While it existed, On-Premises was Meta's self-hosted option: a business or a BSP ran the API client on its own servers rather than Meta's, over a REST interface rather than the Graph API, with one phone number per deployment. Figures on exactly how much lower its throughput was compared to Cloud API are inconsistent across sources — some cite roughly 250 messages per second on On-Premises against 1,000 on Cloud API, others cite 70 per second single-connect and 250 multi-connect on On-Premises against 500 on Cloud API. Meta's own sunset page does not restate the throughput numbers, so treat any specific figure you see for the retired platform as approximate rather than settled.

If you have inherited a codebase pointing at On-Premises, it is not sending anything, and it has not been for some time. The only fix is migrating the number to Cloud API. Meta supports moving a number across without changing what customers see, so this is recoverable, but nobody does it automatically for you, and the longer a dead integration goes unnoticed, the more silently-failed messages pile up behind it.

Cloud API: the official platform, by elimination

With On-Premises gone, "WhatsApp Business API" and "WhatsApp Cloud API" mean the same thing. This is Meta's hosted platform: you register a phone number inside a Meta Business Portfolio, submit message templates for approval by category (marketing, utility, authentication), and anything sent outside a 24-hour window since the customer's last message has to be one of those approved templates. Inbound messages arrive as webhooks.

The constraints that catch people off guard: an unverified portfolio can message 250 unique customers per rolling 24 hours, climbing to 1,000, then 10,000, 100,000 and unlimited as verification and send history improve, with those limits applying at the portfolio level rather than per number since October 2025. Each number also carries a quality rating, green, yellow or red, driven by blocks and spam reports, and a yellow or red rating stalls or cuts your sending capacity regardless of your tier. You can access it directly through Meta's developer console or through a BSP like Twilio, 360dialog, Gupshup or Wati, who add tooling and a markup on top of the same underlying platform. Our Cloud API vs session-based APIs breakdown goes much deeper into the mechanics, cost modeling and real-world scenarios than this comparison has room for.

Session API: the unofficial third option that actually still works

This is the category that often gets left out of "types of WhatsApp API" articles entirely, or confused with On-Premises because both involve running your own infrastructure. They are not the same thing. A session API connects as a linked companion device through WhatsApp's multi-device protocol, the same mechanism WhatsApp Web itself uses, authenticated by scanning a QR code rather than registering a business number with Meta.

Underneath, these run on libraries like Baileys, whatsapp-web.js or whatsmeow, wrapped by self-hosted tools like WAHA and Evolution API or by hosted flat-rate providers. What you get is a normal, scriptable WhatsApp account: no templates, no message categories, no 24-hour window, no per-message fee, and group behavior that matches your phone rather than the eight-participant cap Cloud API's official groups carry. What you give up is Meta's sanction. This runs outside WhatsApp's terms of service for automated use, and enforcement is unpredictable account restriction rather than a documented rate limit.

Side by side

Choosing between what's actually left

Choose Cloud API if you need the verified badge, click-to-WhatsApp ads, catalogs or payments, you are messaging consumers at marketing scale, you operate in a regulated industry needing an audit trail, or delivery guarantees matter because a missed message means a failed OTP.

Choose a session API if the traffic is internal, operational or conversational, you want to keep a number your customers already know without a migration, you are running many client numbers as an agency and ten Cloud API onboardings is not worth it, or per-message billing makes the economics of your use case absurd before you even start. Our 2026 pricing breakdown shows exactly where that math tips.

On-Premises is not a choice anymore. The only decision left regarding it is how fast you migrate off it, not whether to adopt it.

If you're migrating off On-Premises right now

Moving to Cloud API keeps your number and its history; Meta's migration path does not require customers to re-add you. You will need to re-create your message templates under Cloud API's approval system, since On-Premises templates do not carry over automatically, and you should expect your quality rating to effectively restart, so send volume gently rather than resuming your old broadcast cadence on day one.

Moving to a session API instead is a different kind of migration: there is no template system to rebuild, but you are accepting the terms-of-service exposure that Cloud API and On-Premises both avoided. That trade only makes sense if the traffic itself (internal alerts, support conversations, low-volume operational messages) was never a good fit for templates in the first place. Our guide to avoiding a WhatsApp number ban covers the sending behavior that actually drives enforcement if you take that route.