Facebook Graph API User IDs: A Beginner's Guide

The Facebook Graph API does not return one universal user ID. It returns an identifier scoped to the thing asking: an app-scoped user ID (ASID) for someone who logged into your app, a page-scoped user ID (PSID) for someone who messaged your Page, and a classic numeric UID visible in profile URLs. The same person legitimately has different IDs in each context, by design.

If you have been debugging why an ID from one integration does not match an ID from another, that is the answer, and it is not a bug. The rest of this guide explains the model so you can build against it.

Why doesn't one person have one ID?

Early in Facebook's platform history, apps received a single global user ID. Any two apps that both knew a user could compare IDs and confirm they were looking at the same person, which made it possible to correlate someone's activity across unrelated services without their knowledge.

Scoping removed that capability. Facebook now issues a different identifier to each app for the same user, so the ID your app receives is meaningless to any other app. It identifies the user to you, consistently and permanently, and tells a third party nothing.

Meta states this directly in the Graph API overview, describing the id field on a User node as "The app user's App-Scoped User ID. This ID is unique to the app and cannot be used by other apps."

The design consequence worth internalising: an ID is only meaningful together with the context that issued it. Store the scope alongside the value, because a bare number in a database column is ambiguous.

What are the main ID types?

App-scoped user IDs

An ASID is created the first time a given person authenticates to a given app through Facebook Login. It is stable: the same user returning to the same app gets the same ASID, which is what makes it usable as a primary key for your user records.

Two properties catch people out. First, an ASID exists only for users who have actually logged into your app, so there is no way to look up an ASID for someone who has not. Second, the same person on your other app has a different ASID, so two apps you own cannot match users by ID alone. Meta provides Business Mapping mechanisms for linking identities across apps that belong to the same verified business, which is the sanctioned route when you genuinely need it.

Page-scoped user IDs

A PSID is the Messenger equivalent, scoped to a Page rather than an app. When someone sends your Page a message, the webhook delivers a PSID, and that is the value you send messages back to. A person who messages two different Pages has two different PSIDs, even if the same app powers both.

The history here matters if you are reading older tutorials. Meta's v7.0 changelog records that the Pages API began returning PSIDs rather than ASIDs for all new apps from 1 May 2018, and that the endpoint for mapping ASIDs to PSIDs was deprecated in v7.0 and usable on older versions only until 5 May 2021. Both dates have passed, so any guide instructing you to call an ASID-to-PSID mapping endpoint is describing a path that no longer exists. Current identity-linking approaches run through Business Mapping and related features, and you should confirm the specifics in the live documentation rather than trusting a blog post.

The classic UID

The UID is the global numeric identifier for an account, the one that appears in facebook.com/profile.php?id= URLs. It is not what the Graph API hands your app for an authenticated user, and it is not something you can exchange for private profile data. It is a public reference, useful for pointing at a profile unambiguously. Our explainer on what a Facebook UID is covers it in full, and the comparison of IDs across profiles, Pages, and groups sets out how the types differ.

What does the API actually return, and when?

Every Graph API request carries an access token, and the token determines both who is asking and what they are permitted to see. The identity in the response follows from the token, not from the endpoint.

Calling /me resolves to the ID of the user or Page whose token you used, which is the standard way to establish identity after login. Calling /{user-id} with your app's user token returns the fields that user granted you, which for a basic login is typically little more than ID and name. Requesting anything beyond that, such as email or profile details, requires the corresponding permission, granted by the user and in most cases cleared through App Review before you can request it from the public.

The mental model that avoids most confusion: the API answers "what has this user allowed this app to see", not "what is true about this user". Your app does not get a view of a person's Facebook account. It gets a view of the slice they consented to share with you.

This is also why you cannot resolve an arbitrary profile URL to private data through the API. There is no endpoint that accepts a stranger's ID and returns their information, regardless of how public their profile looks in a browser. Public identifier resolution of the kind our Facebook UID Finder performs works on publicly served pages, not on privileged API access, and the same applies to the Instagram and X equivalents.

What are the permission and review realities?

Newcomers routinely underestimate this part, then discover it after building a feature that cannot ship.

Permissions beyond the basic set require App Review, where you submit a description, a screencast, and a justification, and Meta assesses whether your use case warrants the data. Reviews can be rejected, and a rejection means redesigning rather than resubmitting the same request. Several permission sets additionally require Business Verification, and some require a signed data-handling agreement or an independent security assessment, depending on the data involved.

Access tiers also matter: an app in development mode behaves differently from a live one, and features that work with your own account as a developer frequently stop working for real users until the corresponding permission is approved. Testing exclusively with your own admin account is a common way to be surprised late.

And availability moves. Meta has removed or restricted a long list of capabilities over the years, so an endpoint described in a tutorial from a few years ago may simply not exist now. Version your calls explicitly, read the changelog before committing to a design, and treat any undocumented endpoint as something that will break without notice.

Practical advice: confirm what you need is actually available, at your access level, before writing the feature. The documentation and changelog are the authority, and version-level behavioural claims from third-party sources, this article included, should never outweigh Meta's current reference.

Practical guidance for storing IDs

A few decisions save pain later. Store IDs as strings rather than integers, because they exceed 32-bit range and some exceed what JavaScript handles safely as a number, and because you never do arithmetic on them. Record the scope with the value, so you know whether a row holds an ASID, a PSID, or a public UID. Do not use an ASID as a cross-system global key, since it is valid only within your app. Expect to handle deauthorization: when a user removes your app, you should respond to the deauthorize callback and delete data accordingly, which is both a platform requirement and a sensible data-protection habit.

If you are working across platforms, each has its own scheme and none of them interoperate, as our articles on TikTok user ID vs sec_uid and finding a YouTube channel ID show.

Frequently asked questions

Why is the user ID from my app different from the one in the profile URL?

Because they are different identifiers. Your app receives an app-scoped user ID, unique to your app, while the profile URL shows the global UID. Both refer to the same person, and there is no general way to convert between them.

Can I convert an ASID to a PSID?

Not through the old mapping endpoint, which Meta deprecated in v7.0 with legacy use ending 5 May 2021. Current identity linking runs through Business Mapping and related features for apps under one verified business. Check the live documentation, since this area has changed repeatedly.

Do app-scoped IDs stay the same over time?

Yes, for the same user and the same app, which is what makes an ASID safe to use as a primary key. It does not change when the user edits their profile or name. It is meaningless to any other app.

Can I get someone's email from their user ID?

No. Email requires the user to grant the email permission to your app during login, and that permission is subject to App Review. An ID on its own grants nothing, and no endpoint turns an arbitrary ID into contact details.

What is the difference between a Page ID and a page-scoped user ID?

A Page ID identifies the Page itself and is global. A PSID identifies a person in their conversation with that Page and is scoped to it. One Page has one Page ID and as many PSIDs as it has people messaging it.

Does the Graph API let me look up any public profile?

No. There is no endpoint that takes a stranger's ID and returns their data without their authorization, however public the profile appears in a browser. Access follows the permissions a user granted your app.

Which API version should I build against?

Pin an explicit recent version rather than relying on a default, and watch the changelog for deprecations, since versions are supported for a limited window. Unversioned calls can shift behaviour under you when the default advances.

If you are starting out and mainly need to resolve public identifiers rather than build an app, the tools at 2uid.net cover Facebook, Instagram, TikTok, and YouTube without any API setup.