[WORKAROUND] Bypass Code 100 / Subcode 33 Outage for Container Polling, Analytics, & Permalinks

Hey everyone,

If you are still struggling with the global infrastructure issue that started around May 23—where valid Page Access Tokens throw a 400 GraphMethodException (code 100, subcode 33: Authorization Error) or Error #10 when polling containers, fetching insights, or pulling permalinks—we found a structural workaround that completely unblocks all three pipelines.

🔍 The Root Cause

Meta's internal permissions router is experiencing a replication failure when checking individual object endpoints (like /{container-id}, /{media-id}/insights, or /{media-id}) against a Page Token. It completely forgets the handshake and rejects the token.

💡 Your Two Options to Fix This

Depending on how your app stores tokens, you have two clear paths to unblock your platform right now:

Option A: Switch to the ?ids= Array Layer (Best if you only have Page Tokens)

We discovered that if you route your requests through the root object directory using the ?ids= array syntax, Meta’s API bypasses the broken individual item permissions check. This allows the Page Access Token to work perfectly without requiring you to switch tokens or force client re-authentication.

1️⃣ Fix for Initial Media Container Polling: Instead of hitting the individual container endpoint directly, pass the container ID into the ?ids= query parameter. * ❌ Old Way (Failing with 400): GET /v25.0/{container-id}?fields=status_code,status * ✅ New Way (Succeeds with Page Token): GET /v25.0/?ids={container-id}&fields=status_code,status

2️⃣ Fix for Post Analytics / Insights: Bind your metric parameters locally to the insights edge inside the fields string using the nested dot syntax .metric(). * ❌ Old Way (Failing with 400): GET /v25.0/{media-id}/insights?metric=reach,saved,shares * ✅ New Way (Succeeds with Page Token): GET /v25.0/?ids={media-id}&fields=insights.metric(reach,saved,shares,total_interactions)

3️⃣ Fix for Fetching Post Permalinks: If you try to query ?fields=permalink on a single Media ID using a Page Token, it will fail with an authorization block. You must wrap it in the directory layer too. * ❌ Old Way (Failing with 400/Error 10): GET /v25.0/{media-id}?fields=permalink * ✅ New Way (Succeeds with Page Token): GET /v25.0/?ids={media-id}&fields=permalink

Option B: Use the Long-Lived User Access Token (Old Structure Works!)

If your system stores the long-lived User Access Token (the root OAuth token from your initial login flow, not the page-specific token from /me/accounts), you don't need to rewrite your query structure.

The individual endpoints are still completely functional if you simply swap the token being used: * ✅ Polling: GET /v25.0/{container-id}?fields=status_code,status (Using User Token) * ✅ Analytics: GET /v25.0/{media-id}/insights?metric=reach,saved,shares (Using User Token) * ✅ Permalinks: GET /v25.0/{media-id}?fields=permalink (Using User Token)

Because the long-lived User Token sits higher up in Meta's internal database hierarchy, it bypasses the broken Page-to-Asset verification block entirely across all endpoints.

🚀 Bonus Architecture Win for Option A

By adopting the ?ids= structure for your analytics engine, you can pass a comma-separated array of up to 50 Media IDs in a single HTTP request (?ids=ID1,ID2,ID3...). This reduces your platform's network overhead and round-trip times by up to 98% compared to looping individual calls.

This has completely restored our publishing pipeline, analytics engine, and link-fetching workflows back to normal operation while we wait for Meta to roll out an official patch. Drop a comment below if this successfully unblocks your production apps!

the api is OK this morning, location east Asia

just to join the dots : https://developers.facebook.com/support/bugs/2158425928311016/ and https://developers.facebook.com/community/threads/985905100510985/ are related

Confirmed it is now finally working again for me.

Additional information:

The issue appears to have been isolated to May 25, 2026. The same integration, page, and publishing workflow were functioning correctly before and after that date.

We verified the following:

