Cloud API Calling

What Cloud API Calling Is

The WhatsApp Business Calling API lets your business initiate and receive voice calls with WhatsApp users over VoIP, using the same business phone number you use for messaging. Calls go through Meta Cloud API and use WebRTC for media — encrypted with SRTP/DTLS, audio compressed with OPUS by default.

The same business phone number unifies messaging and calling. From the user's perspective, it's a familiar WhatsApp call — no separate app, no SMS-style trust prompts, no region-specific carrier limitations.

Calling is not enabled by default. You opt in per phone number by configuring call settings (see Calling Configuration).

Calling Pages in This Section

• Calling Configuration — Enable calling, call hours, holiday schedule, callback permissions, audio codecs, settings webhooks
• Business-Initiated Calls — Place outbound calls; /calls endpoint with connect/terminate; lifecycle webhooks
• User-Initiated Calls — Receive inbound calls; pre_accept/accept/reject/terminate; DTMF; companion-device support
• Call Permissions — Temporary vs permanent permissions; three ways to obtain them; permission-reply webhooks
• SIP Configuration — Use SIP signaling instead of Graph API + webhooks; digest auth; SDES vs DTLS
• Call Buttons & Deep Links — voice_call interactive messages, template buttons, wa.me/call/<number> deep links
• API Reference — Consolidated endpoints + webhook reference + WebRTC/media implementation guidelines
• Pricing — Per-pulse billing, volume tiers, CSW interaction with calling
• Troubleshooting — Error codes, audio clipping, media-flow timeouts

Two Call Paths: User-Initiated vs Business-Initiated

The business phone number's country code must be in the BIC-supported list. The recipient's phone can be in any country where Cloud API is available.

Two Signaling Paths: Graph API vs SIP

When SIP is enabled, calling-related Graph API endpoints stop working and calling webhooks are not sent — SIP becomes the exclusive signaling path. Messaging continues to use Graph API + webhooks normally.

Pick Graph API + webhooks unless you have a SIP-based contact center or telephony infrastructure that needs native SIP integration. See SIP Configuration for details.

Prerequisites

Before enabling calling on a business phone number:

• The number must be in use with Cloud API (not the WhatsApp Business app).
• Subscribe your app to the calls webhook field (skip this if you're using SIP).
• The same app must be subscribed to the WABA of your business phone number.
• The app must have whatsapp_business_messaging permission for the number.
• The phone number must have a daily messaging limit of at least 2,000 unique recipients. (Test numbers and sandbox accounts bypass this.)
• A valid payment method must be attached to the WABA — calls require billing on file even though UIC is free.
• Business verification is not required for calling (same as messaging).

Availability

User-initiated calling: every country where Cloud API is available. iOS, Android, and selected companion devices (iPhone/Android phones registered as additional devices on the same account). Not supported on WhatsApp Web or WhatsApp Desktop.

Business-initiated calling: every country where Cloud API is available except the following business-phone-number countries:

• United States
• Canada
• Egypt
• Vietnam
• Nigeria

The recipient's phone can be from any country where Cloud API is available.

Testing and Sandbox

Public test numbers (PTNs) and Sandbox accounts have relaxed calling limits to make integration easier. Sandbox accounts are only available to Tech Partners.

Test numbers also bypass the 2,000-message-limit prerequisite for enabling calling. Calling is disabled by default on test numbers — you must configure call settings before placing or receiving calls.

Integration Patterns

How you wire up calling depends on your role:

Our terms forbid PSTN on any leg of a WhatsApp call. SIP trunks are allowed if they stay exclusively VoIP — bridging into the PSTN is prohibited.

Single App vs Multiple Apps

You can almost always reuse your existing messaging app for calling. The webhook callback URL is the same; the payload distinguishes message events from call events.

Reasons to use one app:

• Less app-review and ongoing maintenance overhead.
• Simpler footprint on Meta.
• The Embedded Signup app and the Graph-API-invoking app stay equal.

If you do want separate apps, you can — subscribe the calling app only to calls-related fields and the messaging app only to message-related fields. Override the callback URL per app at WABA or phone-number level. The trade-off is operational complexity, especially for permission management.

Dualhook's Stance on Calling

Dualhook does not currently expose calling features in its dashboard. Calling is sender-side and media-heavy — your backend handles SDP, WebRTC stacks, and call-state machines, just as you handle outbound messaging today.

What Dualhook does affect:

• The Embedded Signup token Dualhook issues has whatsapp_business_messaging, which is the same permission needed to place calls and accept inbound calls. No re-onboarding needed.
• If you subscribe your app to the calls webhook field, those webhooks go directly to your endpoint via Webhook Override. Dualhook does not ingest them.
• Dualhook does not auto-subscribe to account_settings_update either. To receive the calling-settings webhook, subscribe your own app to that field at the WABA level — see Calling Configuration.

If you want Dualhook to surface calling-related state (permission status, call hours, call analytics) in the dashboard, that's a feature request — open it through the in-app support chat.