System User Access Token for WhatsApp: Step by Step

01 · How it works, in 5 steps

How does a system user access token work?

1
Prepare the system user
Create or pick a regular system user in your business portfolio and assign it the Meta app and the WABA. The regular role is enough for sending and template work.
2
Choose app, permissions and expiry
Click Generate new token, select the app and tick only the API permissions the service uses: whatsapp_business_messaging to send, whatsapp_business_management for templates, numbers and webhook subscriptions, and business_management only for portfolio-level calls. Pick 60 days or never.
3
Copy it once into a vault
The token is displayed only at creation. Put it straight into a secrets manager or your platform's encrypted credential store, never into source code, a committed .env file, a ticket or a chat.
4
Verify before deploying
Call debug_token, or paste the token into the Access Token Debugger, and check is_valid, type: SYSTEM_USER, the scopes, the WABA IDs in granular_scopes and expires_at. Then send a test template from the phone number ID to an internal number.
5
Plan rotation and retirement
Record where the token is used and who can re-issue it. For token rotation, issue a replacement, deploy it and confirm traffic before revoking the old access; schedule 60-day tokens well before they expire.

02Try it

Hands-on: use the controls to work through it yourself.

Tick off a production-ready token

9/9

ticked

Required: 7 / 7
Optional: 2 / 2

Token ready for production

Every item ticked.

Create a regular system user in your own portfolio RequiredBusiness settings → Users → System users. Name it after its job, such as wa-sender-prod.
Assign the Meta app RequiredEvery token is issued for one app, so the system user must have that app.
Assign the WABA RequiredFull control, or partial access that matches the job. The phone numbers come with the WABA.
Tick only the permissions the service uses Requiredwhatsapp_business_messaging to send; add whatsapp_business_management for templates, numbers and subscriptions.
Choose an expiry Required60 days if rotation is automated; never only with monitoring and a re-issue drill.
Store it in a secrets manager RequiredIt is shown once. Never paste it into code, chat, tickets or a committed .env file.
Verify it with debug_token Requiredtype SYSTEM_USER, is_valid true, the right scopes and your WABA ID in granular_scopes.
Send a test templateFrom the phone number ID to an internal, opted-in number, and watch the status webhooks arrive.
Write down the rotation planWhere the token is used, who can re-issue it and how the old access is retired.

The checks a team runs before a system user access token goes live. Tick each one to fill the ring: the required steps make the token work, the rest keep it safe over time.

03What is a system user access token?

A system user access token is the credential a system user issues so that a server can call Graph API, including the WhatsApp Cloud API, without anyone logged in. You create it in Business settings → Users → System users → Generate new token (or through the API): pick the Meta app it will be used with, tick the permissions — usually whatsapp_business_messaging and whatsapp_business_management — and choose an expiry of 60 days or never. Your code then sends it as Authorization: Bearer {ACCESS_TOKEN} on every request.

What a token can do is the overlap of three things: the permissions on the token, the assets assigned to its system user (a WABA and, through it, its phone numbers) and the app it was issued for. A token with whatsapp_business_messaging whose system user was never given the WABA cannot send; a token with the WABA but without whatsapp_business_management cannot create templates. The debug_token endpoint shows all of it: type: SYSTEM_USER, the scopes, the granular_scopes listing which WABA IDs each permission covers, and expires_at, which is 0 for a token that never expires.

Two neighbours are easy to confuse with it. The system user is the identity that holds asset access; the token is one credential issued from it, and the same identity can hold several. A user access token belongs to a person and expires within hours. A business integration system user access token is what a Tech Provider receives by exchanging an Embedded Signup code, scoped to one onboarded customer; a system user access token is what a business generates for its own portfolio.

Key takeaways

A system user access token is the long-running credential servers use to call the WhatsApp Cloud API on a business's own assets.
It inherits the system user's assigned assets and adds the permissions and expiry chosen when it is generated.
Expiry is 60 days or never, and even a non-expiring token stops working if it is revoked or its system user is deleted.
It is shown once: store it in a secrets manager and confirm its scopes, WABA IDs and expiry with debug_token.
It is not the business integration token a Tech Provider receives from Embedded Signup for a customer's assets.

04 · In code

