Any error code between 200 and 299 returned by the WhatsApp Business API is an authorization failure. Wati groups the block under one label: "Errors 200-299: Permission Issues", caused by permissions "revoked or not granted", with the fix being to re-grant the whatsapp_business_messaging and whatsapp_business_management scopes. The best documented member is code 200: "API Permission - Permission is either not granted or has been removed", at HTTP 403
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 write this range up as a list of codes with a distinct invented meaning for each, when the useful fact is that they are all non-retryable permission failures sharing one diagnostic path. For the wider set, see the WhatsApp Business API error code reference.
Why the error text will not tell you which problem you have
Because the descriptions are not unique. Code 10 is documented as "Permission is either not granted or has been removed", and code 200 carries word-for-word the same sentence. Code 10 sits outside the 200-299 block and code 200 sits inside it. If two codes in different ranges cannot be told apart by their text, the text is not a diagnostic signal.
We could verify a published description for code 200 only. Per-code meanings for 201, 210, 230 and the rest are not published by any source we could reach, and popular guides fill that gap with meanings they appear to have inferred. One repeated claim is that code 200 means "no access token provided"; no reachable source supports it.
So branch on the numeric code for the category, then read error_data and details in the response body for the cause.
The diagnostic order that works for every code in the range
Work through these in order and stop at the first step that fails.
- Read the full response body. Log
error_data,details,type,codeanderror_subcodefirst. The missing capability is usually named there. - Inspect the token in the Access Token Debugger. Confirm
whatsapp_business_messagingandwhatsapp_business_managementare both listed, and check the expiry. Heltar gives this step for permission errors, and says to generate a new token if the scopes are missing. - Check which app and asset the token belongs to. A token issued for one app cannot act on another app's WhatsApp Business Account. System user tokens are the usual production choice, but the WABA and phone number still need assigning to them.
- Confirm the phone number is allowlisted and assigned. Heltar lists allowlisting alongside the token check.
- Check your access level. If the caller is not a test user, developer or admin on the app, Standard Access refuses it.
- Check whether a permission was revoked. An admin removed from Business Manager, a reissued token or a changed app role can strip a scope that was there before.
- Keep the
fbtrace_id. Dualhook advises retaining it for support escalation. Without it, Meta support cannot look up the call.
If your integration is new rather than broken, the WhatsApp Business API setup walkthrough covers the account structure these steps assume.
The two permissions, and what each one covers
A WhatsApp app needs two scopes. public_profile is granted automatically when the Meta app is created.
Permission | Covers | Typical failing call |
|---|---|---|
| Sending messages and reading message status |
|
| Managing the WABA: templates, phone numbers, account settings | Template create, list and edit calls |
| Granted automatically at app creation | Not usually the cause of a 200-299 error |
A token holding only the messaging scope sends messages and fails on template management, so the error appears only when a campaign build step runs. Teams handling template creation and approval hit this more often than teams that only send.
Standard Access vs Advanced Access
Standard Access works only with test users, developers and admins explicitly added to the app. Advanced Access, granted after App Review, lets the app act for any user who grants the permission .
Standard Access | Advanced Access | |
|---|---|---|
Who the app can act for | Test users, developers, admins on the app | Any user who grants the permission |
App Review needed | No | Yes |
Suitable for | Development and internal testing | Production and customer accounts |
Typical failure symptom | Works for your own account, 403 for everyone else | Not applicable once approved |
The last row is the giveaway. If calls succeed under your own developer account and fail with a permission error for every customer account, you are on Standard Access.
What App Review asks for
App Review is mandatory before Advanced Access is granted, and the submission requires screen recordings that show message sending and template creation
Twilio's instruction is direct: request advanced access for the whatsapp_business_messaging and whatsapp_business_management permissions.
Record the flows end to end and show the actual product, not a mockup. Whether separate verification of your business is also required is something we could not confirm against Meta's own App Review documentation in this run, so check Meta's current requirements before planning the timeline. Build the review window into your launch schedule; you cannot shorten it from the code side. Reviewing your WhatsApp API compliance position first is worth the time.
Handling the range in code: alert loudly, never retry
Treat 200-299 as a hard stop. Dualhook classifies auth failures, listing 0, 10, 190 and 200 among them, as non-retryable: retrying without changing the token or its permissions cannot succeed. A retry loop here burns Graph API call budget and can add a rate-limit fault on top, a separate problem covered in the guide to WhatsApp API rate limits.
Three rules for your error handler:
- Match on the numeric range, not the message string. A regex over the description breaks when Meta rewords it.
- Page a human immediately. These errors do not clear on their own, and every queued message behind them fails the same way.
- Log
fbtrace_id, the app ID, the phone number ID and the fullerror_dataevery time.
Log the phone number ID because permission assignment is per asset, which matters most for teams running multiple numbers on one WhatsApp Business Account. Error 10 and error 200 have their own articles in this series. Where the failure is a delivery problem rather than an authorization one, start with WhatsApp messages not being delivered.
Frequently Asked Questions
What is the 200-299 error range in the WhatsApp API?
It is the authorization block. Wati groups codes 200 to 299 as permission issues caused by scopes revoked or never granted, and code 200 returns HTTP 403. Treat any code in the block as a sign that your token lacks a permission for the call you made, not as a fault with its own fix.
How do I identify the exact problem behind the code?
Read the response body. The error_data and details fields carry the cause, and they are the authoritative signal because per-code descriptions for most of this range are unpublished. Then check the token in Meta's Access Token Debugger for both WhatsApp scopes and the expiry, and confirm the phone number is assigned to that app.
Which permissions does a WhatsApp app need?
Two: whatsapp_business_messaging for sending messages and reading status, and whatsapp_business_management for templates, phone numbers and account settings. public_profile is granted automatically when the Meta app is created. A token holding only the messaging scope sends messages and fails on every template management call, which makes the fault look intermittent.
Do I need business verification to fix this?
What is documented is that Advanced Access requires App Review, and that the submission includes screen recordings showing message sending and template creation. Whether a separate business verification step is also required is not something we could confirm against Meta's own documentation in this run. Check Meta's current App Review requirements directly.
Why does retrying not help?
Because nothing about the request changes between attempts. Dualhook classifies auth failures including code 200 as non-retryable, meaning the call cannot succeed until the token or its permissions are altered. Backoff and jitter suit rate limits and transient faults, not permission errors. Fail fast, alert a human, and hold the queue.
Get help with a permission failure you cannot clear
Permission errors that survive a token refresh usually trace back to how the app, the WABA and the phone number are assigned to each other. Helo.ai is a Meta Partner with 25 years of enterprise communication experience. Talk to an expert about your access setup.
