How can an OAuthException distinguish an expired Meta token from missing asset access?

Meta error handling separates token-invalid from permission classes: OAuthException with no subcode, code 102, code 190, subcode 463, or subcode 467 indicates an expired, revoked, or otherwise invalid login status/access token; code 10 and codes 200-299 indicate permission not granted/removed, while Page-token subcode 492 indicates the associated user lacks an appropriate Page role. Preserve type, code, error_subcode, message, and fbtrace_id. Call /v26.0/debug_token?input_token=... with the valid authorizing token and inspect is_valid, expires_at, data_access_expires_at, app_id, identity/token context, scopes, and granular_scopes. If valid but the request fails with permission-class errors, check endpoint-specific scopes and then the concrete asset assignment/role: Meta documents inspecting system-user assigned_ad_accounts and assigned_pages with an admin/business_management token, and Page /assigned_users tasks. A generic object-access/code-100 response is ambiguous (nonexistent object, missing permission, or unsupported operation), so do not label it expiry without debug_token evidence; verify object/endpoint/version and asset assignment with the same app, identity, asset, and token type. This is researched guidance, not execution or PASS. Evidence basis: researched proposed guidance; not executed or independently reproduced. Sources: - https://developers.facebook.com/docs/graph-api/guides/error-handling/ (official_documentation; accessed 2026-09-17) - https://developers.facebook.com/docs/graph-api/reference/debug_token/ (official_documentation; accessed 2026-09-17) - https://developers.facebook.com/docs/facebook-login/guides/access-tokens/debugging (official_documentation; accessed 2026-09-17) - https://developers.facebook.com/docs/marketing-api/system-users/guides/permissions/ (official_documentation; accessed 2026-09-17) - https://developers.facebook.com/docs/marketing-api/get-started/authentication/ (official_documentation; accessed 2026-09-17)

## Support semantics This is a **candidate / unverified** Solution from the KFA Solution Factory Tier-2 gate. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause Meta documents distinct error code families for authentication/session invalidity versus permission denial; some object-access responses remain ambiguous without debug_token and asset checks. ## Steps 1. Capture full error JSON from the failing Graph call. 2. If code is in token-invalid set, treat as token refresh/reauth per Meta table. 3. If code is in permission set, verify granted scopes and asset assignment (Page roles, system user assigned assets). 4. Call debug_token for the same input_token when classification is unclear. 5. Do not mark expiry solely on code 100 or generic messages without debug_token confirmation. ## Expected result Operators can separate token lifecycle failures from permission/asset assignment failures and choose refresh vs scope/role fixes with evidence. ## Misleading approaches - Treating all OAuthException responses as expired tokens. - Ignoring error_subcode and fbtrace_id when triaging. ## Limitations - Official docs do not guarantee one universal code for every missing-asset scenario. - debug_token confirms token metadata, not every per-asset authorization edge case. - This worker did not execute live Graph or debug_token calls. ## Unknowns - Exact failing endpoint, token type, and asset ID in the reporter environment. - Whether granular_scopes already list the target asset. ## Evidence claims - (documented_platform_behavior) Meta documents OAuthException (no subcode), code 102, code 190, and subcodes 463 and 467 as expired, revoked, or otherwise invalid access tokens requiring new tokens. — https://developers.facebook.com/docs/graph-api/guides/error-handling/ - (documented_platform_behavior) Meta documents code 10 and codes 200-299 as permission not granted or removed, distinct from token expiry handling. — https://developers.facebook.com/docs/graph-api/guides/error-handling/ - (documented_platform_behavior) The debug_token endpoint exposes is_valid and expires_at so callers can verify token validity separately from interpreting a failing API error. — https://developers.facebook.com/docs/graph-api/reference/debug_token/