WhatsApp API Architecture & Security

Cloud API Architecture

Since October 2025, WhatsApp Business Platform runs on Cloud API. At a high level:

• Businesses send messages through Meta Graph API
• Businesses receive events through webhooks
• Meta Cloud API acts as the managed messaging intermediary between business systems and WhatsApp transport

Encryption Model

WhatsApp messaging uses the Signal protocol for encryption. Cloud API also applies standard platform security controls:

• Data in transit — HTTPS + TLS
• Data at rest — encrypted storage on Meta infrastructure

Security boundary:

• WhatsApp transport does not expose message content to WhatsApp operators.
• Cloud API processes message content to provide platform functionality on behalf of the business.

Message Flow

User to Business

1. User sends a message.
2. Message is encrypted in transit to Cloud API.
3. Cloud API processes and decrypts for delivery to the business webhook.
4. Data is temporarily retained for core platform functionality (e.g. retries and retransmissions).

Business to User

1. Business sends message request to Cloud API.
2. Cloud API temporarily stores and processes for delivery and reliability.
3. Cloud API encrypts for destination delivery.
4. WhatsApp transport delivers to the user client.

In Dualhook setups, inbound messages arrive at your endpoint directly from Meta via Webhook Override. For outbound operations, your backend calls Dualhook's exact allowlisted Graph-compatible runtime routes with a per-connection dh_live_... key. The surface covers messages, media, selected templates, health/status, profiles, safe phone/calling settings, and QR codes without becoming an arbitrary Graph gateway.

All native authenticated Graph calls made by Dualhook pass through a server-only transport that derives Meta's app-secret proof from the exact authorizing token. Neither the token nor the proof is exposed to customers. The runtime resolves the existing authoritative routing projection before decrypting authorization, compares every route to the connection's stored phone/WABA assets, verifies template and media object ownership, rejects customer-controlled fields/hosts/callbacks, and uses manual redirect handling so credentials cannot be forwarded to another origin. OAuth code exchange (before a token exists), inbound webhook signatures, and validated Facebook/CDN media downloads are separate documented flows rather than Graph proof exceptions inferred by callers.

Local Storage (Data Residency)

Cloud API supports local storage for message data at rest in selected regions. This is useful for businesses with regulatory or residency requirements.

Data localized by Local Storage can include:

• Incoming and outgoing messages
• Text, media, and template payloads
• Limited metadata needed for linkage and auditing

Supported Regions (as of February 2026)

Region availability can change. Always validate against current Meta documentation before rollout.

Enabling Local Storage

1. Request Local Storage for a specific WABA through support.
2. Specify target storage region.
3. Confirm change with the PIN sent to the WABA phone number.
4. Verify data location after activation.

Rollback to default region typically requires a support request as well.

Stored and Collected Data

Cloud API stores and processes operational data needed for platform behavior. Published guidance describes temporary message retention up to 30 days for core functionality (such as retries and retransmissions).

Business identity and config data is managed in Meta business systems. Consumer identifiers used for delivery are processed for message routing.

GDPR and Shared Responsibility

Meta provides platform controls and documentation to support compliance. Each business remains responsible for its own legal compliance obligations (GDPR and other applicable laws).

Platform security controls do not replace your internal privacy, access-control, and retention policies.

Dualhook Security Model

Dualhook follows a stricter privacy boundary than what Cloud API requires:

• Message content is routed directly from Meta to your webhook endpoint via Webhook Override.
• Inbound message-path webhooks go directly from Meta to your endpoint and are not proxied by Dualhook.
• Outbound message and media payloads transit Dualhook's runtime without body persistence, caching, or content logging. Successful allowlisted phone/WABA metadata reads use a connection-isolated 60-second cache; message, media, template, profile, error, and mutation responses are never cached.
• Meta tokens, app secrets, generated proofs, Authorization headers, and credential-bearing Meta URLs are excluded from logs, persisted errors, analytics, and customer responses.
• Structured, quoted-JSON, and JSON-encoded error fields pass through the same credential sanitizer. The runtime preserves safe public Meta error fields while sanitizing non-success JSON before relay.
• Management responses use explicit projections; SIP credentials, encryption material, storage settings, callback configuration, and raw pagination URLs are removed even if Meta returns them unexpectedly.
• Customer-controlled webhook subscriptions or phone-level webhook overrides are not exposed. WABA routing and offboarding remain owned by Dualhook's existing lifecycle services.
• Dualhook stores only operational metadata needed for setup, monitoring, and compliance features.

See Compliance & Data Retention for retention windows and export options.

Operational Security Checklist

• Protect each connection's dh_live_... key and rotate it from the connection Overview page. Dualhook does not expose its customer-scoped Meta authorization tokens.
• Validate inbound webhook POSTs (envelope, WABA ID, phone_number_id), keep the override URL high-entropy and private, and enforce HTTPS. See Messaging Webhook → Inbound Webhook POST Validation.
• Use least-privilege roles for Meta portfolio and system users.
• Enable and manage two-step verification on business numbers.
• Monitor quality, account alerts, and security-related webhook events.
• Keep clear audit trails for template changes, number ownership, and webhook endpoint changes.