WhatsApp API Error Code 10: Restore Permissions

Error code 10 on the WhatsApp Cloud API is an authorization failure. BSP documentation describes it as "Permission is either not granted or has been removed.". MessageBot's table lists the HTTP status as 403 Heltar states no status at all, so treat 403 as BSP-reported rather than settled.

Meta's public error-code reference could not be retrieved when this article was last checked, so the wording above is quoted from BSP documentation rather than from Meta. Confirm the current text against Meta's own reference before you build error handling on it.

Most guides get one thing wrong here. They present error 10 as a distinct error with its own meaning, when its documented description is word-for-word identical to code 200's. Context separates them, not text, so what you need is a diagnostic order rather than a definition. The WhatsApp Business API error code reference collects the related codes in one place.

What error code 10 means

Error 10 means the token on the request does not hold the permission that endpoint requires, or the business asset behind the request is no longer assigned to the identity that token represents.

Three things have to line up on every Cloud API call:

• The identity. Usually a system user, a non-human account inside Meta Business Manager that holds API access. It can also be a person's token, which is where many incidents begin.

• The permissions on the token, called scopes. Wati groups codes 200–299 as permission issues and tells teams to re-grant whatsapp_business_messaging and whatsapp_business_management. The first covers sending, the second account and template management.

• The asset assignment. The WhatsApp Business Account (WABA) and phone number must be assigned to that identity with a role that allows the action.

Break any one and calls that ran fine yesterday return error 10. Heltar's recommended action covers two: check the Access Token Debugger for the required permissions, and confirm the phone number is allowlisted. The walkthrough on setting up the WhatsApp Business API shows how these objects fit together.

Error 10 and error 200 share one description

You cannot separate error 10 from error 200 by reading the message. Heltar documents code 200 as "API Permission Permission is either not granted or has been removed." That sentence is identical to code 10's.

The consequence for your handler: never pattern-match on the title, because two codes produce the same string and BSP tables disagree on what titles mean. MessageBot and Wati both advise building logic on the numeric code, then reading the error_data or details field.

{
  "error": {
    "message": "Permission is either not granted or has been removed.",
    "code": 10,
    "error_data": {
      "details": "..."
    },
    "fbtrace_id": "..."
  }
}

Keep the fbtrace_id from every failed response. Dualhook advises retaining it for support escalation

One correction worth carrying: error 200 is widely published as meaning "no access token provided". No source we could reach supports that reading, and the documented description is a permission error, so treat it as unverified.

What usually changed in Meta Business Manager

In live cases, error 10 follows an administrative change to the business account rather than a change to your application. The failure timestamp is the best clue, because it maps to somebody's action in the Meta console.

These mappings are diagnostic guidance, not published Meta behaviour. Work down the table by blast radius: if every number failed at once, look at the identity and the WABA; if one number failed, look at that number. Accounts running multiple numbers on one WhatsApp Business Account hit the single-number version most often, and teams sharing access across agents should also check how their shared WhatsApp team inbox holds permissions.

Restoring access in Meta Business Manager, in order

Work from the asset outward: WhatsApp account first, then phone number, then the token.

1. Identify which identity the failing token belongs to. If nobody can say whose token it is, fix that first.
2. Open Business Settings for the business that owns the WhatsApp account, not one that merely has access.
3. Find the account under business assets and review who holds access: people, system users and apps.
4. Assign the system user with the access level your integration needs. Management and messaging access differ, so a token can send while failing on template calls.
5. Assign the phone number your requests use, and confirm it is allowlisted.
6. Check that your Meta app is still connected to the WABA. An app can lose the asset link while the system user keeps it.
7. Regenerate the token only if the debugger shows a scope missing.

Meta changes these labels periodically, so confirm each step against the console in front of you. For newly built rather than newly broken integrations, the material on WhatsApp API integration covers the same objects.

Verifying with the Access Token Debugger before you retry

Check the token before you replay traffic. Heltar's stated action for error 10 is to check the Access Token Debugger for the required permissions and confirm the number is allowlisted.

Four fields matter:

