Official vs Unofficial WhatsApp API: Risks and Real Costs

The difference between the official and the unofficial WhatsApp API is who authorizes access to the number. With the official one, it is Meta itself: the number is registered on the WhatsApp Cloud API, with published terms, limits, and pricing. With the unofficial one, software emulates a WhatsApp Web session and talks to WhatsApp as if it were you in the browser, without Meta's authorization and in violation of its rules. The risk of the unofficial route is losing the number; the cost of the official route is much lower than comparison pages usually claim.

This article compares the two from the inside, shows what Meta says about each, takes apart the "real cost" math, and explains when the unofficial route still makes sense and how to migrate without losing your number or your history.

Short answer: the difference in one sentence

The official API is a contract with Meta. The unofficial one is a technical trick played against Meta.

That sounds harsh, but it is what decides everything that follows. When access is authorized, the rules are known: what can be sent, when, to whom, and at what cost. When access is emulated, there is no rule to follow, because Meta does not recognize that use. What exists is a race between those who detect and those who disguise, and your business's number is the stake on the table.

The rest of the article is the detail behind that sentence. If you do not know the Cloud API yet, the pillar article Official WhatsApp API: what it is and how it works covers the basics; here the focus is the comparison.

How each one works on the inside

Both paths deliver the same apparent result: a system sends and receives messages on WhatsApp. What changes is the mechanics, and the mechanics define the risk.

Unofficial: an emulated WhatsApp Web session

The best-known tools in this market in Brazil work like a WhatsApp Web without a browser. You scan a QR code, as you would on a computer, and from then on a server at the provider keeps that session open. It reads what arrives, sends what you tell it to, and exposes all of that to your system.

To WhatsApp, that server is a "linked device" on your phone. Meta does not publish or document that protocol. Whoever implements it reverse-engineers the messages the app exchanges with the servers, and every time the app changes, the library has to change after it. That is why unofficial integrations stop working out of the blue: nothing changed in your code, the protocol it was imitating changed.

Three practical consequences:

• Everything goes through the provider's server, including your customers' conversations, because the server is the one that "is" the linked device.
• There is no published limit, which looks like an advantage and is not. With no published limit, the real limit is the point at which Meta's detection system classifies the number as unauthorized automation.
• Sending to people who have never talked to you is technically possible, because the emulated session does what a human would do on the phone. That is exactly the use Meta describes as prohibited "bulk messaging."

Official: Meta's Cloud API, with a registered number and a contract

The WhatsApp Cloud API is Meta's own service for businesses. The number is registered in a WhatsApp Business Account (WABA) inside your portfolio in Business Manager, and access is granted by you, in Meta's window, to an approved app. That app can be yours or a provider's: Frame Conexa, for example, is a verified Meta Tech Provider, and the customer authorizes access through Embedded Signup without leaving the dashboard.

From there, communication goes directly to Meta's servers, through a documented, versioned API with advance notice of changes. Messages arrive by webhook (an HTTP notification Meta sends to your system for every event), signed so you can verify it came from Meta. Sending is an HTTP call with a clear response: accepted, or rejected with a code that tells you why.

What really changes compared with the emulated session is that Meta knows you exist. It knows which company owns the number, which app speaks for it, and the quality history of that number. And that visibility is what allows it to publish rules instead of simply blocking.

How to tell whether the API you use is official

The signs are objective and do not depend on what the provider writes on its site:

• An official provider shows Meta's Tech Provider or Solution Partner badge, and is listed in Meta's public directory. Only those who have passed Business Verification and App Review get there. If the platform does not display that badge and does not appear in the directory, it has no way to guarantee it talks to the Cloud API. What it writes on its own site proves nothing.
• Official starts with a Facebook login, in a Meta window. There you choose the business portfolio and the number, before anything else. A QR code may show up later (official coexistence itself asks for a QR to link the WhatsApp Business app that is already on the phone), but it is never the first step and never replaces that login. If "scan this QR code" comes BEFORE any Meta login, it is an emulated session.
• Official shows up in Business Manager. The provider is listed as a partner with access to your WhatsApp Business account, and you can remove that access from there.
• Official generates a bill from Meta. The template messages you send appear on your Meta account's invoice, with category and price per message. If nobody ever asked for a card in Business Manager, it is not the Cloud API.

What Meta says about unofficial clients

No interpretation is needed. Three of Meta's own sources say the same thing, in different words.

The WhatsApp Messaging Guidelines prohibit "using unofficial clients, bulk messaging, auto-messaging, auto-dialing, or automation to harm WhatsApp or our users," and list the penalties: from a warning to temporary or permanent suspension of the account.

