Unsupported Post Request: Object With ID Does Not Exist

Why does Meta refuse to say whether the object exists?

The message arrives exactly like this, with your own id dropped into the middle of it:

Unsupported post request. Object with ID '<ID>' does not exist, cannot be
loaded due to missing permissions, or does not support this operation.

Read literally, that sentence offers three unrelated diagnoses at once: the id is wrong, or the id is right but your token cannot see it, or the id is right and visible but the operation you tried is not allowed on that kind of object. Nothing in the response says which. One generic exception carries all three meanings for every object type Graph handles — pages, ad accounts, business assets, and WhatsApp Business Accounts and phone numbers among them — which is why the exact same wording turns up in no-code automation platform logs, mobile SDK issue trackers, and WhatsApp Cloud API server logs alike.

Whether Meta declines to distinguish these cases on purpose — so a caller probing ids at random cannot tell a merely-forbidden object from one that never existed — or whether it is simply what one shared exception class looks like across thousands of endpoints, is not stated anywhere in Meta's documentation. What is checkable is that the message's three clauses map onto four real causes once you include the Business Manager layer behind the OAuth scope: an invalid or expired token, a scope never granted, an object never assigned to your app as an asset, and an object that genuinely does not exist. All four produce the identical sentence above.

That convergence is the whole reason this message resists searching. A numeric error code invites you to look it up; this one describes a symptom common to four different illnesses, so the fix is a fixed order of checks rather than a lookup table. The rest of this piece works through that order.

• Why does Meta refuse to say whether the object exists?
• What is the difference between the two error 33s?
• How do you find out what your token can actually see?
• Which scopes does each WhatsApp endpoint need?
• What does it mean when an id worked yesterday and fails today?
• Why is a client-supplied id the wrong thing to trust?
• Where do you read the authoritative account ids from?
• How do asset assignment and permission grants differ?
• What does error 10 tell you that this message does not?
• What is the fastest order to check these in?

What is the difference between the two error 33s?

Confusingly, Meta's own error taxonomy has two completely separate error 33s, and they point in opposite directions.

The first is a plain, top-level code on the WhatsApp Cloud API's own error code reference:

"The business phone number has been deleted." (Meta - WhatsApp Cloud API error codes)

with the remedy given as "Verify that the business phone number is correct." That is an unambiguous, specific diagnosis: the phone number resource itself was removed.

The second is not a top-level code at all — it is error_subcode: 33 nested underneath the generic code: 100, and it is exactly the message this article opened with. Developers have reported the combination for years across very different Graph surfaces, always with the same shape. One long-running Facebook SDK issue records it verbatim:

"HttpStatus: 400, errorCode: 100, subErrorCode: 33, errorType: GraphMethodException, errorMessage: Unsupported get request. Object with ID '<MY_APP_ID>' does not exist, cannot be loaded due to missing permissions, or does not support this operation." (facebook-android-sdk issue #900)

and a no-code automation platform's support forum shows the identical text arriving from a live API call against a Facebook object id, request verb and all:

"[400] [100] Unsupported post request. Object with ID '[Collection]' does not exist, cannot be loaded due to missing permissions, or does not support this operation." (Make community forum)

So the same numeral, 33, means "the phone number is confirmed deleted" in one place and "could be permissions, could be nonexistent, could be unsupported" in the other. If you are pattern-matching on the digits alone rather than reading whether 33 arrived as a bare code or as an error_subcode under code: 100, you will draw the wrong conclusion from a genuinely correct-looking error.

There is a further wrinkle worth knowing before you build any error-handling logic around subcode 33: the WhatsApp Cloud API's own error reference documents error_subcode as:

"Deprecated. Will not be returned in v16.0+ responses." with the added guidance: "Graph API subcode. Not all responses will include a subcode, so build your error handling logic around code and details properties instead." (Meta - WhatsApp Cloud API error codes)

Community reports of error_subcode: 33 nonetheless exist in developer forum threads, which only reinforces the point: do not build logic around catching this specific subcode. Treat code 100 with no distinguishing detail as the ambiguous case it is.

Checked against Meta's documentation on 4 September 2026.

How do you find out what your token can actually see?

Graph API exposes a purpose-built endpoint for exactly this question: debug_token. Calling it against the token you actually use returns:

"metadata about a given access token" including "what permissions the app has for the given user" (Meta - Debug Token, Graph API Reference)

Four fields matter most for this problem. is_valid is described as "Whether the access token is still valid or not." expires_at is "Timestamp when this access token expires." data_access_expires_at is "Timestamp when app's access to user data expires." scopes is "List of permissions that the user has granted for the app in this access token." (Meta - Debug Token, Graph API Reference)

The field that actually answers "can this token see this specific object" is granular_scopes, defined as:

"List of granular permissions that the user has granted for the app in this access token. If permission applies to all, targets will not be shown." (Meta - Debug Token, Graph API Reference)

Each entry carries a scope name and a target_ids array of the specific object ids — WABAs among them — that scope was actually granted against. Meta's own web tool for this, the access token debugger, is what error code 10's own remedy points to, and calling debug_token from code returns the same data programmatically, which is what a server needs to check automatically rather than pasting a token into a browser every time.

The practical rule: before touching the object that is throwing this error, call debug_token on the literal access token your server is sending, read is_valid and expires_at first, then look for the endpoint's required scope inside granular_scopes, then check whether the id you are calling actually appears in that scope's target_ids. Three separate questions, three separate failure points, and the ambiguous error message answers none of them for you.

Which scopes does each WhatsApp endpoint need?

WhatsApp Business Platform access splits across two scopes with distinct jobs, and mixing them up is a common cause of this exact error. Meta's own permissions reference states:

whatsapp_business_management is "needed to access metadata on your WhatsApp Business account, template management, getting business phone numbers associated with your WABA, all analytics, and to receive webhooks notifying you of changes to your WhatsApp Business account." (Meta - WhatsApp permission scopes)

while

whatsapp_business_messaging is "needed to send any type of message to WhatsApp users, and to receive incoming message and message status webhooks." (Meta - WhatsApp permission scopes)

The WhatsApp Business Management API's own getting-started guide is specific about the combination a token needs: "Add the following permissions to the token: business_management, whatsapp_business_messaging, whatsapp_business_management." A token missing whatsapp_business_management will fail to read templates, phone number metadata or WABA-level webhooks configuration with this exact ambiguous error, even while happily sending messages under whatsapp_business_messaging — because the two scopes are checked independently, per call.

A provider managing many customers' numbers at once — the shape this site covers in our comparison of the BSP and Tech Provider tiers — hits this constantly, because every customer's WABA needs its own separate scope grant and its own separate asset assignment; there is no single "manage everything" grant that covers a whole portfolio of unrelated businesses.

What does it mean when an id worked yesterday and fails today?

An id that worked yesterday and throws this error today, with no code change on your side, almost always traces back to one of the debug_token fields changing state rather than the object moving. is_valid can flip to false, expires_at or data_access_expires_at can simply pass, all without any signal reaching your app proactively — Graph does not push you a warning before a token dies, it just starts answering every call about that token's objects with the same undifferentiated message.

The other common cause has nothing to do with the token's validity: the object can still be assigned to your app one day and un-assigned the next, because asset assignment lives in Business Manager and is something the other business controls, not you. A WABA moved between business portfolios, an app removed from a shared asset, or the account itself being restricted all look identical from your side: yesterday's call succeeds, today's returns "does not exist." None of that shows up as a change in your own configuration, which is why the debugging order later in this piece checks the token before it ever touches the object.

If you are migrating a number between providers rather than debugging an existing one, our guide to switching WhatsApp API providers covers the token and permission handoff that migration itself requires — a related but distinct problem from a token silently expiring underneath a stable integration.

Why is a client-supplied id the wrong thing to trust?

A browser-side signup flow, an OAuth popup, or a webhook payload can hand your server a WABA id, a phone number id, or an app id as part of its response. It is tempting to store that id and call the API with it directly. The trouble is that a client-supplied id is only a claim about what the flow believes happened — it is not proof that your server-side token was actually granted access to that specific object, and the two can diverge for reasons entirely outside your control: the flow can report an id for an account whose asset assignment silently failed on Meta's side, or a session can complete against one business while your app's actual grant lands against another.

Calling the API with a client-reported id you have not independently verified is how this error message ends up surfacing days or weeks after the id was first captured, rather than immediately — the id sat unused until something tried to read or send against it, and only then did the mismatch between "what the client said happened" and "what the token can actually see" become visible. This article is about the case where the API call itself refuses outright, rather than a connection that looks fine on screen but silently fails to deliver — that second failure mode has its own set of causes and its own checklist.

Where do you read the authoritative account ids from?

The only place to get an id your token is guaranteed to actually have a grant for is the token's own debug_token response, not the client. Inside granular_scopes, find the entry whose scope reads whatsapp_business_management, and read its target_ids array — Meta's own guidance on this is specific about which entry to trust when more than one is present:

"IDs for the most recently onboarded WABAs appear first, so capture the first ID in the target_ids array for the whatsapp_business_management scope." (Meta - Managing WhatsApp Business Accounts)

For a broader inventory than one token's scopes can show — every WABA a whole business portfolio has shared with your app, not just the ones the current token happens to carry — the same page points to a dedicated endpoint:

the Client WhatsApp Business Accounts API is used "to retrieve a list of all the WABAs assigned to or shared with your business portfolio after the business completes the Embedded Signup flow." (Meta - Managing WhatsApp Business Accounts)

An operator managing many tenants' numbers needs exactly this distinction: which ids a signup flow reported versus which ids the platform's own tokens can actually reach.

Reading the authoritative id first and treating anything a signup dialog or webhook reported as a hint rather than a fact is the difference between resolving this error in one debug_token call and chasing a phantom typo for an afternoon.

How do asset assignment and permission grants differ?

It is easy to assume that once a scope shows up correctly in granular_scopes, the object is reachable. It is not — Graph API access to a WhatsApp Business Account is gated by two independent mechanisms, and this error commonly comes from having one without the other.

The first is the OAuth scope grant: a business or user consenting, through a login dialog, that your app may use a named permission like whatsapp_business_management on their behalf. The second is Business Manager asset assignment, a completely separate step performed inside Business Manager itself, where a specific asset — a WABA — is explicitly attached to a specific system user or app. Meta's own walkthrough for setting this up describes it as a distinct action from granting a scope:

"Select the new system user you created, and click Assign Assets." Then, "Select your WhatsApp account and toggle Manage WhatsApp Business accounts under Full control." (Meta - WhatsApp Business Management API, Get Started)

A token can carry a perfectly valid whatsapp_business_management scope and still fail against a particular WABA if that WABA was never assigned to the system user or app the token belongs to — the scope says "this app is allowed to use this kind of permission," the assignment says "this app may use it against this specific object." Both have to be true at once. This is the third gate in the diagram earlier in this piece, and it is the one a scope check alone will not catch: granular_scopes can look correct while the id you need is absent from target_ids, because the assignment, not the scope, is what is missing. The paperwork behind that assignment — the documents Meta asks for during business verification — is a separate, earlier gate again, and one this error message says nothing about either.

What does error 10 tell you that this message does not?

By contrast, when Graph can actually name the problem, it does — which makes error 10 a useful comparison for how much less this message tells you. Meta's WhatsApp Cloud API error code reference gives code 10 as:

"Permission is either not granted or has been removed." (Meta - WhatsApp Cloud API error codes)

with a remedy stated directly: "Use the access token debugger to verify that your app has been granted the permissions required by the endpoint." (Meta - WhatsApp Cloud API error codes) That is a single, specific diagnosis with a named tool to confirm it — nothing like the three-way hedge in "does not exist, cannot be loaded due to missing permissions, or does not support this operation."

The comparison matters because it tells you Graph is capable of being specific when the failure is cleanly a permission problem at the scope level. When it instead returns the vaguer, three-clause message, that is itself informative: it usually means the failure sits one layer deeper than a simple missing scope — most often the asset assignment gap described above, or a token whose validity has actually lapsed — rather than a case Graph could have named and chose not to.

What is the fastest order to check these in?

Given that the message itself will not tell you which of four gates failed, checking them in a fixed order is faster than guessing from the wording:

1. Call debug_token on the exact token your server sends — not one from Graph Explorer, not one you assume is equivalent — and read is_valid, expires_at and data_access_expires_at first. A token that has expired or been invalidated explains everything downstream and needs no further investigation.
2. Check granular_scopes for the scope the endpoint actually requires, using the table earlier in this piece to confirm you need whatsapp_business_management versus whatsapp_business_messaging for this specific call.
3. Check whether the object id you are calling with actually appears in that scope's target_ids. A present scope with an absent id means the object was never assigned to this app or system user in Business Manager, regardless of what any OAuth screen showed the customer.
4. Only once all three pass, treat the object as genuinely gone — check the top-level error 33 conditions, confirm the phone number or WABA was not deleted, and verify you have not mistyped an id that was never valid to begin with.

Doing this in reverse order — starting from "maybe I typed the id wrong" — is the slow path, because a typo is the least likely of the four causes and the hardest to falsely rule in from the error text alone.

Every Meta quotation on this page was read from Meta's own documentation on 4 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.