• The Page ID is correct.
• The Page is returned by /me/accounts.
• We are using a valid Page Access Token.
• The token includes all required permissions, including pages_manage_posts, pages_manage_engagement, pages_read_engagement, and pages_show_list.
• The image URL supplied to the /photos endpoint is publicly accessible.
• Other Graph API operations continued to work as expected.

The response received was:

{
  "error": {
    "message": "Authorization Error",
    "type": "GraphMethodException",
    "code": 100,
    "error_subcode": 33
  }
}

Since the issue occurred only during a specific time window and has not been reproducible since, we are interested in understanding whether there were any known platform-side authorization issues, page-state synchronization issues, or other conditions that could result in error subcode 33. while the page remains accessible through other Graph API endpoints.

Any insights would be greatly appreciated.

Same issue - All IG posts failing since Saturday and still happening.

Yep, we are still seeing this issue after almost 3 days now, almost all posts failing.

I have the same error, the API response was the following: {"message":"Authorization Error","code":100,"type":"GraphMethodException","error_subcode":33,"fbtrace_id":""}

I tried to reconnect the IG account, revoke my token and generate a new one, and other ways to fix it, but nothing worked. If someone find a solution, please help us.

Same here, all carousels are failing since saturday a 7:30am { "error" : { "message" : "Authorization Error", "code" : 100, "fbtrace_id" : "A9vC8I2KxxsXSl4TqQ3pDUv", "error_subcode" : 33, "type" : "GraphMethodException" } }

The problem remains

