What is end-to-end encryption?
End-to-end encryption (E2EE) is a design in which a message is encrypted on the sender's device and can only be decrypted on the recipient's device, because only those two endpoints hold the keys. Servers that store and forward the message see only ciphertext. WhatsApp has encrypted chats end to end by default since 2016, using the Signal Protocol for key agreement and fresh per-message keys.
With a business, the question is where the business's endpoint sits. On the Cloud API, Meta hosts it: the customer's message is encrypted on their phone and decrypted by the Cloud API, which manages the encryption keys on the business's behalf, and is then forwarded to the business's webhook over HTTPS. Outbound messages take the same path in reverse, encrypted by the Cloud API with the Signal Protocol before they travel to the customer. WhatsApp shows users in the chat when a business uses a secure service from Meta to manage the conversation.
So E2EE in business messaging is a narrower promise than in a chat between two friends. The customer-to-endpoint leg is protected; after that, Meta processes messages for the business (its documentation says Cloud API message data is kept for up to 30 days, encrypted at rest), and the message is then in the hands of the business, its provider and their systems. TLS (Transport Layer Security) protects each later network hop and Encryption at Rest protects stored copies, but neither is end to end.
Key takeaways
- End-to-end encryption (E2EE) means only the endpoints of a conversation hold the keys; relaying servers see ciphertext.
- WhatsApp encrypts every chat end to end by default, using the Signal Protocol.
- On the Cloud API, Meta hosts the business's endpoint, manages its keys and decrypts messages before passing them to the business.
- After the endpoint, protection depends on TLS, webhook security and how the business stores and handles the data.
- E2EE protects message content in transit; it does not hide metadata or cover what the business does with messages.
Figure 1
Who can actually read a message to a business?
Stage 5 of 5 · Unlock
Only the recipient's device has the key, so only it can turn the ciphertext back into the message.
At Cloud API endpoint:Is my blood test report ready? Ref LAB-20931
Patient's phonesees
Relay serversees
Ciphertext, unreadable without the key
Cloud API endpointsees
Can read the message
- The patient, on their phone
- The Cloud API endpoint Meta runs for the lab
- The lab and its provider, once the webhook delivers it
Cannot read it
- WhatsApp's relay servers in between
- The mobile network or Wi-Fi operator
- Anyone intercepting the traffic on the way
Step 5 of 5, Unlock: Only the recipient's device has the key, so only it can turn the ciphertext back into the message.
Why it matters
Why does end-to-end encryption matter?
Customers trust the padlock, and regulators and enterprise buyers ask precise questions: who can read these messages, where are they stored, and for how long? Knowing that E2EE ends at the Cloud API endpoint Meta runs for the business lets a company answer honestly, write an accurate Data Processing Agreement and privacy notice, and spend its effort on the parts it actually controls: webhook security, storage encryption, access control and retention.
How does end-to-end encryption work?
Keys are created on devices
Each WhatsApp client generates its own identity and session keys, and private keys never leave the device. The Signal Protocol agrees a shared secret between two endpoints.
The sender encrypts
Each message is encrypted with a fresh message key from the Double Ratchet, so a key stolen later cannot unlock earlier messages.
Servers relay ciphertext
WhatsApp's servers route the encrypted message, and queue it while the recipient is offline, without the key to read it.
The business endpoint decrypts
On the Cloud API, Meta runs that endpoint for the business: it decrypts the message and delivers it to your webhook over TLS, signed with X-Hub-Signature-256.
Your systems take over
From the webhook on, confidentiality depends on you and your provider: TLS between services, encryption at rest, access control, masking and retention limits.
Example: An honest answer in a vendor assessment
A Delhi diagnostics lab sends test reports on WhatsApp and answers patients' questions there. In a hospital partner's vendor assessment, it describes the flow precisely: messages are end-to-end encrypted between the patient's phone and the Cloud API endpoint Meta operates for the lab; Meta processes them on the lab's behalf; they reach the lab's messaging provider over HTTPS with signed webhooks; and report conversations are stored encrypted at rest for 90 days, with phone numbers masked on agent screens. The assessor accepts it because it names who can read the data at each step instead of claiming that nobody can.
End-to-end encryption in code
{"object": "whatsapp_business_account","entry": [{"id": "{WABA_ID}","changes": [{"field": "messages","value": {"messaging_product": "whatsapp","metadata": { "display_phone_number": "919876543210", "phone_number_id": "{PHONE_NUMBER_ID}" },"messages": [{"from": "919812345678","id": "wamid.HBgMOTE5ODEyMzQ1Njc4FQIAEhgg","timestamp": "1792396800","type": "text","text": { "body": "Is my blood test report ready?" }}]}}]}]}
By the time a message reaches your webhook it is plain text: the Cloud API has already decrypted it. Protect it from here with signature checks, TLS and encrypted storage.
Common mistakes with end-to-end encryption
Telling customers only you and they can read chats
On the Cloud API, Meta's hosted endpoint decrypts messages and your provider processes them. Name the actual parties in your privacy notice and data processing agreement.
Assuming E2EE covers your database
Once delivered to your webhook, messages are ordinary data. Encrypt them at rest, restrict who can read them and set a retention period.
Confusing TLS with end-to-end encryption
HTTPS protects each hop but is decrypted at every server along the way. Only the device-to-endpoint leg on WhatsApp is end to end.
Forgetting metadata
Who messaged whom, when and how often remains visible to the platform and to your systems. Treat it as personal data too, with the same retention rules.
Best practices for end-to-end encryption
- Write a one-paragraph data-flow statement naming every party that can read messages, and reuse it in security questionnaires.
- Verify X-Hub-Signature-256 on every webhook so the decrypted messages entering your systems are genuine.
- Keep only the message history you need, and mask phone numbers on agent screens and in logs.
E2EE FAQs
- Is the WhatsApp Business API end-to-end encrypted?
- Messages are end-to-end encrypted between the customer's device and the business's endpoint. On the Cloud API, Meta runs that endpoint and manages its keys, so the Cloud API decrypts messages on the business's behalf before delivering them.
- Can Meta read WhatsApp Business messages sent through the Cloud API?
- The Cloud API decrypts them in order to deliver them, processing them for the business. Meta's documentation says it keeps Cloud API message data for up to 30 days, encrypted at rest, to provide the service.
- Is end-to-end encryption the same as TLS?
- No. TLS encrypts each network hop and is decrypted at every server; end-to-end encryption stays encrypted until the final endpoint. A webhook call to your server uses TLS, not E2EE.
- Does end-to-end encryption make my business DPDP compliant?
- No. It protects one leg of the journey. DPDP duties cover consent, purpose, security safeguards, retention and breach handling across all your systems, which E2EE does not address.