How do I check if my WhatsApp access token is still valid?

Call debug_token, or paste the token into the Access Token Debugger, and read `is_valid`. If it is false, the `error` object says why — expired, revoked or a session that ended — and you need a new token.

How can I see which WABA my access token has access to?

Look at `granular_scopes` in the debug_token response. Each permission lists `target_ids`, the WhatsApp Business Account or business IDs it covers; if `target_ids` is absent, that permission applies to every target the token was granted.

What is the difference between the Access Token Debugger and the Graph API Explorer?

The debugger inspects an existing token; the Explorer creates user tokens and runs API calls. Use the Explorer to try a request and the debugger to understand why a token can or cannot make it.

Which token do I use to call debug_token?

An app access token ({APP_ID}|{APP_SECRET}) or the user token of a developer on the same app. The token you are inspecting goes in `input_token`, which also lets you debug a token that is already invalid.

man glossary/access-token-debugger

glossary define access-token-debugger

Name

Access Token Debugger

Meta's tool and debug_token endpoint that show what an access token really is: its app, owner, scopes, granted WABA IDs, validity and expiry.

Synopsis

debug_token, debug_token endpoint, Token debugger

Section

Graph API & SDKs

Level

practitioner

▍

Graph API & SDKs
Practitioner
Developers
Support teams

Reviewed 19 October 2026

Read a debug_token response line by line

5 / 5

json

