A quick note on what is and is not publicly confirmed, because most posts on this topic blur it. In June 2022, Maytapi published a post saying Chat-API, one of the larger providers of unofficial WhatsApp APIs, was closing that side of its business and would focus on the WhatsApp Business API instead. That post is from a competitor; it gives no shutdown date, and it offers no guidance to Chat-API's own customers. Chat-API's current website, meanwhile, advertises an "enterprise-level API from $30/month" and shows no closure notice, without saying which WhatsApp connection method sits underneath. So the accurate version is this: the unofficial, QR-code-style product was announced as closing, and what Chat-API sells today is something you should confirm directly with them rather than assume.
If you are reading this, you probably already know which situation you are in: your integration stopped working, your instance is being retired, or you want to move before it does. This post is about what comes next.
First decision: official or session-based
Chat-API's reported move went from one model to the other, and your replacement choice starts with the same fork.
Official (Meta Cloud API or a Business Solution Provider). Your number is registered to a WhatsApp Business Account, you send business-initiated messages through approved templates, and you pay Meta's per-message rates plus whatever the provider adds. This is the route that does not depend on anyone's tolerance of unofficial clients. It is also the route with onboarding: a Meta business portfolio, a number that has not been used on WhatsApp, template approvals, and a verification process if you want to scale beyond the starting message tier. Our pricing breakdown for 2026 has the current rate card, and it includes a change that matters for anyone budgeting around free service replies: Meta ends the free customer-service window on 1 October 2026.
Session-based (QR-code linked device). Your number connects as a linked device, the provider holds the session, and you call HTTP endpoints. No templates, no Meta approval, flat monthly pricing. The cost is the one this category always carries: it sits outside Meta's terms, and enforcement is unpredictable. A provider that has exited this side of the market is itself evidence of that, whatever the reason in their case.
If your traffic is promotional, high-volume, or something a suspended number would damage, go official. If it is conversational, internal, or support on a number your customers already know, session-based remains a reasonable fit. Our post on WhatsApp API without Meta approval lays out that trade-off in full, including the parts that do not flatter our own category.
Replacements by type
If you want official. 360dialog and Twilio are the two most commonly chosen routes for developers who want the Cloud API without a dashboard-first platform on top. Both publish pricing. 360dialog is a flat monthly fee with no per-message markup on Meta's rates; Twilio adds a per-message charge and suits teams already using it for SMS or voice. The direct Meta Cloud API is free to access and fine if you are comfortable building your own tooling.
If you want session-based. The established names are Maytapi, WasenderAPI, UltraMsg, Green API and WaHttp. They differ mainly on pricing structure, how they handle multiple numbers, and what happens to your session if the provider has an outage. WaHttp is ours, so weigh that accordingly: $5 a month for one session with unlimited messages, up to $35 for ten, REST endpoints and webhooks from the first plan, and a hosted MCP endpoint if an AI agent is part of what you are building. The full provider comparison puts all of these side by side so you can see where each one is cheaper or weaker than the others.
If you want both. Plenty of teams run templates and campaigns on the official platform and everything conversational on sessions. It is a more sensible arrangement than it sounds, because each side carries only the risk it is suited to.
What to check before you pick, so this does not happen twice
The reason to take the Chat-API story seriously is not that one provider changed direction. It is that every provider in this category can, and the cost to you depends on how you built against it.
Ask what happens to your sessions and data if they close. Can you export message history? Can you keep your linked number and move it, or does it need re-pairing from scratch? Providers that cannot answer this plainly are telling you something.
Keep your own copy of conversations and contact data. A webhook that writes every inbound and outbound message to your own database turns a provider shutdown from a data loss into a re-pointing exercise.
Put a thin layer between your code and the provider. One internal sendWhatsApp() function that wraps the HTTP call means a migration touches one file instead of forty. This is the single cheapest piece of insurance on the list.
Read how they describe their own risk. A provider that tells you plainly it is unofficial, and what that means for ban risk, is easier to plan around than one that says nothing.
Check for a second route. If your volume justifies it, have a template-approved Cloud API number sitting idle as a fallback. It costs almost nothing until you use it.
Migration notes
Whatever you move to, the moving parts are the same. Outbound sends map onto the new provider's send endpoint: recipient, message type, body or media URL. Inbound events become webhooks, and the payload field names will differ, so remap your handler rather than assuming a drop-in. Authentication changes, usually from an instance ID and token pair to a single API key or bearer token. Anything that relied on a specific unofficial feature, such as certain group operations, needs checking against the new provider's documentation before you cut over, because a session-based provider may support it and an official one may not.
Move one number first, run both providers in parallel for a few days if you can, and compare delivery receipts before you switch the rest.