We have the same issue :(

The failure persists. Is anyone at Meta looking into this???

The same problem has persisted for 3 days! This situation is unacceptable. We have hundreds of customers who can't publish, and they obviously blame us.

Same problem here

Same issue here!

Hi everyone,

Adding our findings here in case it helps other developers affected by the Instagram publishing issue that started around May 23, 2026.

We are seeing a similar failure pattern in our production app. Media containers are being created successfully, but the status polling step intermittently fails with:

GraphMethodException code: 100 error_subcode: 33

What we observed

Our publishing flow looks like this:

1. POST /{ig-user-id}/media succeeds and returns a container ID.
2. GET /{container-id}?fields=status_code,status sometimes returns a 400 response with code: 100 and subcode: 33.
3. In some cases, checking the same container status using the user access token associated with the original OAuth connection returns FINISHED.

Based on this, the media container itself does not appear to be failing in all cases. The failure seems to happen during the status polling step.

Temporary handling that helped us

To reduce failed publishes while this issue is ongoing, we made the status polling step more defensive:

1. We added an initial delay of around 15 to 30 seconds before the first status check.
2. We now treat code: 100 / subcode: 33 during container polling as a potentially transient error and retry instead of immediately marking the post as failed.
3. Where our app already has a valid user access token from the original OAuth flow, we use that token for the status check. If it is unavailable, we fall back to our existing token flow and continue retry handling.
4. After publishing, permalink retrieval is now treated as best-effort. If the post has already been published but GET /{mediaId}?fields=permalink fails or returns no permalink immediately, we log it and retry later rather than failing the entire publish job.

This has helped stabilise our publishing flow, but it still appears to be related to the current Graph API behaviour rather than a change in our app.

Adding this in case it helps others compare notes. It would be very helpful to get an official update from Meta on whether this is a known issue and whether there is a recommended handling pattern while it is being resolved.

Thanks.

We have found a fix for now. Don't use the page token to check the status. Use the user's long-lived token. Same for getting the permalink

We were able to restore publishing on our side with a workaround.

The issue was not container creation itself. POST /{ig_user_id}/media continued to succeed and returned a valid creation_id. The failure happened on the next step: GET /{creation_id}?fields=status_code,status returned Authorization Error (code 100, subcode 33) for newly created containers.

Our workaround was to stop querying the container directly via /{creation_id} and instead use:

GET /?ids={creation_id}&fields=status_code,status

That returned the expected nested object. Once status_code=FINISHED, we could continue with the normal publish step:

POST /{ig_user_id}/media_publish

using the same creation_id, and publishing started working again.

So in short: POST /media worked direct GET /{creation_id} was broken GET /?ids={creation_id} worked as a workaround POST /media_publish worked again after switching the status lookup

One more point:

Buffer stated on May 26, 2026 that they had deployed a temporary fix and restored publishing success rates, but they chose not to document the technical workaround publicly. That is disappointing. In an incident affecting many developers and customers, sharing at least the general mitigation path would have helped the broader ecosystem recover faster instead of forcing everyone else to rediscover the same workaround independently.

Their public update remained vague despite clearly having found a viable mitigation: https://status.buffer.com/incidents/01KS9XCSVD40PTC7QKDP8JBTV8

We’d be delighted if someone from Buffer saw this and followed up with a suitable solution.

Also im looking forward to the response of the META Team here: https://developers.facebook.com/support/bugs/2158425928311016/

Same problem here as well

same

Same here. Facebook works, but Instagram displays an "Authorization Error".

getting same issue

Hi everyone,

Confirming the same issue on our end. Since May 23, 2026, Instagram publishing has been intermittently failing across all connected accounts in our production app, with zero changes on our side.

We are observing two distinct failure patterns:

1. Authorization Error (intermittent) The publishing flow sometimes fails mid-way with an Authorization Error (code: 100, type: GraphMethodException, error_subcode: 33). This is not consistent, it doesn't happen on every request, but when it does, it completely blocks the post from being published. Since all accounts are affected simultaneously and no tokens were changed, this does not appear to be a token or permission issue on our end.

2. Permalink fetch fails after successful publish In cases where the Authorization Error does NOT occur and the media publish call goes through successfully, a subsequent GET /{mediaId}?fields=permalink call either fails or returns no permalink for the newly published media. This means even when publishing appears to succeed, we are unable to retrieve the post's permalink via the Graph API.

This two phase failure pattern is particularly concerning, even when the first step succeeds, the media resource does not appear to be fully accessible immediately after publishing.

Adding my voice here as another affected developer. The intermittent nature of this makes it especially hard to handle gracefully on the app side. Would really appreciate an official acknowledgment from Meta and an ETA on a fix.

Thanks

Yes, same happening to me.

Confirming we are also experiencing the exact same issue. Have not found a fix or work around at this stage.

I am having the same error in my application.

Same issue here! We've noticed—if that helps—that the URL graph.facebook.com/v24.0/{container_id}?fields=status_code,status works with a “User” token, but not with a “Page” token.

Same issue, just started yesterday. Still happening today. I have removed the app, re-added, re-authorized all pages and insta profile, etc. Facebook posts no problem, insta photo post "Authorization Error" - but hey, Graph API system status is all good lmao. Meta, get your shit together.

Additional Test: Container creation returns container ID successfully:

Request: POST https://graph.facebook.com/v25.0/{{ig_user_id}}/media

Response (200 OK): { "id": "179798.......0686" }

When i then want to check the container status:

Request: GET https://graph.facebook.com/v25.0/179798.......0686?fields=status_code,status

Response: { "error": { "message": "Authorization Error", "code": 100, "type": "GraphMethodException", "error_subcode": 33, "fbtrace_id": "Aqzz_8LP5YgTnZsiiXX11nO" } }

For me, this is a strong indicator that the problem is not limited to Reels or video uploads. In our case, even image post containers can be created successfully, but the returned container resource becomes inaccessible immediately afterwards when querying its status.

We also checked one affected backend log from production. It shows the same behavior server-side: Instagram publishing reaches the container status check, and the failure occurs exactly when requesting the status of the newly created container via GET /{creation_id}?fields=status_code,status. In other words, container creation appears to succeed, but the container cannot be read immediately afterwards.

Cheers, Andre

Same issue here! Most posts aren't publishing due to this issue.