Graph API Tester

Before you paste a live access token

The Graph API is versioned and changes on a regular schedule — endpoints, fields, permissions and error codes are all subject to change, and older versions are eventually retired. This page is an independent guide, not documentation. Check the official Facebook Graph API documentation for authoritative details.

Nodes, edges and fields

Graph is named after its data model and the model is worth internalising, because it explains the URL shapes. Everything is a node — a user, a page, a photo — identified by an id. Nodes are joined by edges, which are collections hanging off a node. Nodes have fields, which are their attributes. A URL is therefore usually a node id, optionally followed by an edge name.

The special id me resolves to whoever the access token represents, which makes /me the natural first request — it is prefilled above. Fields are where Graph differs most from a typical REST API: it does not return everything by default. You ask for what you want with a fields parameter, comma-separated, which is why fields=id,name is prefilled in the Params tab. If a field you expected is missing from a response, the first question is whether you asked for it; the second is whether your token has permission to see it.

Requests should normally include a version segment in the path, written as v followed by a version number — the current version changes several times a year, so this page deliberately does not name one that would be stale by the time you read it. Check the documentation for the current version and put it directly after the host, before the node id. Pinning a version explicitly is strongly preferable to omitting it, because an unversioned request's behaviour is not under your control.

Valid and invalid responses

A successful Graph request returns a plain JSON object with the fields you asked for. Calling /me with fields=id,name and a working user token gives you an object with an id and a name and nothing else — concise, and unambiguous confirmation that the token is alive and whose it is. Requests to an edge instead return a data array plus a paging object holding cursors for the next and previous pages.

Failures are wrapped in a single error object, and Graph puts real information in it. It carries a human-readable message, a type such as OAuthException, a numeric code, often an error_subcode that narrows things further, and a trace id. Unlike some providers, Graph also uses genuine HTTP error status codes rather than returning 200 with a failure inside, so the status pill above is meaningful here.

Read the message field first and take it literally. Meta's error messages are more specific than most — they will often name the missing permission or say plainly that the session has expired — and a great deal of time gets wasted theorising about errors that already explain themselves.

Code 190 and the token that stopped working

The error you will hit most is an OAuthException with code 190. This is Graph's general "something is wrong with your access token" error, and it covers several distinct situations that all look similar at first glance: the token is malformed, it has expired, the user revoked it, or it was invalidated by a security event such as a password change. The accompanying message and subcode tell you which.

In practice, expiry is the answer far more often than anything else, because tokens generated for testing are typically short-lived by design. A request that worked twenty minutes ago and fails now, with nothing else changed, is almost always an expired token rather than a mystery. Get a fresh one before you investigate further.

Permission errors are the other large family. A token can be perfectly valid and still be refused because the app was never granted the permission that a particular field or edge requires. The distinction matters: an invalid token is fixed by getting a new one, while a missing permission is fixed by changing what the app requests and having the user re-authorise it. Getting a new token without changing the permission set will not help.

Getting a token to test with

Graph tokens come from an app in Meta's developer platform. Create an app, then use the Graph API Explorer tool in the developer site to generate a token: it lets you pick the app, choose the type of token, select individual permissions, and hands you a token you can copy. It is the fastest route to a working credential and it shows you which permissions you actually granted, which is worth knowing before you start debugging refusals.

There are several kinds of token and they are not interchangeable. A user access token acts for a person and is what /me resolves against. A page access token acts for a page. An app access token identifies your application rather than any user. Using the wrong kind produces errors that read like permission problems, so confirm which type you are holding before assuming permissions are at fault. Graph also offers a token-debugging endpoint that reports a token's app, type, expiry and granted permissions — usually the quickest way to answer "what exactly is this token?".

Rate limiting and what 401, 403 and 429 mean here

Graph reports usage against its limits through response headers — look for an app-usage header in the response header panel, which reports how much of your allowance has been consumed. Meta applies several distinct throttles depending on the app, the user and the business use case, so this page quotes no numbers; read the headers you actually get back. Response header mechanics in general are covered in the HTTP headers reference.

A 401 Unauthorized or a 403 Forbidden from Graph points at the token or its permissions, and the error object will be more specific than the status code is — check the code and message before concluding anything from the status alone. A 429 Too Many Requests, or a Graph error indicating that a request limit was reached, means you should back off; Meta's throttles typically clear on their own after a cooling-off period, and continuing to hammer the endpoint extends it.

If you are working with Meta's login flows you may end up holding an ID token that genuinely is a JSON Web Token; the JWT decoder shows its claims and expiry locally without sending it anywhere. Note that ordinary Graph access tokens are opaque strings, not JWTs, so the decoder will not read them. For Meta's inbound webhook subscriptions, the webhook tester covers the receiving side, and the general API tester handles any endpoint without Graph-specific defaults.

Test another provider's API

Frequently asked questions