# Meta's API errors, translated into what they actually mean

> Markdown version of https://postlake.dev/blog/meta-api-errors-translated . The canonical page for humans.
> PostLake is the social media API for AI agents: https://postlake.dev/llms.txt

18 August 2026 · 5 min read

Meta's errors are usually accurate and almost never actionable. Here is the translation table, built from real failures rather than from the docs.

Every error below is one we hit for real. The pattern is consistent: Meta tells you a true thing that does not help, and often lists several unrelated causes in one sentence so you cannot tell which applies.

## "Object with ID … does not exist, cannot be loaded due to missing permissions, or does not support this operation"

**Usually means:** your token lacks the permission for that specific edge.

The object almost always exists. If you published to it five minutes ago, it exists. Read this as a permission problem first, and check whether the connection was made before you added that scope. A token does not gain permissions retroactively when you add them to the app: the person has to reconnect.

## "Invalid Scope: some_permission"

**Means:** that scope is not enabled on your app, even if the name is real and documented.

Two different causes look identical here. Either the name is not a login permission at all (Human Agent and Business Asset User Profile Access are app _features_, not scopes, and asking for them at login fails), or it is a real permission your app has not been granted. Meta refuses the **entire** authorisation either way, so one wrong entry breaks every connection rather than just its own capability.

## "The account owner has disabled access to Instagram Direct messages"

**Means:** a switch inside the Instagram app, not a permission.

Settings, then Messages and story replies, then Connected tools, then Allow access to messages. Only the account owner can change it, and App Review will not help. This one reads exactly like a scope problem and is not.

## "To access this endpoint, your brand needs to verify its business"

**Often means:** the business is verified and you have not completed onboarding.

Verification is step one of a longer flow. We saw this message against a business that was verified, and the real gap was creator marketplace onboarding, which is a separate click-through in Business Suite. Once the business was verified, the message changed to name onboarding directly, which is how we knew.

Worth knowing: it is the business owning the **asset** that must be verified, not the one owning the app. Those are often different, and nothing tells you which one Meta means.

## "For field 'authorized_adaccounts': The parameter business is required"

**Means:** resolve the business first.

Nobody has that id to hand. Read it from the Page with `fields=business`, then pass it. A Page with no Business Manager behind it has no ad accounts to report, which is a real state rather than an error.

## "Tried accessing nonexisting field (x)"

**Means:** you are on the wrong host, or asking one API for another API's field.

The Instagram and Facebook hosts do not expose the same edges. Asking `graph.instagram.com` for a catalogue field answers this, and if your code treats it as "no results" you will report an empty catalogue to someone who has products. Ask for one field that does not exist and the **whole** call fails, not just that column.

## "This message is sent outside of allowed window"

**Means:** more than 24 hours have passed since their last message.

Not a permission problem and not fixable by reconnecting. A reply a person wrote can use the Human Agent tag for 7 days instead, but only when a human genuinely wrote it. That tag exists precisely to stop automation claiming to be a person, and the penalty lands on the connected account.

## The rule underneath all of these

Meta's errors describe symptoms. Your users need causes. The gap between the two is where most of the support burden of a Meta integration lives, and closing it is cheap: keep the raw message, add the one action that fixes it, and never let a failure be reported as an empty result.

That last part matters more than it sounds. If a failed call returns an empty list, then "we could not look" and "there is nothing there" become the same answer, and every debugging session after that starts from a lie.

---

PostLake publishes, schedules and reads across every major social network from one API. https://postlake.dev