A product team decides to add voice to its WhatsApp integration. The expectation is a toggle: calling is switched on, the existing number starts taking calls, and the work is a week of front-end. What they find instead is a feature that sits behind a messaging-volume threshold they may not have reached, a webhook field they are probably not subscribed to, a per-user permission that has to be asked for and can be refused, and a daily call ceiling low enough that it changes the product design.
None of that is documented in one place, and almost none of it is visible until the number is already live. This is what the WhatsApp Business Calling API actually requires, and where projects stall.
What the Calling API is — and what it is not
The Calling API adds real voice calls over the WhatsApp Cloud API. Both directions are in scope: a WhatsApp user can call your business number, and your business can call a WhatsApp user. It runs on its own webhook events and its own permission model, entirely separate from the message-sending flow teams already have working.
What it is not: a feature of the WhatsApp Business app. Meta states the prerequisite plainly — the business number must be in use with Cloud API, not the WhatsApp Business app. For a lot of businesses that single line is the whole project, because it means migrating a number that customers already have off the app they have been running the business on.
whatsapp_business_messaging) for the business number, with a messaging limit of at least 2000 business-initiated conversations in a rolling 24-hour period.”Meta for Developers — Cloud API CallingThe gate nobody plans for: the messaging limit
Of the four prerequisites, three are configuration. The fourth is not. A messaging limit of at least 2,000 business-initiated conversations in a rolling 24-hour period is a tier the number has to have reached through its own messaging history and quality rating — it is not something switched on by request, and a newly registered number does not have it.
That inverts the usual project order. Calling cannot be the first thing a new number does. The number has to run a messaging programme first, at volume, without quality damage, long enough to be moved up the tiers. Teams that scoped calling as a two-week feature discover it is gated behind a several-month messaging track record they have not started.
Meta does relax this for development: the messaging-limit requirement does not apply when testing Calling API features with public test numbers and Sandbox accounts. Which is why calling so often works perfectly in staging and refuses to work in production — the environments are not running the same rules.
| Limit | Sandbox / test | Production |
|---|---|---|
| Connected calls per 24 hours | 100 | 10 |
| Call permission requests per day | 25 | 1 |
| Call permission requests per week | 100 | 2 |
| 2,000-conversation messaging limit required | No | Yes |
Read the production column as a product constraint rather than a rate limit. Ten connected calls in a rolling 24-hour period, and a single call-permission request per user per day capped at two per week, rules out any design that treats outbound calling as a volume channel. It is built for high-value, low-frequency contact, and a roadmap that assumed otherwise needs rewriting before a line of code is committed.
Permission is per user, and the user can say no
Calling a WhatsApp user requires explicit permission from that user. There is no account-level setting that grants it in bulk. One supported route is to request permission at the moment a user calls your business, with the permission interface appearing inside the user’s own WhatsApp client — you do not render it and you do not control it.
This creates a state machine most teams have not budgeted for. Every user is separately in a granted, declined, expired or never-asked state; the outbound request itself is rate-limited to a couple of attempts a week; and the CRM has to hold that state accurately or the integration burns its allowance re-asking people who already said no.
SIP silently changes the rules
Calls can be signalled over SIP instead of Graph API endpoints. But when SIP is enabled, calling-related webhooks are not sent by default — they have to be explicitly enabled. Integrations that switch to SIP and keep listening on the old events simply go quiet.
Changes are not immediate
After call configuration is updated, WhatsApp users may take up to 7 days to see those changes reflected. Launch plans that assume a config change lands the same afternoon will not match what customers actually experience.
Calling can be taken away from you
Calling is a privilege attached to the number, and it is withdrawn automatically. When negative user feedback reaches a threshold, Cloud API restricts calling functionality on that phone number for a period of 7 days. No appeal step runs first; the restriction is applied and the channel goes dark for a week.
A detail worth designing around: call permissions that users approved or declined while a number is paused remain valid. The permission ledger survives the outage, so the recovery problem is operational and reputational rather than a full re-consent exercise — provided the team knows that in advance instead of re-asking everyone and burning the weekly request cap.
Meta also publishes App Review guidance specific to the Calling API, separate from the general messaging permission guidance. Treating calling as covered by an existing whatsapp_business_messaging approval is a common and expensive assumption.
How the work is actually sequenced
Establish where the number really lives
On Cloud API, or still on the WhatsApp Business app? If it is on the app, the migration is the project and calling waits behind it — with real customer-facing risk during the move.
Check the messaging tier before promising a date
The current messaging limit and quality rating decide whether calling is available at all. If the number is below the required tier, the honest answer is a messaging-growth plan first, not a calling build.
Get the app, the WABA and the webhook aligned
The same app has to hold messaging permissions for the number, be subscribed to the WhatsApp Business Account, and be subscribed to the correct webhook fields — which differ depending on whether you use Graph endpoints or SIP.
Design the product around the production ceilings
Ten connected calls a day and two permission requests a week per user is the shape of the channel. This decides which use cases are viable and which have to stay on messaging.
Prepare the review submission as its own piece of work
Calling has its own review guidance and its own justification burden. The submission has to show a legitimate, consented, non-spam calling use case — which is a writing and evidence task, not a coding one.
Where WhatsApp calling setups go wrong
- The number is still on the WhatsApp Business app. Everything else is blocked until it is on Cloud API, and migrating a live customer-facing number is not a quiet change.
- The messaging limit was never checked. The build finishes, production refuses, and the real blocker turns out to be a volume tier that takes months to reach.
- It worked in Sandbox. Test numbers are exempt from the messaging-limit requirement and carry far higher call and permission ceilings. Staging success proves very little here.
- The app is not subscribed to the
callswebhook field. Or is subscribed to the WABA but with the wrong app. Call events never arrive and the failure looks like a network problem. - SIP was enabled without enabling SIP call webhooks. Calling webhooks are off by default under SIP; the integration goes silent with no error to debug.
- Outbound calling was designed as a volume channel. One permission request per user per day, two per week, ten connected calls per 24 hours. The roadmap, not the code, is what has to change.
- Permission state was not stored. Re-asking users who already declined wastes a weekly allowance that is measured in single digits.
- Config changes were assumed instant. Users may take up to seven days to see updated call settings; launch communications go out before the feature is visible.
- Calling was assumed to be covered by the existing approval. Meta publishes separate App Review guidance for the Calling API.
- Nobody planned for the 7-day restriction. Negative feedback past a threshold pauses calling on the number automatically, and there is no continuity plan for the week it is down.
Where this sits
The Calling API is not a hard feature to write. It is a hard feature to become eligible for, and the eligibility work — number platform, messaging tier, WABA and app wiring, permission design, and a review submission that stands up — all sits outside the codebase.
If that is the work in front of you, it is covered under the WhatsApp App Review service, with scope and pricing set out separately. Where the business behind the WhatsApp account is not yet verified — which blocks the wider Meta permission set as well — that is handled under Meta Business Verification.
An honest note. Meta sets and changes these thresholds itself, reviews every submission itself, and can restrict a number without warning. No consultant controls messaging tiers, review outcomes or restriction decisions, and no specific outcome or timeline can be promised. What can be controlled is that eligibility is confirmed before a date is committed, that the platform, permission and webhook wiring is correct the first time, that the product design fits the production ceilings, and that the review submission is prepared properly. This is review preparation and technical implementation support, and it is not affiliated with or endorsed by Meta.
Sources: Meta for Developers — Cloud API Calling (developers.facebook.com/docs/whatsapp/cloud-api/calling), Obtain User Call Permissions, Configure Call Settings, SIP, and the Calling API App Review Guidelines. Reviewed August 2026 — Meta changes calling thresholds, limits and review rules regularly; verify against the current pages before acting.