WhatsApp Business chats are encrypted in transit. But they are not end to end encrypted in the way customers assume. Here is where the encryption stops, why automation makes that unavoidable, and what serious businesses should do about it.
You already trust WhatsApp.
The little lock. The “messages are end-to-end encrypted” banner. The years of being told that not even Meta can read your chats.
All of that is true.
For personal chats.
The moment you message a business on WhatsApp, that guarantee quietly changes.
A bank. A clinic. A remittance service. A government desk running a chatbot.
The channel is still encrypted. But it is not end to end encrypted in the way most people understand that phrase.
Not because someone weakened it.
Not because of a hidden setting.
Not because Meta is secretly spying.
Because automation changes the architecture.
And the gap matters most at the exact second it becomes expensive: when someone types an account number, a national ID, a card number, or a medical detail into a chat they assume no intermediary can read.
Are WhatsApp Business chats end to end encrypted?
WhatsApp Business chats are encrypted in transit, but they are not end to end encrypted in the way most customers assume. In Cloud API business chats, the message is decrypted at Meta’s endpoint so it can be processed and passed to the business systems.
End to end encryption means only the two endpoints hold the keys.
In a personal WhatsApp chat, both ends are humans holding phones. Each phone runs the Signal protocol. Each phone holds its own keys. Nobody in the middle, including Meta, can read the content.
PERSONAL CHAT
You, on a phone holding keys, sends a message through Signal end to end encryption to a friend, also on a phone holding keys.
Nobody in between can read the content.
That is true end to end encryption.
A business chat on the WhatsApp Business Platform works differently.
The Cloud API that most business messaging now runs on introduces a cloud endpoint that has to process the message before it reaches the business systems.
BUSINESS CHAT, CLOUD API
Your phone sends the message through Signal end to end encryption to Meta’s Cloud API endpoint.
That is where the message is decrypted.
From there, the readable content is passed over TLS to business systems: the bot, the CRM, and the human agents.
The message is genuinely end to end encrypted on the first leg, from the customer’s phone to Meta’s API endpoint. At that endpoint, Meta decrypts it while acting as the business’s data processor, then passes the readable content onward to the business systems.
This distinction matters.
Everything is still encrypted in transit. Signal protects the first hop. TLS protects the rest of the path. Nothing is flying around the internet in the clear.
What disappears is the stronger property: the guarantee that no intermediary can read the content.
That property, not encryption in general, is what people mean when they say “end to end.”
Metadata is a separate issue. The who, when, and how often of a conversation are not end to end encrypted even in personal chats. That is not the main point here, but it is worth knowing.
This is not Meta reading your messages to sell ads
The lazy version of this story is wrong.
It is easy to say, “Meta can read your business chats.” It is also easy for someone to dismiss that as fearmongering.
So the precise version matters.
Meta acts as a data processor for business messages. Per its own documentation and certifications, it does not use business messages for ad targeting.
The honest claim is not:
“Meta is spying.”
The honest claim is:
“The content is readable by an intermediary by design.”
Those are very different statements. The difference is the whole point.
So why is it built this way?
Because end to end encryption and automation are fundamentally incompatible.
A business bot is automation. It has no human phone sitting at the other end holding private keys. The “business” is a server.
To do anything useful, that server has to read the message. Parse intent. Route a request. Trigger a template reply. Hand off to a human. Create a support ticket. Update a CRM.
A machine cannot act on ciphertext.
The instant software must read and respond at scale, something has to decrypt. And that decryption point is, by definition, an intermediary.
Once there is a readable intermediary, it is no longer end to end.
Nobody removed encryption. The property simply cannot exist when one “end” is a cloud service whose entire job is to read and process the content.
The self-hosted path is closed
There used to be an answer for businesses that wanted to control the decryption point.
It was the WhatsApp On-Premises API. The business self-hosted the endpoint. Meta did not see the cleartext in the same way.
If your priority was keeping the decryption point inside your own infrastructure, that was the serious option.
Meta has retired it.
| Date | What changed |
|---|---|
| January 9, 2024 | On-Premises was frozen. New features moved to Cloud API only. On-Premises received bug fixes and security patches only. |
| July 1, 2024 | Business phone numbers could only be registered for Cloud API. Attempts to register numbers for On-Premises returned error code 1005. |
| October 23, 2025 | On-Premises reached end of life. The final version, v2.63, expired, and messages to or from numbers still on On-Premises were no longer delivered. |
| 2026 onward | Any self-hosted container still running is unsupported software. No patches. No support. |
Self-decryption on your own infrastructure is no longer a supported path.
For practical purposes, if you are doing business messaging on WhatsApp today, Meta hosts the endpoint, and Meta decrypts.
What this means if you run the business
This is where it stops being a privacy trivia fact and becomes a compliance posture.
Under data protection law, the business is the data controller. Meta is the processor.
PDPL in Saudi Arabia. GDPR-style regimes in Europe. GLBA for financial data in the United States.
“It went through a third party” is not a defense.
The accountability for that customer’s account number sitting in a decrypted message store stays with the business.
The good news is that WhatsApp Business can still be a defensible channel.
Meta is controlled by contract and certification rather than by your direct supervision, and the controls are real. Cloud API carries SOC 2 and SOC 3 certification, GDPR and LGPD compliance, message storage limits, and local storage options that let businesses control where message data sits at rest.
That makes the channel defensible if the data processing agreement is in place and the system is configured deliberately.
It is not defensible if the business simply assumed the chat was private because the personal WhatsApp app is private.
The design answer is data minimization.
Keep sensitive data out of the chat by construction, so there is nothing damaging to decrypt in the first place.
How a serious money product handles it
The cleanest example comes from fintech, because the stakes are money and the rules are unforgiving.
Félix, the WhatsApp-based remittance product, lets people send money home as easily as sending a message.
But the part worth studying is not the chatbot.
It is what the chatbot refuses to collect.
When it is time to enter card details, Félix does not take the card number inside the WhatsApp chat. It sends the user to a separate, secure payment page where the card is entered and processed off platform.
That redirect looks like a small UX step.
It is actually the compliance architecture.
PCI DSS does not allow card data to be typed into a WhatsApp chat that gets decrypted at an intermediary and may sit in a message store.
So the card never touches the chat.
The same discipline applies to the rest of the data. Account numbers and recipient details are collected once, through a secure form, then referenced by alias afterward.
Bad steady state: “Send $200 to account number 123456789.”
Better steady state: “Send mom $200.”
The steady state chat is low sensitivity by design.
The residual risk is unsolicited input. A customer can still type their full account number into the chat unprompted.
By the time the business receives it, Meta has already decrypted it and it may already be in the message store.
You cannot undo that.
The defensible posture against that last risk is not a single feature. It is a system posture:
- Do not solicit sensitive data in the chat.
- Redact sensitive data before it is logged.
- Do not persist unnecessary sensitive content.
- Do not echo sensitive data back to the customer.
- Move collection of sensitive fields to secure forms and authenticated flows.
WhatsApp Business is a powerful, legitimate channel. Use it. But use it knowing what it actually is.
It is encrypted in transit. It is not end to end encrypted in the sense customers usually assume. And the responsibility under the law still sits with the business.
The winning design is not to demand a privacy guarantee the architecture cannot give you.
The winning design is to build so there is nothing in the channel worth reading in the first place.
Encrypt the transport. Minimize the content. Keep sensitive data behind a secure form and an alias.
That is not paranoia. It is the only design that survives contact with a regulator.
Sources
- Meta for Developers, On-Premises API Sunset: https://developers.facebook.com/docs/whatsapp/on-premises/sunset
- Stripe customer story, Félix: https://stripe.com/customers/felix
- Félix model overview, Stellar / Bitso: https://stellar.org/case-studies/felix-bitso
- Cloud API temporary storage and decryption for processing: https://www.infobip.com/blog/whatsapp-data-security
- BSP processing and metadata note: https://www.wati.io/en/blog/whatsapp-data-security/