Yesterday morning our own auto-posting pipeline went quiet. No posts, no obvious error in the dashboard, just silence. The token debug tool said the token was valid. It wasn’t a token problem at all.

What the API actually returns

When Meta flags your Page and requires identity confirmation, the Graph API stops accepting publishing calls and returns this:

{
  "error": {
    "message": "The action attempted has been deemed abusive or is otherwise disallowed",
    "type": "OAuthException",
    "code": 368,
    "error_subcode": 1390008,
    "fbtrace_id": "YOUR_TRACE_ID"
  }
}

The word “abusive” sends you hunting for policy violations. Dont. The subcode 1390008 is the real signal: it means a Page-level checkpoint is blocking the action, not a bad token and not a policy strike you can appeal.

A genuinely expired or revoked token looks different:

{
  "error": {
    "message": "Error validating access token: Session has expired",
    "type": "OAuthException",
    "code": 190,
    "error_subcode": 463
  }
}

Code 190 means token trouble. Code 368 means the Page itself is held. Two completely different fixes.

How to tell them apart in your logs

Add this check wherever you handle Graph API errors:

if error.get("code") == 368:
    # Page checkpoint - token is fine, human action needed
    alert_team("Page checkpoint on Page ID: " + page_id)
elif error.get("code") == 190:
    # Token expired or revoked - trigger re-auth flow
    refresh_token(page_id)

Log the fbtrace_id too. If you end up on a Meta support chat it’s the first thing they ask for.

Where to find the checkpoint

Meta does not send an email. There is no notification in the Page inbox. You have to go looking.

  1. Go to business.facebook.com and switch to the affected Business Portfolio.
  2. Open Settings ’ Pages and click the Page in question.
  3. Look for a yellow or red banner at the top of the Page overview. It will say something like “Confirm your identity to keep using this Page” or “Your Page has been restricted.”
  4. If you see nothing there, open the Page directly at facebook.com/YOUR_PAGE_SLUG while logged in as a Page admin. The prompt sometimes only appears in the consumer interface, not Business Suite.
  5. Follow the confirmation flow. For our Page it asked for a government ID upload from the primary admin account. The review took about four hours.

Once Meta clears the checkpoint, the same token works immediately. No re-auth, no new token generation, nothing to change in your app.

Verify the token was never the problem

Before you start revoking and regenerating tokens, run this call with your existing Page access token:

GET https://graph.facebook.com/debug_token
  ?input_token=YOUR_PAGE_ACCESS_TOKEN
  &access_token=YOUR_APP_ID|YOUR_APP_SECRET

A healthy response looks like this:

{
  "data": {
    "app_id": "YOUR_APP_ID",
    "type": "PAGE",
    "is_valid": true,
    "expires_at": 0,        // 0 means never-expiring Page token
    "scopes": ["pages_manage_posts", "pages_read_engagement"]
  }
}

"is_valid": true with the right scopes present means the token is fine. Stop there. The problem is upstream of the token.

What triggers a 368 checkpoint

Meta hasn’t published a definitive list, but from what we saw and from developer forum threads, the common causes are:

  • Unusual publishing volume in a short window (our pipeline had queued up a backlog and fired it all at once after a brief outage).
  • A new admin added to the Page from an account Meta doesn’t recognise.
  • The Page crossing a follower threshold that triggers an automated review.
  • Geographic mismatch between the admin account location and the Page’s usual activity.

Thats the frustrating part: the trigger is often mundane, but the API error reads like you’ve done something seriously wrong.

The one-line fix for your monitoring

Add a separate alert for 368 that says “Page checkpoint - check Business Suite” rather than lumping it in with auth failures. It will save the next person on your team an hour of token debugging that goes nowhere.

If you’re building or maintaining a social publishing integration and want a second pair of eyes on your error-handling, see how we work and what it costs.