Instagram Graph API error codes: the complete index

• 190 — Invalid or expired access token. Common subcodes: 460 (password or security setting changed since the token was issued), 463 (token expired), 467 (token invalid — often issued for a different app or already revoked). Requires reconnecting the account; no amount of retrying the same request will fix it.
• 102 — Session key invalid or no longer valid. Usually paired with a token that was valid recently but has since been invalidated server-side (for example, the user removed your app's access from their Meta account settings).
• 2500 — Generic "error validating parameters." This code covers a wide range of malformed-request cases, not just authentication — see the dedicated post below for what is confirmed and what is community-reported about its publishing-flow triggers.

• 10 — Permission denied. The token is valid, but the app or the granted scopes do not cover the action being attempted — most often a missing instagram_business_content_publish, instagram_business_manage_comments, or similar business-scoped permission.
• 200 — Generic permissions error. A broader bucket than code 10; can appear when the connected account's role or the app's App Review status doesn't cover the requested operation, even if the specific scope was technically granted.
• Deprecated scope names (instagram_basic and related Instagram Basic Display API permissions) will produce permission errors on connections that used to work — see the dedicated migration post below for the full old-to-new scope map.

• 2500 — "An ID has already been specified" and other parameter-validation failures during container creation. Meta does not publish a definitive root-cause list for this message, and public reports of the exact trigger vary; the best-documented, verifiable cause of container-creation failures in general is a media URL Meta's servers cannot fetch (not publicly reachable, wrong content-type, or expired signed URL) — see the dedicated post below for what is and is not confirmed about this specific message.
• 100 (subcode 33) — Object does not exist, or cannot be loaded with the current permissions. In a publish flow this usually means an invalid or already-expired container ID, or an ID for the wrong node type.
• 9007 (subcode 2207027) — "The media is not ready for publishing." Meta's own documentation frames this as a not-yet-ready state to retry after a short wait; in practice it is also widely reported for a container that already expired or was already published, so treat it as "this container is not currently publishable" rather than assuming which of those three it is without checking status_code first.
• Container status_code: ERROR — not a top-level API error code, but one of five terminal and non-terminal states (IN_PROGRESS, FINISHED, PUBLISHED, EXPIRED, ERROR) Meta documents for a container itself (returned from GET /{ig-container-id}?fields=status_code). Means processing failed after creation, distinct from a container that is merely slow — see the dedicated post below on telling the two apart.

• 4 — Application request limit reached. An app-wide throttle tied to your Meta app's overall call volume across all connected accounts, not any single user.
• 17 — User request limit reached. Scoped to a specific connected account rather than the whole app.
• 32 — Page request limit reached. The Facebook Page-scoped equivalent, relevant when your Instagram publishing flow is routed through a linked Page.
• 613 — Calls to this API have exceeded the rate limit. A custom throttling code Meta applies to specific endpoints independently of the general request-limit codes above.
• 9 (subcode 2207042) — "You reached the maximum number of posts that are allowed to be published by Content Publishing API." Distinct from generic rate limiting: Instagram caps API-published posts per account at 25 within a rolling 24-hour window (not a calendar day), separate from any manual posting the account owner does in the app. Check GET /{ig-user-id}/content_publishing_limit to read an account's current usage against that limit before assuming this is the cause.

• 368 — The action attempted has been deemed abusive or otherwise disallowed. A policy-enforcement code rather than a technical one; retrying the identical request will not help, and the fix is changing the content or, if you believe it was flagged incorrectly, appealing through Meta's standard channels.
• Content-moderation rejections during container creation or publish. These surface with varying codes and messages depending on what was flagged (copyright match, community standards, spam signals) — the common thread is that the request itself was well-formed and the rejection is about the content, not the API call.

Meta adds and adjusts subcodes over time, and this index covers what a publishing integration encounters most, not every code in the platform. When you hit something unfamiliar: check the top-level code first (it is the stable part), treat the message as a hint rather than ground truth, and check whether the failure is retryable — auth and permission errors need account or app action, rate-limit errors need backoff, content-policy errors need a content or appeal path, and container errors need a fresh container rather than a retry against the same one.