Search "types of WhatsApp API" and half the results are still describing a landscape that no longer exists. They talk about on-premises Docker containers and self-hosted webhook endpoints as if that is a live option. It is not.
Here is the actual 2026 situation, and then the decision framework I would use.
The on-premises API is gone
Meta announced the deprecation of the WhatsApp Business On-Premises API in October 2023 and set an end-of-life date of 23 October 2025. That date has passed. The final client version expired, new number registrations were blocked before that with error code 1005, and on-premises endpoints no longer deliver messages.
If you have inherited a codebase pointing at a self-hosted WhatsApp container, it is not sending anything. The only fix is migrating the number to Cloud API. Meta supports moving numbers across without changing the customer-facing number, so this is annoying rather than catastrophic, but nobody is going to do it for you.
Meta's rationale was cost and throughput. Cloud API pushes up to 1,000 messages per second against on-premises' 250, some partners reported infrastructure cost reductions above 90 percent after moving, and Meta ships all new features to Cloud API exclusively.
So "WhatsApp Business API" and "WhatsApp Cloud API" now mean the same thing. Any article distinguishing them is describing history.
That leaves two real categories.
Category one: the Cloud API
Meta hosts everything. You talk to Graph API endpoints, Meta handles the connection to WhatsApp's network, and your business identity is registered and verified.
How it works in practice:
- You create a Meta Business Portfolio and a WhatsApp Business Account inside it.
- You attach a phone number that has never been used on WhatsApp, or migrate one in.
- You submit a display name for review.
- You write message templates and submit them for approval by category: marketing, utility or authentication.
- Anything you send to a user who has not messaged you in the last 24 hours must be one of those approved templates.
- Inbound messages hit your webhook.
Access is either direct through Meta's developer console or through a Business Solution Provider like Twilio, 360dialog, Gupshup or Wati, who add tooling and take a markup. Both paths hit the same Cloud API underneath.
The constraints that surprise people:
Messaging tiers. A business portfolio that has not completed verification can message 250 unique customers per rolling 24 hours. After verification you start at 1,000 and climb through 10,000, 100,000 and unlimited based on quality rating and send history. Since October 2025 these limits apply at the portfolio level rather than per number, so adding a second number does not double your capacity. Meta re-evaluates tier eligibility roughly every six hours now, down from 24 to 48 hours, which makes ramping faster than it used to be.
Throughput. Standard accounts get 80 messages per second. Higher throughput is available but not automatic.
Quality rating. Each number carries a green, yellow or red rating driven by blocks, spam reports and engagement over a rolling seven-day window. Yellow freezes tier progression. Red can cut your limit outright.
The 24-hour window. Free-form replies only work inside 24 hours of the customer's last message. Miss it and you are back to templates, and a casual follow-up template usually gets categorised as marketing, the most expensive tier.
Category two: session-based APIs
These connect through WhatsApp's multi-device protocol as a companion device, the same mechanism WhatsApp Web uses. You scan a QR code, the provider maintains the authenticated session, and you get HTTP endpoints on top.
The open source ancestry here is Baileys (a direct WebSocket implementation) and whatsapp-web.js (which drives a headless browser). Commercial platforms build session persistence, reconnection, queuing, webhook delivery and a dashboard around that core.
What you get is a normal WhatsApp account that happens to be scriptable. No templates. No categories. No 24-hour window. No per-message fee. Groups work the way they do on your phone rather than being capped at eight participants behind an Official Business Account gate.
What you give up is Meta's blessing. Automating a standard account this way is against WhatsApp's terms, and enforcement is by account restriction. Ban risk is genuinely unpredictable and depends far more on your sending behaviour than on your provider's marketing claims.
Side by side
| Cloud API | Session-based API | |
|---|---|---|
| Meta approval | Required (portfolio, verification for scale, display name, templates) | None |
| Time to first message | 2 to 7 days typically | Minutes |
| Facebook business account | Mandatory | Not needed |
| Pricing model | Per delivered template message, by country and category | Flat per connected number |
| Message freedom | Templates outside the 24-hour window | Anything, anytime |
| Daily send cap | 250 unverified, then 1k / 10k / 100k / unlimited | Informal, driven by spam detection |
| Throughput | 80 msg/sec standard, up to 1,000 | Provider-dependent, typically paced deliberately |
| Groups | Official API capped at 8 participants, OBA required | Native behaviour |
| Verified badge | Available | Not available |
| Catalogs, payments, CTWA ads | Yes | No |
| Terms of service | Compliant | In breach |
| Ban risk | Near zero with good practice | Real and variable |
| Existing number | Only via coexistence | Any number, including one with history |
| Uptime guarantee | Meta publishes 99.9% and a status page | Provider SLA, plus protocol drift risk |
Cost, with actual numbers
Meta bills per delivered template message. Published rates in 2026 sit around $0.025 for a US marketing message, $0.0592 in the UK, $0.1365 in Germany, $0.0625 in Brazil and $0.0118 in India. Utility rates are far lower, roughly $0.004 in the US and $0.0014 in India. On top of Meta's wholesale rate, most BSPs add $0.003 to $0.010 per message, and many add a platform fee between $29 and $299 a month.
Session-based providers charge for the connection. WaHttp runs $5 a month for one session, $12 for three, $22 for six and $35 for ten, with unlimited messages on every paid plan.
Run it through a real scenario. An e-commerce operation sending 40,000 utility messages a month across UK, Spain and Brazil, plus a weekly broadcast to 12,000 subscribers:
- Cloud API: utility traffic lands somewhere near $600 depending on how much falls inside the customer service window, marketing broadcasts around $2,600 at a blended $0.055, BSP markup near $400, plus a platform fee. Call it $3,600 to $3,900.
- Session-based: $22 for six numbers. Plus whatever the ban risk is worth to you, which is the number that actually matters.
At that volume the official platform costs about 170 times more. That sounds damning until you consider that a compliant channel with an SLA, a verified badge and Meta's ad integration is genuinely worth thousands a month to a business doing serious revenue on WhatsApp. The comparison only looks absurd if you ignore what you are buying.
Note also that Meta's free tiers are shrinking. Service messages, the free-form replies your team sends inside the 24-hour window, become chargeable on 1 October 2026 at the same rate as utility and authentication templates in that market. Utility templates inside the window lose their free status on the same date. Meta's own AI agent replies moved to token billing at $2.00 per million tokens on 1 August 2026. If you modelled your Cloud API costs on free inbound support, that model expires in six weeks.
Which one do you actually need
High-volume marketing to consumers. Cloud API. No argument. Broadcasting promotional content from a linked session is the fastest way to lose a number, and you need click-to-WhatsApp ads and the verified badge anyway.
OTPs and authentication at scale. Cloud API. Delivery guarantees matter when a failed message means a failed login, and authentication rates are cheap in the markets that send the most OTPs.
Internal operations and alerting. Session-based. Server alerts, inventory notifications, ERP and POS integrations, approval flows going to your own staff. There is no customer to spam, no template that fits, and no reason to pay per message. Paying Meta's utility rate to tell your own warehouse team that stock is low is money set on fire, and the full pricing breakdown shows how quickly that adds up at volume.
Support on a number your customers already use. Session-based, usually. If you have spent years putting one number on invoices and shopfronts, migrating it to the Cloud API means either coexistence or asking everyone to update their contacts. A linked session leaves it alone.
Agencies running many client numbers. Session-based, on cost alone. Ten clients through Cloud API means ten onboarding processes, ten verifications and ten sets of template approvals. Ten sessions is $35 a month and an afternoon. If the approval queue is the specific thing blocking you, we covered every gate Meta puts in the way in WhatsApp API without Meta approval.
AI agents and chatbots. Depends on who they talk to. An internal agent, or one answering inbound customer questions, works well on a session, especially with MCP support letting Claude or GPT drive the connection directly. An outbound agent contacting cold leads belongs nowhere near a session. Worth noting that Meta restricted open-ended AI assistant bots on the WhatsApp Business Platform in January 2026, allowing structured flows like orders, FAQs and lead capture but not general-purpose assistants. That restriction pushes some legitimate AI use cases off the official platform entirely.
Regulated industries. Cloud API. Banking, insurance and healthcare need the audit trail, the compliance certifications and the verified identity. This is not a cost question.
Running both
The teams with the best setups I have seen do not pick a side. They send campaigns and OTPs through the Cloud API, where compliance and deliverability justify the price, and they run internal tooling, staff notifications, prototypes and legacy numbers through sessions. Two systems, two risk profiles, one messaging strategy.
The one thing worth being deliberate about is lock-in. Some platforms bury WhatsApp behind a proprietary SDK and a flow builder you cannot export. When you outgrow them, or when their pricing changes, you rewrite everything. Prefer plain REST endpoints and standard webhook payloads on either side of the fence. It is worth comparing providers on that axis rather than on feature-list length, because a boring, predictable API surface is what makes leaving cheap.
Common Questions
What is the difference between the WhatsApp Business API and the WhatsApp Web API? The Business API is Meta's official platform, now delivered exclusively as the Cloud API. The Web API is an informal name for session-based tools that connect through WhatsApp's multi-device protocol as a linked companion device. One is sanctioned and metered, the other is unsanctioned and flat-rate.
Is the WhatsApp on-premises API still available? No. It reached end of life on 23 October 2025 and can no longer send messages. Cloud API is the only supported official deployment.
How many types of WhatsApp API are there in 2026? Two that work: Meta's Cloud API and session-based third-party APIs. The on-premises API is the third, and it is retired. The WhatsApp Business app is not an API.
Can I move from a session-based API to the Cloud API later? Yes, though it means provisioning the number on a WABA, completing verification and building templates. Plan for a week. Keeping your integration on plain HTTP requests makes the swap considerably less painful than if you built on a proprietary SDK.
Is a session-based WhatsApp API a Cloud API alternative? For conversational, internal and low-volume transactional use cases, yes, and it is dramatically cheaper. For marketing broadcasts, regulated messaging and anything needing a verified badge, it is not a substitute.
Do both options support webhooks? Yes. The Cloud API posts events to your endpoint, and reputable session-based providers do the same, typically with signed payloads, delivery logs and retries.