WhatsApp error 3: capability or permission missing

WhatsApp Cloud API error 3 (Capability or permissions issue): how it differs from errors 0, 10, 190 and 200, and how to fix it.

WhatsApp error 3 means the application calling the Cloud API lacks the capability or permission that this specific endpoint requires. The token can be perfectly valid: it is the app that is not allowed to make that particular call. You fix it by granting the missing permission or feature, never by sending the same request again.

What does error 3 mean?

Meta lists it among the Cloud API's authorization errors:

"Capability or permissions issue." — Meta, Cloud API error codes

The suggested fix: check in the access token debugger that the app was granted the permissions the endpoint requires. The general Graph documentation names this code "API Method" and sums it up as "Make sure your app has the necessary capability or permissions to make this call" (Meta, Graph API error handling).

How do you tell it apart from the other authorization errors?

The Cloud API's six authorization codes each answer a different question. The wording is from Meta's error page:

Code	Meta's wording	What is missing
0	"We were unable to authenticate the app user."	An authenticable user behind the token
190	"Your access token has expired."	A token that is still valid
3	"Capability or permissions issue."	An app capability or permission for this endpoint
10	"Permission is either not granted or has been removed."	A permission, or eligibility for the API being called
200	"No access token was provided."	A token in the request
200 to 299	"Permission is either not granted or has been removed."	A permission, or the user's access to the account

Keep the boundary in mind: with 0 and 190 the token itself is dead; with 200 ("No access token was provided") there is no token at all; with 3, 10 and 201 to 299 the token is alive but does not give access to what you are asking for.

When does error 3 happen?

The token was generated without the WhatsApp permissions, or for a different app from the one making the call. When generating it, Meta asks you to select the app used for the calls and the whatsapp_business_management and whatsapp_business_messaging permissions (Meta, WhatsApp support).
The endpoint belongs to a feature the app or account has not enabled. The Marketing Messages API is one example: it requires onboarding completed by a portfolio user with full control (same page). Until that onboarding is done, the call has no reason to succeed.

Where do you see it in Genuka WA?

Genuka WA puts code 3 in the config class: a token, permission or registration problem that a retry will not fix.

Channel	What you get
`POST /api/v1/messages`	`409`, `"error": "send_config"`, `meta.code: 3`
`POST /api/v1/templates`	`403`, `"error": "meta_rejected"`, `meta.code: 3`
`MARKETING` campaign	If the Marketing Messages API refuses the send with a 4xx permission or parameter error (codes 3, 10, 100…), Genuka resends the message through the regular `/messages` endpoint; if that refuses too, the recipient turns `failed`

The last case is deliberate. Meta exposes no flag that says beforehand whether an account has access to the Marketing Messages API: Genuka tries it, treats a 4xx permission-type refusal as "feature unavailable on this account" and resends the message the regular way. The fallback is silent: only the result of the send on /messages is recorded. It does not cover every refusal: Meta also reports ineligibility with code 134102 and an HTTP 500 status (Meta, Marketing Messages API error codes); Genuka treats it as a transient outage, retries it, then marks the recipient failed.

How do I fix error 3?

If you call the Cloud API with your own token

Inspect the token in the access token debugger: which app does it belong to, and does it carry whatsapp_business_management and whatsapp_business_messaging?

Regenerate it if needed, selecting the right app and both WhatsApp permissions. For a production service, prefer a system user token (Meta, Access tokens).

Check the requirements of the feature you are calling. If the endpoint belongs to a feature that requires onboarding or eligibility, such as the Marketing Messages API, complete that first before trying again.

If you go through Genuka WA

You have no Meta token to fix: a code 3 on a send or a template creation is Genuka's to handle. Contact support with the response's x-request-id header and meta.traceId. If you are sending an advanced message type through the raw field, say so: that is where a feature that is not enabled is most likely to show up.

How do I prevent error 3?

Generate every token for the right app, with only the WhatsApp permissions you need.
Before adopting a new Meta feature, read its access requirements: many need their own onboarding or eligibility.
Alert on the config class, not on the message text: Meta warns that error titles will eventually be deprecated.

10: permission not granted or removed, or API not eligible.
200: no token, or a user without access to the account.
190: the token has expired.
0: Meta could not authenticate the app user.

FAQ

What is the difference between error 3 and error 10?

Meta ties 3 to a capability or permission missing for the endpoint, and 10 to a permission not granted or removed, including when the account is not eligible for the API being called. In both cases the token is alive; what it authorizes is not enough.

Should I retry a call refused with error 3?

No. As long as the permission or feature is missing, the same request will fail the same way.

Can a marketing campaign recipient fail with error 3?

Yes. A refusal from the Marketing Messages API alone never reaches you: Genuka resends the message through /messages, and that second send is the one that counts. If the recipient still turns failed with a permission reason, /messages refused it too: the problem affects the number, not just the Marketing Messages API, and is one for Genuka support.