Instagram Graph API code 100, subcode 33: bad request body
What Instagram Graph API error code 100 with subcode 33 means, and the most common malformed-request causes.
By André LugInstagram Graph API code 100 with subcode 33 means the object ID you referenced does not exist, cannot be loaded with your current permissions, or does not support the operation — not necessarily a malformed request body. It most often appears on GET requests reading a freshly created container or media object, where a short delay and a bounded retry usually resolves it.
Code 100 is the Instagram Graph API's general-purpose GraphMethodException — a wide bucket, not a specific diagnosis on its own. Subcode 33 narrows it, but its exact wording points somewhere more specific than "bad request body" suggests, and it is worth reading precisely before you start rewriting request payloads that were never the problem.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What does subcode 33 literally say?
The canonical message attached to code 100, subcode 33 is: "Unsupported get request. Object with ID '…' does not exist, cannot be loaded due to missing permissions, or does not support this operation." That wording covers three distinct root causes at once, and Meta's own Instagram Platform error-codes reference does not list subcode 33 among the subcodes it documents under code 100 — it is a general Graph API subcode that predates the Instagram-specific reference and applies across Meta's broader platform, not something Instagram's own docs define separately.
In a publishing integration, this subcode most often surfaces on a GET request — reading back a container's status_code, fetching a published media object's permalink, or looking up a comment you just created — rather than on the POST that actually creates something. That is the opposite of what "bad request body" implies: the request body that failed is frequently not the one that triggered the original operation, but the follow-up read.
What can it actually mean?
- The object genuinely does not exist. You are reading back an ID that was deleted, never created, or belongs to a different node type than you assumed — for example, passing a container ID to an endpoint expecting a published media ID after the container already converted.
- Missing permissions on that specific object. Your token is valid and generally works, but the connected account's role, or the app's current App Review status, does not cover reading that particular field or node — distinct from an invalid token (that is code
190, not this). - A known timing issue on freshly created objects. Developers have repeatedly reported
GETrequests against a container or media object failing with this exact code/subcode combination within moments of creation, even though the precedingPOSTsucceeded and the object is confirmed to exist — the write lands before the object is consistently readable across Meta's infrastructure.
That third case is the one worth being honest about: it is a widely reported pattern in developer communities and public integration issue trackers, not something Meta's documentation formally acknowledges as a known behavior. Treat it as a credible, common explanation rather than a confirmed platform guarantee.
When is it really your request body?
Despite the timing-issue pattern above being common, a genuinely malformed request body can also produce this subcode, most often by referencing the wrong ID inside the body rather than sending invalid JSON:
- Passing a user-scoped ID where the endpoint expects an IG Business Account ID, or vice versa — the request is syntactically valid but points at a node the operation does not support.
- Referencing a container ID after it already transitioned to
PUBLISHEDorEXPIRED— the ID is real, but it no longer supports the operation you are attempting against it. See Instagram media container stuck in QUEUE for the full container lifecycle. - Building the request body from a stale cached ID your own system retained past the point where Instagram considers it valid for that operation.
How do you tell these apart?
Work through this order rather than guessing:
- Re-fetch the same ID a few seconds later, unchanged. If it now succeeds, you hit the freshly-created read-timing pattern — add a short delay or a bounded retry before your first read of a just-created object, rather than treating it as a hard failure.
- Check the ID's type and current state against what the endpoint expects — a container ID sent to a media-object endpoint, or an ID for an object that already moved past a publishable state, is a request-body problem, not a timing one.
- Confirm the token's granted permissions actually cover the specific field or node you are reading, not just that the token is generally valid — a valid token can still lack access to one particular object.
How does PostGate handle this?
PostGate's internal container polling already accounts for the freshly-created-object read pattern, so a transient subcode-33 response on a container PostGate just created does not surface to you as a hard failure — see Delivery lifecycle for how target status transitions handle this internally. A genuinely bad ID reference in a request you send PostGate still comes back as a specific, structured error in the error envelope rather than a raw pass-through of Meta's message.
Frequently asked questions
Why does a GET on a just-created Instagram container return code 100 subcode 33?
Developers have repeatedly reported GET requests against a container or media object failing with this exact code/subcode combination within moments of creation, even though the POST succeeded and the object exists — the write lands before the object is consistently readable across Meta's infrastructure. It is a widely reported community pattern, not behavior Meta formally documents. Add a short delay or bounded retry before the first read.
Is subcode 33 documented in Meta's Instagram error-codes reference?
No. Meta's Instagram Platform error-codes reference does not list subcode 33 among the subcodes it documents under code 100. It is a general Graph API subcode that predates the Instagram-specific reference and applies across Meta's broader platform, with the canonical message: "Unsupported get request. Object with ID does not exist, cannot be loaded due to missing permissions, or does not support this operation."
How do I tell if code 100 subcode 33 is a permissions problem or a bad ID?
Re-fetch the same ID unchanged a few seconds later — if it succeeds, it was the freshly-created read-timing pattern. If not, check the ID's type and state against what the endpoint expects (a container ID sent to a media-object endpoint is a request-body problem), then confirm the token's granted permissions cover the specific field or node. An invalid token is code 190, not this.
Can an expired or already-published container ID trigger this error?
Yes. Referencing a container ID after it has transitioned to PUBLISHED or EXPIRED produces this subcode — the ID is real, but it no longer supports the operation you are attempting against it. The same happens when your system builds a request from a stale cached ID retained past the point where Instagram considers it valid for that operation.