The WhatsApp Business Messaging Policy says that if you use or work with a service that uses WhatsApp and violates the terms, such as sending unauthorized bulk messages, Meta has the right to restrict or remove your access to WhatsApp Business services. The same policy warns that a violation can cost you access to any WhatsApp product in the future. Note the "work with a service" part: the responsibility is yours, not the provider's.

The WhatsApp Help Center, on the page about unauthorized use of automated or bulk messaging, explains that detection combines machine learning and user reports, and points to the legitimate alternative: the WhatsApp Business Platform, which is the commercial name of the Cloud API.

What Meta does not publish is a ban statistic by tool. Any number you read about "X% of blocks come from automation" comes from third parties. What can be stated, because it is on Meta's pages, is the mechanism: an unofficial client is a violation by definition, and the punishment goes as far as permanent loss of the number. What to do when that happens is in WhatsApp Business blocked: what to do.

Comparison table: risk, cost, features, maintenance, and data

Two rows in this table deserve special attention. The bulk sending row, because it is the reason most people choose the unofficial route and also the reason most of them lose the number. And the cost per message row, because that is where the comparison is usually distorted.

The real cost: taking apart "R$ 70 per instance vs. thousands on the official side"

Comparison pages from some unofficial providers still present the official API as expensive and bureaucratic: a sign-up fee of thousands of reais (R$, the Brazilian currency), a minimum volume of thousands of messages per month, a contract with an intermediary. That scenario existed years ago, when access had to go through Solution Partners with contracts and credit. It is not how the Cloud API works today, and Meta's pricing page is public.

What Meta actually charges and what is free

Meta charges per delivered template message, in three categories: marketing, utility, and authentication. The rate depends on the category and the recipient's country. There is no sign-up fee, no minimum volume, and no monthly fee from Meta. Receiving a message never costs anything. A message that Meta rejects or does not deliver is not charged.

According to the table Meta published in September 2026 for recipients in Brazil, marketing is around 6 US cents per message, and utility and authentication are below 1 US cent. Check the official rate card before doing the math: the table is interactive, changes without notice, and the amount in reais depends on your account's billing currency. The details, with simulations by type of business, are in how much the WhatsApp Business API costs.

Today, replying to a customer who wrote to you, inside the 24-hour window, is free. That changes on October 1, 2026: from that date Meta also charges per message for free-form replies inside the window and for utility templates sent inside it, at the utility rate of the recipient's country. An article that compares costs without mentioning this date goes stale in weeks.

Warning: several providers repeat that there will be a monthly allowance of free service messages before this charge starts. Meta's official page does not mention any allowance. Do not count on it in your budget until the October rate card confirms it.

Fixed price per number, no markup: the Tech Provider model

The other half of the bill is what the provider charges. There are two models here. A Solution Partner bills the customer directly, with a Meta credit line, and so usually charges a per-message markup. A Tech Provider cannot do that: under Meta's rules, a Tech Provider's customer registers their own payment method in the WhatsApp Business account and pays Meta directly. The provider charges only for the software.

That is Frame Conexa's model: a fixed amount per number per month, with no per-message charge from us, and Meta's invoice arrives to you, in Business Manager, at Meta's list price. There is no markup on the message because there is no way to add one. Plans are listed in per-number pricing.

Compare that with the R$ 70 "instance" of the unofficial route. The fixed amount is similar. The difference is that on the official side the same money buys a number Meta recognizes, with a published limit, a quality history, recourse in case of a penalty, and a growth path. On the unofficial side, it buys a session that can end tomorrow without warning, taking the number with it.

What the official API does not do

It would be dishonest to pretend the official API does everything the emulated session does. It does not, on purpose, and it is good to know that before migrating.

• Groups. The Cloud API does not create, join, or send to groups. With coexistence, groups stay in the phone app, but the system cannot see them.
• Status. There is no way to post a status through the API.
• The app's broadcast lists. With coexistence, existing lists become read-only. Official bulk sending is by campaign with an approved message, which is a different mechanism.
• Free-form messages to someone who never wrote. Outside the 24-hour window, only a Meta-approved template. Sending "hi, how are you?" to a cold list is rejected with error 131047 before it goes out.
• Sending without consent. Meta's policy requires that the person gave you their number and agreed to receive messages. That is a platform rule, and an official provider has no way to make an exception.
• Unlimited volume on day one. Each account starts with a sending capacity of 250 unique numbers per 24 hours, which Meta raises according to quality and usage. What makes that limit grow is in WhatsApp Business API messaging limits.

