Messenger error 230: Requires pages_messaging permission

Code 230 belongs to the Graph API's 200-299 block, which Meta's error-handling guide defines as "API Permission (multiple values depending on permission): permission is either not granted or has been removed." For Messenger sends, 230 is the specific value that fires when the access token simply does not carry pages_messaging: the scope was never requested during authorization, was declined, or has since been removed.

It is worth separating 230 from its neighbor 200, because the fixes differ. Code 200 typically means the permission exists on the token but has not passed App Review, so messaging works for app admins, developers and testers and fails for everyone else. Code 230 means the token itself lacks the scope, so sends fail for everyone, including you. If your bot cannot message even its own developers, look here first.

The token is the unit that carries permissions, which produces the classic confusion: the app has pages_messaging approved in the dashboard, yet sends fail, because the Page token in production was generated before the scope was added, or was generated through a tool that requested a narrower scope list. Regenerating the token through the same flow reproduces the same gap. Inspecting the actual token in the Access Token Debugger, its scopes field is authoritative, settles the question in seconds.

What is NOT wrong: the token's validity (an invalid token is 190), the recipient, and the messaging window. Also distinct is code 10, "application does not have permission for this action," which covers feature-level denials rather than a missing OAuth scope. The permission chain, app scope, App Review status, token scopes, Page role, is walked step by step in the Messenger troubleshooting guide.

{
  "error": {
    "message": "(#230) Requires pages_messaging permission to manage the object",
    "type": "OAuthException",
    "code": 230,
    "fbtrace_id": "BLBz/WZt8dN"
  }
}

Treat scopes as part of the deployment contract: a startup check that introspects the production token and asserts pages_messaging is present catches this before the first customer message does. Keep one canonical authorization flow with the full scope list, and never hand-mint tokens from the Graph API Explorer into production. When onboarding new Pages to a Messenger chatbot, verify the token's scopes as part of the connect step rather than trusting the dashboard's app-level view.