For the entire life of the WhatsApp Business Platform, the channel has been text. Every playbook a support team has written — the 24-hour service window, canned replies, the queue that tolerates a four-minute wait because nobody is holding a handset to their ear — assumes asynchronous messaging. The WhatsApp Business Calling API breaks that assumption on the same phone number, and most teams discover the consequences in staffing rather than in code.
The integration itself is not hard. Meta exposes calling as a setting on a Cloud API phone number, and switching it on is a single API call. What is hard is that voice arrives with a permission model unlike anything in messaging, a billing unit measured in six-second pulses, and a revocation rule that punishes exactly the failure mode a busy team is most likely to produce. This guide covers the prerequisites, the geography, the permission mechanics in detail, the settings endpoint, what calls cost, and the operational reality of running a synchronous channel next to your chats. If you are still on the free app rather than the platform, start with the WhatsApp Business app versus the API, because everything below requires the Cloud API.
What the WhatsApp Business Calling API Actually Is
The WhatsApp Business Calling API lets a business place and receive VoIP calls with WhatsApp users on the same verified business number it already messages from. Meta positions it as unifying messaging and calling behind one global number, and documents voice as shipping today with video and screen sharing planned. There is no separate hotline to publish, no second identity for the customer to trust, and no app switch.
That last point is the strategic argument. A customer deep in a support thread who needs to talk taps a call button inside the conversation they are already in. Compared with publishing a phone number and hoping people dial it, the friction difference is enormous — and it applies most in markets where WhatsApp is the default communications layer rather than one app among several.
Note the distinction from the calling feature in the free WhatsApp Business app. That is a consumer-grade feature on a single handset. The WhatsApp Business Calling API is a platform capability with permission gates, webhooks, SIP options and a rate card, and it only exists on Cloud API numbers.
The Prerequisites That Decide Whether You Can Call at All
Meta gates the WhatsApp Business Calling API behind a short list of requirements, and one of them is a quality threshold rather than a configuration step.
| Requirement | Detail | Why teams fail it |
|---|---|---|
| Cloud API number | The business number must be active on the Cloud API, not the WhatsApp Business app | Numbers still bound to the app have to be migrated first |
calls webhook subscription | The app must subscribe to the calls webhook field | Easy to miss; without it, call events never reach your stack |
whatsapp_business_messaging permission | Standard messaging permission on the app | Usually already present |
| Messaging limit of 2,000+ | Business-initiated calling requires a daily messaging limit of at least 2,000 unique recipients | The real gate — a new or low-tier number simply cannot call out |
| Calling explicitly enabled | Calling must be switched on per phone number; it is off by default | Assumed to be automatic once the number qualifies |
The 2,000-recipient tier is the one to plan around. It is a messaging quality outcome, not something you can buy, and it means outbound calling is unavailable to a number that has not yet earned volume through good messaging behaviour. If you do not know where your number sits, how WhatsApp messaging limits and tiers work is the prerequisite reading — your calling roadmap is downstream of your messaging quality rating.
Inbound is the exception. User-initiated calls do not require the 2,000-recipient tier, which is why almost every team should enable inbound calling first and treat outbound as a later, separately justified project.
Where Business-Initiated Calling Is Not Available
Geography is a hard constraint and it is asymmetric. Meta lists business-initiated calling as unavailable in the United States, Canada, Egypt, Vietnam and Nigeria. User-initiated calling remains available globally wherever the Cloud API operates, so customers in those five markets can still call you — you just cannot call them.
There is a second, subtler restriction. From 10 December 2025, Meta applied country-level rules to call icon visibility, meaning the call button may not surface for every audience even where calling is technically enabled on your number. If your rollout plan assumes a visible call affordance in every market, verify it market by market rather than inferring it from one test handset.
Call Permission Is the Whole Ballgame
This is the section worth reading twice. Business-initiated calling on WhatsApp is not opt-out like a phone number; it is an explicit permission system, and the permission is scarcer than the calls it unlocks.
How permission is granted
A business obtains call permission one of two ways. It can send a free-form or templated message requesting permission — Meta documents a dedicated call permission request message for this. Or the user grants temporary permission automatically by placing a call to the business, with no request sent at all. The webhook reports which path was taken through a response_source field carrying either user_action or automatic.
The user then has three options rather than the usual two: decline, accept temporarily, or accept permanently. The webhook returns response as accept or reject, plus an is_permanent boolean, so your system can tell a seven-day grant from an open-ended one. A permanent permission can still be revoked by the user whenever they choose.
How long permission lasts
Temporary permissions are granted for 7 calendar days — 168 hours. The webhook includes an expiration_timestamp in Unix time, and you should store that value rather than computing your own expiry, because the request itself has separate expiry rules that interact with it.
A permission request expires in three circumstances: 7 days after it was accepted or declined, 7 days after delivery if the user never responds, or immediately when the user interacts with a newer permission request. That third rule matters for anyone running overlapping campaigns — a second request does not stack on the first, it supersedes it.
The request budget: 1 in 24 hours, 2 in 7 days
Per user, a business may send a maximum of 1 permission request in 24 hours and a maximum of 2 permission requests within 7 days. That is the entire budget. Both limits reset when any connected call occurs between the business and that user, in either direction — so a single answered call restores your ability to ask again.
Contrast that with the call ceiling itself: once permission is held, Meta documents business-initiated calls at up to 100 per user per day. The scarce resource is unambiguously permission, not call volume. And permission request messages are billed at standard per-message pricing, so a list of unresponsive contacts costs money to ask twice. Meta documents the call permission request among its marketing template formats, which is the most expensive category on the rate card — confirm the current classification with your provider before you model a campaign. The consent discipline here is close to what WhatsApp opt-in rules already demand of messaging, and if you send the request as a template it goes through the same review path as any other, so getting templates approved applies unchanged.
The Unanswered-Call Rule That Quietly Destroys Permission
Meta enforces call quality from the recipient's side, and the mechanism is unforgiving in production:
- 2 consecutive unanswered calls trigger a system message asking the business to reconsider calling that user.
- 4 consecutive unanswered calls automatically revoke an approved permission.
Read that against the request budget and the trap is obvious. Permission is expensive to obtain, capped at two asks a week, and can be destroyed by four calls that simply went to nobody. Sandbox environments for Tech Partners are far more forgiving — 25 permissions a day and 100 a week, with 5 consecutive rejections triggering a notice and 10 triggering revocation — which means testing will never surface how tight production really is. Design for production limits from day one.
The operational implication is specific: a call you place and do not follow through on is not neutral, it is destructive. Outbound calling belongs to a scheduled, staffed, confirmed-availability motion, never to a dialler working a list. Teams that treat calls as cheap outreach will burn permission at exactly the rate they burn goodwill, and a pattern of poor recipient signals feeds the same quality machinery behind WhatsApp Business account restrictions.
Configuring Call Settings: One Endpoint, Several Decisions
Calling configuration lives on a single endpoint, POST /<PHONE_NUMBER_ID>/settings, and the fields there are where most of your operational control sits.
Call hours are the highest-leverage setting
The call_hours object restricts inbound calls to times you are actually staffed. It carries a status of ENABLED or DISABLED, a timezone_id, a weekly_operating_hours array of day_of_week with open_time and close_time in 24-hour format, and a holiday_schedule supporting up to 20 date-based overrides with a date, start_time and end_time.
Configure this before you enable calling, not after. Outside call hours, Meta directs users to message instead of leaving them ringing into an empty room — which converts your worst voice experience into your normal messaging experience. For teams without genuine round-the-clock cover, this single object is the difference between voice helping and voice hurting, and it is a far more honest answer than pretending to run a 24/7 support operation you have not staffed.
Call icon visibility, callbacks and voicemail
The call_icon_visibility field takes DEFAULT, which shows the call button in the chat menu and on the business info page, or DISABLE_ALL, which hides it everywhere. That gives you a clean staged rollout: enable calling, keep the icon hidden, test with known numbers, then reveal.
A callback_permission_status of ENABLED or DISABLED controls whether users are prompted for permission after they call you — the automatic grant path described above, and the cheapest permission you will ever acquire. Voicemail is configured with a status, a triggers value of REJECT or TIMEOUT, and announcement media, so a missed call can leave you something to work with rather than nothing.
Three Signalling Architectures, and How to Choose
Meta supports three configurations, and the right one depends entirely on whether you already own telephony infrastructure.
| Configuration | Signalling | Media | Best for |
|---|---|---|---|
| Default | Graph APIs and webhooks | WebRTC with ICE, DTLS and SRTP | Teams with no existing telephony stack; least infrastructure to run |
| SIP with WebRTC | SIP over TLS | WebRTC with ICE, DTLS and SRTP | Contact centres routing WhatsApp calls into an existing SIP platform |
| SIP with SDES | SIP over TLS | SDES SRTP | Older SIP estates that cannot negotiate DTLS |
SIP is configured through a sip object with a status, a servers array of hostname and port, and optional request_uri_user_params. Opus is the default audio codec; an additional_codecs array accepts PCMA and PCMU, added on 23 March 2026 specifically for estates that cannot handle Opus.
If you do not already run a SIP platform, take the default. The SIP paths exist to let established contact centres treat WhatsApp as another trunk, and they carry the operational cost of a telephony estate. That build-versus-integrate calculation is the same one behind running the Cloud API directly versus going through a provider.
What Calls Actually Cost
WhatsApp Business Calling API billing is duration-based and differs sharply from messaging.
| Element | How it works |
|---|---|
| User-initiated calls | Free. All of them. |
| Business-initiated calls | Billed on duration in six-second pulses, fractional pulses rounded up — Meta's own example prices a 56-second call at 10 pulses, not 9.33 |
| Volume tiers | Rates fall as monthly call minutes rise, using the same tiering accrual as messaging |
| Tier-crossing calls | A call that spans a tier boundary is priced entirely at the lower rate of the higher-volume tier |
| Currencies | Rate cards in 15 currencies including USD, AED, SAR, INR, GBP, EUR, IDR and SGD effective 1 April 2026; Brazil (BRL) from 1 July 2026 |
| Permission requests | Billed at standard per-message pricing, separate from call charges |
| Payment method | A valid payment method is required before any call can be placed |
Two things follow. First, inbound voice is a free channel — the only cost is the staffing, which is the whole cost. Second, outbound voice has an economic floor that messaging does not: a 20-second call is billed as four pulses whether or not it accomplished anything, while a message costs the same regardless of how long the customer takes to read it. Model outbound voice against the per-conversation rates in WhatsApp Business API pricing before assuming a call is the cheaper touch.
What Voice Does to a Shared Inbox
Here is where most WhatsApp Business Calling API rollouts go wrong, and none of it is in the API documentation.
Concurrency is the real staffing shock
A competent messaging agent handles three to five conversations at once, because every one of them contains dead time while the customer types. A call has no dead time. One agent, one call, full attention, for its entire duration. A team that clears 200 chats a day will not clear anything close to 200 calls, and the honest planning number is closer to a quarter of that.
This is not a reason to skip voice. It is a reason to price it. Voice is a premium channel with premium unit economics, and it should be pointed at the conversations that justify it — escalations, high-value accounts, anything where a five-message misunderstanding becomes a ninety-second clarification.
The conversation record gets a hole in it
Every messaging channel produces its own transcript for free. Voice produces nothing unless you add recording and transcription. Without that, a customer's history reads as a coherent thread with an unexplained gap where the decision was actually made — and the next agent picks it up blind.
Whatever you attach the voice record to, attach it to the same conversation object as the chat. A call logged in a separate telephony system is a second silo, which is the exact problem omnichannel support exists to solve.
Routing cannot be borrowed from chat
Chat routing tolerates delay: assign to a busy agent and the customer waits a minute without noticing. Call routing does not — an unanswered call is abandoned in seconds, and four of them in a row revoke your permission outright.
Voice therefore needs a live availability model rather than a workload model: who is at their desk right now, not who has capacity today. Your existing routing rules are the right starting point but the wrong finishing point, and the same is true of chatbot-to-human handoff — a bot handing off to voice must confirm a human is genuinely available before it promises a call.
The Metrics That Actually Matter for Voice
Messaging metrics do not transfer, and reporting voice on chat KPIs will make a healthy channel look broken.
| Messaging metric | Voice equivalent | Why the swap |
|---|---|---|
| First response time | Answer rate and ring time | A call is answered or it is not; there is no partial first response |
| Resolution time | Average handle time | Handle time is continuous agent cost, not elapsed clock time |
| Unanswered messages | Abandon rate | Feeds directly into the consecutive-unanswered revocation rule |
| Conversations per agent | Occupancy | Concurrency is 1, so utilisation is the constraint |
Abandon rate deserves a named owner. It is the only metric that carries a platform penalty attached, and on a shared number that penalty lands on the channel your whole business runs on. Keep first response time benchmarks for messaging where they belong, run CSAT separately per channel so voice does not flatter or drag your chat numbers, and write voice into SLA rules your team will actually follow as its own target rather than an appendix to the chat SLA.
A Realistic Rollout Sequence
- Confirm the number is on the Cloud API and check its messaging limit against the 2,000-recipient gate.
- Subscribe the app to the
callswebhook field before enabling anything. - Configure
call_hourswith your real staffed hours, timezone and holiday overrides. - Enable calling with
call_icon_visibilityset toDISABLE_ALLand test with known internal numbers. - Set voicemail triggers so a missed call still produces a record.
- Reveal the call icon to inbound traffic only. Measure answer rate and abandon rate for a full month.
- Only then consider outbound — and only with a scheduled, confirmed-availability motion, never a list.
- Store
expiration_timestampper user and never let an outbound campaign fire against a lapsed permission.
Steps 6 and 7 are the ones teams skip. Inbound voice is free, needs no permission, works globally and carries no revocation risk. Outbound is billed, permission-gated, geographically restricted and revocable. They are different projects with different business cases, and running them as one is how a calling rollout ends up costing permission it cannot easily rebuy.
When Voice Is Worth It, and When It Is Not
Voice earns its place when conversations are complex enough that typing is the bottleneck, when the customer relationship justifies a synchronous channel, or when your market treats a call as the serious escalation path and a chat as the casual one. In much of MENA and South Asia that expectation is real, and a business that only ever answers in text reads as harder to reach than it is.
Voice is a poor fit when your volume is high and your queries are repetitive, when your team is small enough that one call blocks the entire chat queue, or when you cannot staff predictable hours — in which case call hours plus a hidden call icon is a legitimate permanent configuration, not a failure. Adding a channel you cannot answer is worse than not adding it. That logic is the same one behind adding a second WhatsApp number: capacity first, surface area second.
The Short Version
The WhatsApp Business Calling API puts voice on the number your customers already message, and the technical lift is small. The constraints are what matter: a 2,000-recipient messaging tier before you can call out, five markets where business-initiated calling does not work, permission granted for 168 hours at a time against a budget of one request per day and two per week, automatic revocation after four consecutive unanswered calls, and duration billing in six-second pulses on outbound while every inbound call is free. Configure call hours first, enable inbound before outbound, measure abandon rate as a platform risk rather than a service metric, and keep the call on the same conversation record as the chat. Every one of those constraints is documented and knowable — and every one is cheaper to design around before launch than to discover after your permission is gone.