The difference in one sentence
With the official API, you operate within Meta's rules and billing in exchange for stability and backing. With the unofficial API, you operate the number's own WhatsApp, with freedom and predictable cost, in exchange for taking responsibility for your sending behavior. Both are legitimate ways to get a WhatsApp API; the mistake is choosing without looking at your scenario.
Criterion-by-criterion comparison
| Criteria | Official (Cloud API) | Unofficial (QR code) |
|---|---|---|
| Time to first message | Depends on sign-up and verification with Meta | Minutes: create the session and scan the QR code |
| Number | Registered on Meta's platform, under its rules | Your current number, which stays on the phone |
| Starting a conversation | Only with an approved template | Free-form message |
| Billing | Per template, varies by category and country, plus provider fee | Per connection, no per-message fee |
| Groups | Limited | Create, manage participants, send |
| Ban risk | Low within Meta's rules | Depends on sending patterns and infrastructure |
| Verified badge and profile | Possible, under Meta's criteria | Not applicable |
| Dependency | Meta's rules and timelines | Provider quality |
When to choose each one
Choose the official API when
- You need to start conversations with people who have never messaged you, at scale, such as notices to a large base. Approved templates are the intended path for that.
- Your customer or your industry requires it. Banks, insurers and companies with a compliance team often require the official channel by contract.
- The number is the brand. A central support number, with a verified profile, that can't risk being banned.
Choose the unofficial API when
- Each of your customers connects their own number. That's the typical SaaS case: the customer scans a QR code on your screen and starts using it, without going through Meta sign-up.
- The conversation is ongoing and a relationship already exists. Support, sales follow-up, appointment confirmation, customer care.
- You need groups or features of the regular app that the official API doesn't cover.
- Per-message cost breaks your business model, as in operations with high message volume per number.
Use both when
The most common scenario in mature products is mixed: most customers on the unofficial API, for activation speed and cost, and a few on the official one, because they require it or for a specific flow, such as notifications to people who haven't started a conversation yet. That's only viable if the integration doesn't have to be duplicated.
On D-API, both use the same API
The difference is in creating the session. The type field accepts unofficial or cloud_api, and the resulting sessionId works on the same send routes:
# Unofficial: connect afterwards with a QR code
curl -X POST https://api.d-api.cloud/api/v1/sessions \
-H "Authorization: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "sessionId": "store-nyc", "type": "unofficial" }'
# Official: uses your Meta account details
curl -X POST https://api.d-api.cloud/api/v1/sessions \
-H "Authorization: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"sessionId": "hq-official",
"type": "cloud_api",
"wabaId": "YOUR_WABA_ID",
"phoneNumberId": "YOUR_PHONE_NUMBER_ID",
"accessToken": "YOUR_ACCESS_TOKEN"
}'After that, sending a text to store-nyc or to hq-official is the same call to /api/v1/messages/send/text. On the official connection, the webhook can come in the normalized format, the same as the unofficial one, or in Meta's original format, if your system already works with it.
What is exclusive to one model stays exclusive. Sending an approved template, at /api/v1/messages/send/template, only works on cloud_api connections; on an unofficial session, the API responds with a 400 error and the code NOT_CLOUD_API. That makes it explicit, in the code itself, which flow depends on which model.
Cost, risk and what nobody tells you
Two points are usually left out of comparisons. First: on the official API, what drives cost isn't how many numbers you have, but how many conversations you start. A product that sends daily reminders to a large base feels that quickly. The breakdown is in WhatsApp API pricing.
Second: on the unofficial API, ban risk isn't a lottery. It depends on consent, volume and content, and infrastructure limits the damage when something goes wrong. On D-API, each connection runs isolated with its own IP, so one number's problem doesn't spill over to the others. The practices that make the most difference are in how to avoid bans on the WhatsApp API.
To go deeper on each model, see the pages for the official WhatsApp API and the unofficial WhatsApp API.