In Frame Conexa, what exists is what the API delivers: conversations with the window flagged, campaigns with automatic pause when quality drops, audiences with segments, templates, webhooks, and a REST API. There is no ready-made chatbot, catalog, voice calls, or multi-agent support with several attendants. If your use depends on any of those, a partner CRM or support platform connects on top of the API.

When the unofficial route still makes sense and when it is reckless

Not every use justifies the compliance cost of the official route, and saying otherwise would be a sales pitch, not an analysis.

An emulated session makes sense when the number is worth nothing to the business: a personal script to notify yourself of something, a prototype to test an idea for a week, a study project. It also makes sense when the feature does not exist on the official side, such as reading what happens in a group, as long as the number is disposable and the people in the group know what is running.

It becomes reckless when:

• The number is the business's main number, with years of conversations, customers who only have that contact, and a presence on business cards, storefronts, and ads.
• The use is bulk sending to people who did not ask for it. That is the use Meta describes, word for word, as prohibited. It is not a gray area.
• Customer data matters. Conversations with patients, students, or buyers passing through a server that emulates a session, with no Meta terms covering that processing, is a data protection problem that the business owner answers for alone.
• You are building an integration on top of it. CRM, calendar, sales automation. Every protocol change breaks the foundation of what you built, and the outage never gives notice.

The question that settles most cases is simple: if this number disappeared tomorrow, what would happen to the business? If the answer is "nothing," the unofficial route may do. If it is anything else, the cost discussion has lost its meaning.

How to migrate without losing the number or the history

The most common fear among unofficial API users is the migration: "I'll have to take the number off my phone and lose everything." That has not been true since Meta released coexistence.

What coexistence changes

With coexistence, the same number stays in the WhatsApp Business app on the phone and also exists on the Cloud API. You keep handling customers from the phone; the system handles them through the API; the two coexist. If the number's owner approves sharing at connection time, Meta sends the provider the messages from the last 180 days, in phases, plus the contact list. That is the 6-month history that shows up in the dashboard the next day.

There are limits worth knowing beforehand: a number in coexistence has a fixed capacity of 20 messages per second, the app stops creating broadcast lists and turns off disappearing messages, and the phone must stay active, otherwise the integration is turned off after about 14 days of inactivity.

The steps, in order

1. End the unofficial tool's session. In the app, under Linked devices, remove the provider's device. This is not a documented Meta requirement, but it avoids two automations replying to the same conversation during the switch.
2. Check the app. Coexistence requires an updated WhatsApp Business app and a number that is not blocked. A banned number does not get into the official API; if that is your case, the path is an appeal, described in WhatsApp Business blocked: what to do.
3. Have a business portfolio at Meta. That is the Business Manager account. If one does not exist, the connection window creates it.
4. Connect through Embedded Signup. In Frame Conexa it is the "Connect WhatsApp" button in the dashboard, or a connection link you send to whoever has the phone in hand. You log in with Facebook, choose the number, and approve sharing the history. Because the number already has WhatsApp Business installed, there is a step to scan a QR code with the app to confirm the link, always after the Meta login, inside Meta's window, never before.
5. Register the payment method with Meta. As a Tech Provider, Frame Conexa cannot do this for you. Without a card in Business Manager, the number connects and replies inside the window, but cannot send templates. The dashboard warns you and takes you to the right place.
6. Point the integration at the official API. If you had a system talking to the unofficial one, the work is swapping the destination: sending becomes a REST call with a token and receiving becomes a signed webhook. The webhooks guide shows the format, and the quickstart sends the first message in minutes.

An example of what changes in code. On the official side, sending is this, and the response tells you right away whether it was accepted:

curl -X POST https://frameconexa.com/api/v1/instances/$FRAME_CONEXA_INSTANCE_ID/messages \
  -H "Authorization: Bearer fc_SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to":"5585999990000","type":"text","text":{"body":"Olá! Recebemos seu pedido."}}'

If the person did not write in the last 24 hours, that call comes back with Meta's code 131047, and the system knows it needs to use an approved template. On the unofficial side, the same message would go out without warning, and the only possible answer would come days later, in the form of a blocked number.

Anyone automating with a visual tool finds the same path in WhatsApp Business API with n8n and Make, with flows ready for swapping the source.

Tip: migrate the main number first and keep your contact base clean. The new account's sending capacity starts at 250 numbers per day and grows with quality; a bulk send to a cold list in the first week is the fastest way to start your official life with a flagged number.

Next step

If the number matters to the business, the decision is already made; what is missing is the path. See the per-number plans and connect through coexistence, without taking the number off your phone. For anyone who will rewrite the integration, the API quickstart shows the first message in three calls.