• App. Does the token belong to the app you think it does?
• User or system user. Does that identity still exist in the business?
• Expiry. An expired short-lived token also produces authorization failures.
• Scopes. Both whatsapp_business_messaging and whatsapp_business_management should be listed.

Once the token reads correctly, send one message to an internal test number instead of releasing the queue:

curl -X POST "https://graph.facebook.com/v<VERSION>/<PHONE_NUMBER_ID>/messages" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "messaging_product": "whatsapp",
    "to": "<TEST_RECIPIENT>",
    "type": "template",
    "template": {
      "name": "<TEMPLATE_NAME>",
      "language": { "code": "<LOCALE>" }
    }
  }'

If both scopes are present and the call still returns error 10, the gap is asset assignment, not the token. Go back to the WABA and phone number assignments.

Why retrying will not help

Retrying an error 10 cannot succeed, because nothing about the request changes between attempts. The token carries the same permissions the second time as the first.

Dualhook's retry classification puts authorization failures 0, 10, 190 and 200 in the non-retryable group, alongside validation failures such as 100 and 131008 and policy failures such as 368 and 130497. Its retryable group is a different set: 4, 80007, 130429, 131056, and transient failures 1, 2 and 131000. Backoff belongs to that second set.

So the error 10 branch should stop, not sleep. Park the messages for later replay, record the code and fbtrace_id, and page a human, because the fix lives in a console rather than in your service. Sibling articles cover the codes that do deserve backoff, including the articles on error 4 and error 130429, with the wider mechanics in the guide to WhatsApp API rate limits. If failures land at delivery instead, start with WhatsApp messages not being delivered.

Preventing recurrence

Most repeat incidents trace back to two habits: tokens tied to individual people, and asset assignments nobody audits.

• Hold API access in system users. A system user does not resign or change roles.
• Keep more than one business admin. A single admin is a single point of failure for every asset beneath them.
• Audit assignments after every offboarding. Record which system user holds which WABA and numbers.
• Alert on authorization errors separately from delivery errors. Auth failures are rare and total; delivery failures are common and partial. Mixed into one alert, the outage hides in the noise.
• Log the code, fbtrace_id and phone number ID on every failure. Without those, reconstructing an incident later is guesswork.

Access governance sits alongside the other duties covered in the material on WhatsApp API compliance. If token and asset ownership is repeatedly unclear, that is a fair question to raise when choosing a WhatsApp API provider.

Frequently Asked Questions

What causes WhatsApp API error code 10?

A permission the request needed is missing. BSP documentation describes error 10 as "Permission is either not granted or has been removed" (Heltar, retrieved 2026-08-24). In practice: the token lacks whatsapp_business_messaging or whatsapp_business_management, the WABA or number is no longer assigned to the identity holding the token, or that identity lost its role.

How do I re-grant the permission?

Reassign the WhatsApp asset to the system user in Meta Business Manager. Open Business Settings for the business that owns the account, select it under business assets, and assign the system user with the access level your integration needs. Assign the phone number too. Wati's guidance is to re-grant both scopes.

Is this the same as error 3?

No. Heltar documents code 3 as "API Method — Capability or permissions issue" at HTTP 500, while error 10 appears at HTTP 403 in MessageBot's table. Code 3 is disputed too: MessageBot lists it as "Recipient is the sender" at HTTP 400. Two BSP tables disagree on both its meaning and its status.

Why did it start failing without a deploy?

Because the change happened in Meta Business Manager, not your codebase. Someone removed an admin, edited a system user, unassigned a WABA or number, or rotated a token. Your service sends the same request; the platform stopped accepting the credentials behind it. Match the first failure timestamp against recent administrative activity.

Do I need a new access token after reassigning the asset?

Not always. Asset assignment and token scopes are separate. If the token still carries both scopes and only the asset link broke, it may work once the assignment is restored. If the Access Token Debugger shows a scope missing from the token itself, no reassignment fixes that and a fresh token is required.

Getting the integration unblocked

Error 10 is quick to fix once you know which of the three layers broke, and slow when nobody is sure who owns the token. Helo.ai is a Meta Partner with 25 years of enterprise communication experience and an AI-first, India-first approach to messaging, and can review how your WhatsApp account, system users and asset assignments are structured. Talk to an expert.