You already built on the Cloud API. You do not have to build it again.
Sending one WhatsApp message from your own code is a morning's work. Everything after that — template approval states, webhook retries, media handling, delivery reconciliation, version deprecations, and an inbox for the replies — is the actual project. The useful question is not whether you can build it, but whether you want to keep it running.
- An existing Cloud API integration moves across without touching request construction
- Host and token
- Failures arrive in the error envelope your code already handles
- Same errors
- The version pinned in your URLs keeps working after Meta retires it
- No deprecation chase
Who it's for
Developers and agencies who have already integrated Meta's Cloud API directly, or are about to, and are weighing the maintenance against a platform.
The worry it answers
"Switching platforms means re-integrating." Not here: the compatible endpoints mirror the Cloud API's paths, bodies and error envelope, so a host and token change is the migration.
The part that is a morning, and the part that is a year
The first message is easy. The list below is what accumulates afterwards, and none of it is interesting work.
- Template submission, approval states, rejection reasons and variable binding rules
- Webhook delivery, retries, and a way to see what actually arrived
- Media upload, download and the URLs that expire
- Reconciling delivery and read receipts back onto your own records
- Rate limiting that paces sends instead of tripping account limits
- An inbox, because customers reply and somebody has to read it
- Version deprecations, on Meta's schedule rather than yours
Side by side
| Build it yourself | On a platform | |
|---|---|---|
| First message sent | A morning | A wizard and a playground |
| Template lifecycle | You implement it | A screen with status and notifications |
| Webhook debugging | Your logs | A test button and a delivery log |
| Replies | You build an inbox | A shared inbox with assignment and notes |
| Delivery reporting | You reconcile it | Per-recipient status, exportable |
| Meta deprecations | You track and migrate | Absorbed for you |
| Non-technical users | Cannot help | Run campaigns without a developer |
Buying does not mean giving up the API
This is not a choice between code and a dashboard. You keep programmatic access — signed requests, per-key permissions, a webhook with a delivery log, generated snippets and a playground — and get the parts you would otherwise have written yourself. The team who wants a dashboard gets one; the developer keeps an API.
And migrating is not a rewrite
The usual reason teams stay on a direct integration is not that it is better, but that moving looks expensive. The compatible endpoints remove that argument: the same paths, the same request bodies, the same responses, and the same error envelope. Change the base URL, change the token, and run your existing test suite as the migration check.
Checked against the product on 2026-08-14. WhatsApp's own rules and charges are set by Meta and can change.
Good to know
Where this feature stops, in plain words — so nothing here surprises you after you buy.
- The compatible surface is a deliberate allow-list of documented paths, not an open proxy, and supports GET, POST and DELETE only.
- Requests use an API key plus a signature and timestamp rather than a bare bearer token — more work for the integrator, and deliberately so.
- Free-form media still needs an open 24-hour session with the recipient; outside it, use a template.
- Meta's own conversation charges still apply, whichever route you take. A platform does not remove them.
- Reactions only apply to messages from the last 30 days and need WhatsApp's own message id.
Frequently Asked Questions
How much of my existing code changes?
The base URL and the token. Paths, request bodies, responses and error shapes match, so your existing tests are the migration check.
Do I lose API access if I use the platform?
No. You get keys with per-key permissions and usage, a webhook with a test button and delivery logs, a playground and generated snippets — plus the dashboard your non-technical colleagues need.
Is building it myself cheaper?
For the first message, yes. The cost is in what follows — template states, webhook retries, media, reconciliation, deprecations and an inbox — which is ongoing rather than one-off.
What happens when Meta deprecates an API version?
On a direct integration, you migrate. On the compatible endpoints the version in your URL is accepted and ignored, so an old pin keeps working.
Can I run both while I migrate?
Yes. Because the request shapes are identical, pointing one service at the new host while others stay put is a configuration change rather than a branch.
Move without re-integrating
Change the host, change the token, and keep the code you already wrote.
See plansThe features behind this
Each one in detail, including its limits.
- Cloud API CompatibleThe same paths, the same request bodies, the same error envelope. Your existing integration keeps working.
- API ManagementAPI keys you control and can revoke, a webhook with a test button and delivery logs, a playground, and generated code snippets.
- Message TemplatesCreate approved templates, track their status, and personalise them from your contact data — without learning Meta's Business Manager.
- Shared InboxEvery conversation on the connected number, with an owner, a status, labels and internal notes. A helpdesk, not a chat mirror.
Other comparisons
The other decisions that come up at the same time.
- App vs APIWhat each one actually gives you, when the app is genuinely enough, and what changes the day you outgrow it.
- Official vs unofficialThe mechanical difference between an official connection and a device-link tool — and what it means for the number your business runs on.
- Shared inbox vs shared phoneWhat actually breaks when a team shares one handset, and what a shared inbox changes about it.