Messenger error 190: Invalid OAuth access token

Code 190 means the Page access token your server presented is not valid: expired, revoked, malformed, or issued for a different app or Page than the one you are calling. Nothing else about the request was even evaluated, authentication is the first gate, so the recipient, window and payload are all irrelevant until the token is fixed.

On Messenger this failure has a distinctive symptom: the bot goes half-dead. Webhook deliveries continue, because the subscription does not depend on your token, so your server keeps receiving messages; every reply then fails with 190. From the outside the bot "reads" messages but never answers, which is why 190 sits near the top of the Messenger silent-bot checklist.

Tokens die for concrete reasons. Short-lived user tokens expire in hours, and a Page token derived from one can die with it unless you exchanged for a long-lived token first. Any password change, logout-everywhere, or two-factor reset by the person who granted the token invalidates it. So does removing that person's role on the Page or app, deauthorizing the app, or Meta security checkpoints on the granting account. Graph API error subcodes narrow it down when present: 458 (app not installed), 459 (user checkpointed), 460 (password changed), 463 (token expired), 464 (unconfirmed user), 467 (invalid token), 492 (the user behind the Page token no longer has an appropriate role on the Page).

What is NOT wrong: your app review status and permissions, missing pages_messaging surfaces as 200 or 230, not 190, and a token can be perfectly valid yet unauthorized. Fixing 190 means replacing the credential, not resubmitting for review.

{
  "error": {
    "message": "Invalid OAuth access token.",
    "type": "OAuthException",
    "code": 190,
    "error_subcode": 463,
    "fbtrace_id": "BLBz/WZt8dN"
  }
}

Issue tokens from a role that will not churn, a Business Manager system user where possible, exchange for long-lived tokens as a build step, and store them in a secret manager rather than code. Monitor with a scheduled token introspection so expiry becomes a ticket, not an outage. Keep one runbook page: who can re-grant, which scopes are needed (pages_messaging, pages_manage_metadata), where the token lives. Token hygiene issues on the Instagram side look identical; see the Instagram messaging guide.