{

"data": {

"app_id": "1234567890123456",

"type": "SYSTEM_USER",

"application": "Orders Integration",

"data_access_expires_at": 0,

"expires_at": 0,

"is_valid": true,

"issued_at": 1758096000,

"scopes": [

"whatsapp_business_management",

"whatsapp_business_messaging"

],

"granular_scopes": [

{ "scope": "whatsapp_business_management", "target_ids": ["102290129340398"] },

{ "scope": "whatsapp_business_messaging", "target_ids": ["102290129340398"] }

],

"user_id": "61550000000001"

}

Step 5 of 5 · line 18

user_id is the system user behind the token. Log it with auth errors so you know which identity failed.

Jump to

Step through a real-shaped debug_token response for a system user token, then the few lines of server code that turn it into an alert. Each highlight says what to check.

Description

What is the Access Token Debugger?

The Access Token Debugger is Meta's inspection tool for Graph API access tokens. It comes in two forms: a web page in Meta's developer tools where you paste a token and read its properties, and the debug_token Graph API endpoint, which returns the same information as JSON so code can check it. Both answer the questions behind most WhatsApp authentication failures: is this token still valid, whose is it, which app issued it, what may it do, and when does it stop working?

The response describes the token rather than using it. app_id and application name the app; type and user_id identify the person or system user behind it; issued_at, expires_at and data_access_expires_at are Unix timestamps; is_valid gives the verdict; scopes lists the permissions granted; and granular_scopes pairs each permission with target_ids, the specific WhatsApp Business Account or business portfolio IDs it applies to (no target_ids means the permission applies to every granted target). When a token is broken, an error object carries the same code and subcode a real API call would return.

It is easy to confuse with the Graph API Explorer. The Explorer generates user tokens and runs queries; the debugger only inspects a token you already hold. A typical workflow uses both: generate or receive a token, then debug it to prove it has the right scopes on the right WABA before it goes into production. Partners onboarding customers through Embedded Signup also run debug_token on each new business token to confirm which WABAs the customer actually shared.

Key takeaways

The Access Token Debugger inspects an existing token; it never creates a token or makes calls with it.
GET /debug_token?input_token=… returns is_valid, expires_at, scopes and granular_scopes, called with an app token or an app developer's token.
granular_scopes[].target_ids lists the exact WABA or business IDs a permission covers — the quickest way to see what a token can reach.
An expires_at of 0 means the token does not expire; compare any other value with the current Unix time.
Debug from a server script that masks tokens; never paste customers' tokens into shared screens, chats or tickets.

Usage

The Access Token Debugger in code

1# Run from your server: the app token ({APP_ID}|{APP_SECRET}) authorises the call
2curl -G "https://graph.facebook.com/v26.0/debug_token" \
3  --data-urlencode "input_token={TOKEN_TO_INSPECT}" \
4  --data-urlencode "access_token={APP_ID}|{APP_SECRET}"

The inspected token goes in input_token; the app token makes the request.

Mechanics

How does the Access Token Debugger work?

step 1 — Choose the calling token
debug_token must be called with an app access token ({APP_ID}|{APP_SECRET}) or a user token of a developer on the same app. Keep the call on your server, because the app token contains your app secret.
step 2 — Pass the token to inspect
Send GET https://graph.facebook.com/v26.0/debug_token?input_token={INPUT_TOKEN}. The token being inspected goes in input_token; the caller's token authorises the request.
step 3 — Read validity and expiry
Check is_valid first, then compare expires_at (0 means no expiry) and data_access_expires_at with the current Unix time.
step 4 — Check scopes and targets
Confirm scopes includes whatsapp_business_messaging and/or whatsapp_business_management, and that the WABA you call appears in the matching granular_scopes[].target_ids.
step 5 — Act on the result
Invalid or expiring soon: rotate. Missing scope: regenerate with the permission or ask the customer to grant it again. Missing WABA: assign the asset to the system user or re-run Embedded Signup.

Properties

The Access Token Debugger: key facts and limits

Endpoint: GET /v26.0/debug_token?input_token={TOKEN}
Called with: App token ({APP_ID}|{APP_SECRET}) or an app developer's token
Key fields: is_valid, expires_at, scopes, granular_scopes
expires_at = 0: The token does not expire
Timestamps: Unix seconds (UTC)
No target_ids: Permission applies to all granted targets
Web tool: Meta for Developers › Tools › Access Token Debugger

Caveats

Common mistakes with the Access Token Debugger

Mixing up the two tokens
The token you are checking belongs in input_token. The request itself must be authorised by an app token or a developer token of the same app; swapping them returns an error that looks as if the token were broken.
Reading expires_at 0 as expired
Zero means the token has no expiry, not that it expired at the Unix epoch. Only compare non-zero values with the current time.
Stopping at scopes
A token can list whatsapp_business_messaging and still be unable to reach your WABA. Check granular_scopes[].target_ids for the specific ID you are calling.
Pasting production tokens into shared screens
The web tool shows the full token in the browser. Debug from a server script that masks tokens in logs, and keep customers' tokens out of chats and tickets.
Calling debug_token from the browser
The app token includes your app secret, so exposing it in client code is worse than leaking one access token. Keep every debug call on the backend.

Example

Example: A support ticket at a Chennai ed-tech platform

A Chennai ed-tech platform that onboards coaching institutes through Embedded Signup gets a ticket: one institute's class reminders fail with error 200 while every other institute sends normally. Support runs debug_token on that institute's business token. is_valid is true and nothing has expired, but granular_scopes lists whatsapp_business_messaging for a different WABA ID — the institute had created a second account during signup and shared the wrong one. Instead of regenerating tokens blindly, support asks the institute to repeat signup with the right WABA, confirms the new token's target_ids, and closes the ticket the same day.

Why it matters

Why does the Access Token Debugger matter?

Most "the API stopped working" tickets are token problems in disguise: an expiry nobody tracked, a scope removed when a customer edited permissions, a WABA that was never granted. Guessing leads to regenerating tokens that were fine. Thirty seconds with the debugger replaces guesswork with facts, and a scheduled debug_token check turns a silent expiry into an alert days before customers notice anything.

Notes

Best practices for the Access Token Debugger

Run debug_token on every business token right after Embedded Signup and store the target_ids you received.
Schedule a daily check of production tokens and alert seven days before any non-zero expires_at.
Log the token's app_id, type and user_id — never the token itself — next to auth errors, so support can see which identity failed.
In the web tool, the Extend Access Token button turns a user token into a long-lived one for testing; production still belongs to system user tokens.

Questions