A system user access token in code

1curl -G "https://graph.facebook.com/v26.0/debug_token" \
2  -d "input_token={SYSTEM_USER_TOKEN}" \
3  -d "access_token={APP_ID}|{APP_SECRET}"

Inspect the token with an app access token; never print the token itself in logs.

05 · Mistakes to avoid

Common mistakes with a system user access token

Ticking every permission
Adding ads, pages and business_management to a sender's token turns it into a skeleton key. Grant only the WhatsApp permissions each service actually calls.
Right scopes, missing asset
A token with the right permissions still fails with error 100 or 200 if its system user was never assigned the WABA. Confirm the WABA ID appears in granular_scopes.target_ids.
Reading never-expiring as never-breaking
Revocation, deleting the system user or removing its access to the app or WABA all end a non-expiring token. Alert on error 190 and keep a written re-issue procedure.
Leaking it through URLs, logs and repositories
Tokens passed as query strings, echoed in CI output or committed in .env files end up in logs and Git history. Send it in the Authorization header, mask it in logs and scan repositories for secrets.

06 · Key facts

A system user access token: key facts and limits

Expiry options: 60 days or never
Sent as: Authorization: Bearer {ACCESS_TOKEN}
Typical scopes: whatsapp_business_messaging, whatsapp_business_management
debug_token type: SYSTEM_USER
Never-expiring token: expires_at: 0
Shown: Once, when generated
Fails with: Error 190 once revoked or invalidated

07Example: Replacing a leaked token at a Chennai logistics firm

A Chennai logistics firm's dispatch service has used a never-expiring system user access token for two years, until a security review finds it in an old CI log. The team creates a fresh system user, wa-dispatch-v2, assigns it the app and the WABA, and issues a token with only whatsapp_business_messaging. debug_token confirms it is valid and scoped to the firm's WABA, the token goes into the secrets manager, and the service is redeployed. Once dashboards show sends succeeding on the new token, an admin deletes the old system user, which kills the leaked token. Delivery updates never pause, and the new token can no longer touch templates, which dispatch never needed.

08 · Why it matters

Why does a system user access token matter?

This token is the key to every production WhatsApp send, so the way it is made decides the way an integration fails. Made with the wrong permissions, the first template-sync job gets a permissions error. Made from a person's login instead, everything stops when that person leaves. Pasted into a repository, it hands your WABA to whoever finds it. Generated deliberately — least permissions, the right assets, a known expiry, stored in a vault and verified before deploy — it is what lets an integration run unattended for months.

09 · Pro tips

Best practices for a system user access token

Give each service its own token so one can be replaced without touching the others.
Turn on Require App Secret in the app settings and send appsecret_proof with server calls.
Prefer 60-day tokens where rotation is automated; use never-expiring tokens only with monitoring and a practised re-issue drill.
Make it part of your secrets management: store the token's metadata (system user, app, scopes, issue date) next to the secret.

10System User Access Token FAQs

How do I get a permanent access token for the WhatsApp Cloud API?+

Generate a system user access token with the expiry set to never. Create a system user in your business portfolio, assign it your app and WABA, then use Generate new token with the WhatsApp permissions you need.

Why did my WhatsApp access token expire after a day?+

You were most likely using the temporary token from the App Dashboard's API Setup page, which is meant for first tests and expires within about 24 hours. Use a system user access token for anything that runs unattended.

Can a never-expiring system user token stop working?+

Yes. It stops if it is revoked, if its system user is deleted, or if the access to the app or WABA behind it is removed. Calls then fail with error 190, so monitor for it.

What is the difference between a system user access token and a business integration token?+

A business generates a system user access token for its own assets. A Tech Provider receives a business integration system user access token by exchanging an Embedded Signup code, scoped to one customer's WhatsApp assets.

See InfiQ pricing

System User Access Token

How does a system user access token work?

Prepare the system user

Choose app, permissions and expiry

Copy it once into a vault

Verify before deploying

Plan rotation and retirement

02Try it

Tick off a production-ready token

03What is a system user access token?

A system user access token in code

Common mistakes with a system user access token

Ticking every permission

Right scopes, missing asset

Reading never-expiring as never-breaking

Leaking it through URLs, logs and repositories