WhatsApp now lets some businesses call without asking permission first: here's the new quality-based calling model

Until now, the rule for calling a customer on WhatsApp through the Cloud API was simple and strict: first you ask for permission, then you dial. On November 6, 2026, Meta published a change in the platform changelog that flips that logic on its head. Eligible business numbers in "specific countries" are automatically enrolled in a quality-based business-initiated calling model, which allows calling without prior approval, unless the user has rejected the permanent permission or revoked one they had previously granted. The new model comes with permanent permissions and tier-based calling limits. If you have a bot or a call center built on the Calling API, this can change how you operate without you touching a single line of code: numbers that already had the Calling API enabled are migrated automatically.

What the announcement says exactly

The changelog entry is short, and it's worth reading it to the letter before jumping to conclusions. According to Meta:

Eligible business numbers in certain countries are automatically enrolled in the quality-based model when the Calling API is enabled.
Eligible numbers that already had the Calling API enabled are automatically migrated.
The model allows calling without prior approval, unless the WhatsApp user has rejected the permanent calling permission or has revoked one they had granted.
It supports permanent permissions and tier-based calling limits.

The entry links to a new section of the business-initiated calls guide. When we checked the public version of that guide, it wasn't showing it yet: it was still describing the previous flow, with permission as a requirement. So right now the fine print isn't visible to everyone.

How it worked until now

To understand the size of the change, here is the model Meta documents in its guides on business-initiated calls and call permissions:

Permission was mandatory. The guide says so in bold: before calling a user, you have to get their permission. If you don't have it, the call to POST <PHONE_NUMBER_ID>/calls returns error 138006.
Three ways to get it: send a permission request (a free-form message within the customer service window, or a template), enable callback_permission_status so the user gives you temporary permission when they call you, or have the user grant it from your business profile.
Temporary or permanent. Temporary permission lasts 7 calendar days (168 hours). Permanent permission doesn't expire, but it has the same limit on connected calls.
Caps per business-user pair: a maximum of 100 connected calls every 24 hours. That limit has gone up: according to the Calling changelog, it went from 5 to 10 per day in October 2025 and from 10 to 100 in December 2025.
Caps on requesting permission: one request every 24 hours and two every 7 days. And requests are billed as messages.
Penalty for not answering: after 2 consecutive unanswered calls, WhatsApp suggests the user reconsider the permission; after 4, it is automatically revoked.

Comparison between the prior-permission calling model and WhatsApp Cloud API's new quality-based model

What changes in practice

The biggest thing is the order of things. In the old model, permission was the front door. In the new one, according to the changelog, the door is open by default for eligible numbers and the user is the one who closes it, by rejecting the permanent permission or revoking it.

That has three direct consequences for anyone running a bot or a call center:

Your "ask for permission and wait" flow may stop being mandatory on eligible numbers. Less friction, fewer request templates to pay for, and fewer customers who never answer the request.
The migration is automatic. If your number already had the Calling API enabled and is eligible, you've already switched models. There's no button to press, so it's worth checking what the API tells you today.
A user's rejection weighs more. If someone rejected the permanent permission or revoked it, you can no longer call them. Your system has to store that state per user and respect it. The API already notifies you through the call_permission_reply webhook, which includes response (accept or reject), is_permanent, and response_source (user_action or automatic).

What we still don't know

There are more gaps than certainties here, and we're not going to fill them in:

Which countries. The announcement says "specific countries" and doesn't list them. The general Calling guide says business-initiated calls are available wherever the Cloud API is, except the United States, Canada, Egypt, Vietnam, and Nigeria, and that the country code of the business number is what counts. But that's general availability, not the list for the new model. If your number is Mexican, there's no way to know today, based on what's been published, whether it qualifies.
What each tier is worth. "Tier-based limits" doesn't say how many calls, whether per user or per number, or how you move up a tier.
How "quality" is measured. The announcement doesn't explain it. What is documented in the call settings is that if your calls get a lot of negative feedback (blocks and reports), Meta can restrict the number's calls: first it sends an email warning and an account_update webhook with violation_type LOW_BUSINESS_INITIATED_CALLING_QUALITY, and if the threshold is reached, it pauses business-initiated calls and permission requests for 7 days.
What happens to the old limits. It's unclear whether the rules about 2 and 4 unanswered calls or the cap of 100 connected calls stay the same under the new model. A related detail: on October 29, the changelog recorded that "an outdated daily call initiation limit" was removed from the business-initiated calls guide.

My take

The name "quality-based" looks a lot like how WhatsApp already handles messages: according to its messaging limits documentation, to raise your capacity Meta analyzes the quality of what you send. My read is that Meta is bringing that same logic to voice: it lets you call with less red tape and, in exchange, measures you by how people react. That's an interpretation, not something the announcement says.

If so, the risk moves somewhere else. Before, the brake was bureaucratic: no permission, no dialing. Now the brake is reputational: if you call people who don't want you to call them, they block you, they report you, and your number loses the ability to call. A call center that reads this as "open bar for cold calling" is going to burn through its number fast. For bots, the change is good news: an "book your appointment and we'll call you" flow gets simpler. That said, it's worth continuing to ask for explicit permission when it makes sense, because an accepted permanent permission is still the best signal that the call is welcome.

What to check if you already use the Calling API

I haven't tested it; this comes from Meta's official documentation.

Check your errors. If you stop getting 138006 when calling users without permission, your number is probably already on the new model.
Store permission state per user. Process every call_permission_reply and flag the reject ones, both from user_action and from automatic.
Listen for account_update. The low-quality warning arrives there before the 7-day pause. Make sure someone actually receives that alert and it doesn't get lost in a log.
Watch the app's contact email. Meta also sends restriction notices there.
If you share a number between providers, since November 2, Calling requests accept messaging_account_id to indicate which messaging account the call belongs to.
Wait for the full guide before redesigning your flow: the section linked in the changelog is the one that will spell out countries, tiers, and rules.