Error 10 has a distinctive signature: it usually appears on an integration that worked perfectly until someone changed something in Meta Business Manager. Meta documents it as "Permission Denied" with an HTTP status of 403, and a recommended action of using the access token debugger to verify that your app has been granted the permissions required by the endpoint (Meta for Developers, WhatsApp error codes reference, retrieved 2026-08-17).
The word that matters in the sheet's own framing of this code is removed. A permission that was never granted usually surfaces as error 3 during build. Error 10 more often means a permission that existed, was relied upon, and is now gone — which makes it as much an access-governance problem as a technical one.
This guide covers what removes a permission, how to restore it, and the controls that stop an administrative change taking your messaging offline. For the wider failure surface, our WhatsApp Business API error codes reference indexes the rest.
What Removes a Permission
Five changes account for nearly all real error 10 incidents, and none of them happen in your codebase.
An employee was offboarded. If the token or the app connection was tied to a person's Meta account rather than to a system user, removing that person's access removes the integration's access with them. This is the same root cause behind the personal-token pattern that produces error 190.
A business asset was unassigned. Someone tidying Business Settings removes the WhatsApp Business Account or the app from a system user without knowing what depends on it. The system user still exists and its token is still valid, which is why the failure is a 403 rather than a 401.
A system user's role was downgraded. Admin to Employee is a common change during a permissions audit, and it silently removes the ability to manage templates and phone numbers while leaving message sending intact. The signature is that sends work and template operations fail.
Business Manager was reorganised. A merger, a brand split, or moving assets between business portfolios can break asset assignments that nobody re-created afterwards.
A permission was revoked at the app level. Less common, but an app-level permission change invalidates it for every token issued from that app.
Diagnosing Which One You Have
Start with Meta's recommended action, then read the result against the causes.
curl -X GET "https://graph.facebook.com/v23.0/debug_token?input_token=YOUR_TOKEN&access_token=YOUR_TOKEN"What you see | Likely cause |
|---|---|
| App-level permission revoked, or token predates the grant |
| Role downgraded, or management permission removed |
Scopes present but the call still 403s | Business asset unassigned from the system user |
| Not error 10 territory — the credential itself is dead |
| A person's token in production; the person likely changed or left |
The most informative signal is asymmetry. If message sends succeed and template operations fail, you are looking at a management-scope or role problem rather than a wholesale revocation. If everything 403s, an asset assignment has almost certainly been removed.
Restoring Access
1. Find out what changed and when. Business Manager keeps an activity record. Correlate the first error 10 in your logs with recent changes to users, system users, or asset assignments. Skipping this means you fix the symptom and repeat the outage next quarter.
2. Re-assign the business assets. In Meta Business Settings → Users → System users, select the system user and use Add assets to reassign both the app and the WhatsApp Business Account. The WABA needs full control for management operations.
3. Restore the role if it was downgraded. Admin for a system user that manages templates and phone numbers; Employee is sufficient only for sending.
4. Confirm the app-level permissions. whatsapp_business_messaging and whatsapp_business_management must both be granted at the app.
5. Generate a fresh token. This is the step teams skip. Restoring a permission does not retroactively add it to an existing token. Generate a new one from the system user, verify it with debug_token, and deploy it.
6. Verify with a test send before resuming the queue.
Preventing the Next Outage
Error 10 is fundamentally a governance failure, so the durable controls are organisational.
Never depend on a person's token in production. A system user token belongs to the business and survives staff changes. If debug_token reports type: USER, that is a scheduled outage waiting for someone to change jobs. The error 190 guide covers creating a system user properly.
Document the dependency where the change happens. Name the system user something self-describing such as whatsapp-prod-sender, so anyone auditing Business Settings can see it is load-bearing before they unassign anything.
Include WhatsApp assets in your offboarding checklist. When someone with Business Manager admin access leaves, re-verify system user roles and asset assignments as part of the process rather than discovering the gap through a 403.
Alert on the first occurrence. Error 10 is usually all-or-nothing for the affected operation type. A high-severity alert on the first code: 10 catches it before a campaign queue drains into failures.
Do not retry. A 403 will 403 again. Pause the sender, hold messages in a durable queue, and resume once debug_token confirms the scopes are back. Retrying against a permission failure can add rate limit errors to the incident.
For businesses running several numbers or brands, asset assignment gets more complex and more fragile — see multiple numbers on one WhatsApp Business Account. If you are moving between providers, re-check assignments after the migration, as covered in switching WhatsApp API provider.
Frequently Asked Questions
What causes WhatsApp API error 10?
A permission required by the endpoint is missing or was revoked. Meta documents it as "Permission Denied" with HTTP status 403 and recommends the access token debugger to verify permissions. In practice the trigger is usually an administrative change in Meta Business Manager: an offboarded employee, an unassigned business asset, a downgraded system user role, or a reorganised business portfolio.
What is the difference between error 10 and error 3?
Error 3 returns HTTP 500 and is documented as a capability or permissions issue with the API method, typically meaning an access level or capability the app never had. Error 10 returns HTTP 403 and is documented as "Permission Denied," typically meaning a permission that existed and is now gone. Error 3 is common during build; error 10 is common after an admin change.
I restored the permission but error 10 continues. Why?
Because an existing token does not gain scopes retroactively. After restoring an app permission, a system user role, or an asset assignment, you must generate a new token and deploy it. Verify with debug_token that the new token carries whatsapp_business_messaging and whatsapp_business_management before resuming sends.
Sends work but template operations fail. Is that error 10?
Very likely. That asymmetry points to a missing whatsapp_business_management scope or a system user downgraded from Admin to Employee, which leaves messaging intact while removing the ability to manage templates and phone numbers. Check the role in Business Settings before regenerating anything.
Should my application retry after error 10?
No. A 403 is a standing refusal, not a transient failure, so a retry produces the same result. Pause the sender, alert, hold messages in a durable queue, and resume after debug_token confirms the permissions are restored on a freshly generated token.
Fix the Governance, Not Just the Token
Error 10 is one of the few WhatsApp errors where the root cause is almost never in your system. Someone reorganised Business Settings, offboarded a colleague, or tightened a role during an audit, and a dependency nobody had documented broke.
Re-assigning the asset and regenerating the token restores service in about ten minutes. What stops it recurring is naming the system user so it is obviously load-bearing, keeping WhatsApp assets on your offboarding checklist, and making sure no person's individual account sits in the production dependency chain.
Want the permission chain managed outside your Business Manager churn? Helo.ai is a Meta Partner and maintains system user configuration, asset assignment, and credential health for enterprise WhatsApp programmes, with monitoring that catches a revoked permission before your queue does. Talk to an expert.
Next: error 3 if the permission was never granted rather than removed, or error 190 for putting a durable system user token in place.
