Facebook Graph API Error Codes and Subcodes: Full List

Failed calls return an error object. Log the whole object, not just the message, because the message text can change while the numbers stay put.

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

• code: the stable category. Branch on this first.
• error_subcode: the specific cause. Not every error has one.
• type: the error class, such as OAuthException. Too broad to branch on.
• error_user_title and error_user_msg: text you can show the end user, in the request's locale.
• fbtrace_id: an internal ID for Meta support. It expires quickly, so store it with the failure when it happens.

These come from the error-handling guide. The third column is the action that guide recommends, shortened.

Code 190 always means the token cannot be used. The subcode decides whether your app can fix it alone or the person has to act. Meta lists seven authentication subcodes, and the Pages API adds an eighth.

Only 2069032 is a bug in your code. The rest are account state, so retrying the same request never helps. The Instagram API error 190 guide covers the same code on the Instagram side, and how to get a Facebook Page access token covers the exchange that fixes 2069032.

From the Pages API error reference:

Code 100 is an invalid parameter. With subcode 33 the message reads "Unsupported get request. Object with ID ... does not exist, cannot be loaded due to missing permissions, or does not support this operation." Meta documents it in the Messenger Platform reference, and the same message comes back from other Graph API object reads, Instagram included.

Three causes, in the order worth checking:

1. The ID is wrong: a typo, an ID from another app, or an object that was deleted.
2. The token cannot see the object: a user token reading a Page object, or a Page token missing the permission the edge needs.
3. The object exists but does not support that edge or field.

On Instagram the same pair often appears right after creating a media container, when the object is not readable yet. The code 100, subcode 33 deep dive walks through that case.

The rate-limiting reference splits limits into Platform limits and Business Use Case (BUC) limits. If both could apply, BUC limits take precedence.

All of these are retryable, but only after a wait. Retrying at once keeps the counter high. The Facebook API rate limit guide explains how the usage headers count down.

The Pages API reference lists these as standalone numbers. None of them is a broken integration: the post or Page simply does not qualify.

• 2874008: Page insights need at least 100 Page followers.
• 2932001: the post must be public.
• 2932003: on a shared post, only the owner of the original post gets insights or can boost.
• 2932004: you must be the creator of the post.
• 2932005: someone tagged your Page; only the post's creator has insights.
• 2932006 / 2932007: profile-picture and cover-photo posts never have insights. Add the photo to a new post instead.
• 2932009: live videos are not supported.
• 2932010: the info is not available right now for this post.

If your integration also replies in the Page inbox, these are the ones from the Messenger reference:

Sort every error into one of five outcomes, because each one needs a different owner:

1. Reconnect (190 with 458, 460, 463, 467; 190 with no subcode): stop retrying, mark the account as disconnected, and ask the person to log in again.
2. Person must act on Facebook (190 with 459, 464; 492; 1/2853006): show error_user_msg if present and wait.
3. Your code is wrong (190/2069032, 200/2069030, 200/2069031, 100/33): alert your team; retrying the same request fails the same way.
4. Retry later (1, 2, 4, 17, 32, 341, 368, 613): back off with jitter and cap the attempts.
5. Change the content (506, 1609005): edit the post or fix the link before trying again.

Branch on code first and use error_subcode only to refine. Meta adds subcodes without much notice, so an unknown subcode should fall back to the handling of its code, not crash the job.

This sorting is the part most teams rebuild for every network. In PostGate, an authorization failure during publishing moves that destination to awaiting_reconnect and fires a profile.reauth_required webhook with reason publish_auth_error, so you handle one event instead of a list of Meta subcodes.