WhatsApp Cloud API · Token decision guide · 2026
Temporary vs Permanent WhatsApp Access Token: Which One Should You Use?
Both tokens go in the same header and call the same endpoints. One is built to get your first message out in five minutes. The other is built to keep a business running for years. Mixing them up is one of the most common reasons WhatsApp integrations "randomly" break.
By On Cloud API team · Updated · Checked against Meta's access token documentation on the same date
Quick answer
Use the temporary user access token from your app's WhatsApp → API Setup page only for testing. Meta says it expires in less than 24 hours. For anything that has to keep running (a CRM, chatbot, n8n workflow, order alerts), use a system user access token, which you can generate with a 60-day expiry or no expiry at all. Both need the right permissions and access to your WhatsApp Business Account. A longer life doesn't fix a missing permission.
Every developer we've helped with this has the same story. The test token worked, so it went live. A day later, messages stopped. The code was fine; the token had simply done what it was designed to do and expired.
Temporary vs permanent WhatsApp token: side by side
| Temporary (user) token | Permanent (system user) token | |
|---|---|---|
| Where you get it | Meta for Developers → your app → WhatsApp → API Setup, or Graph API Explorer | Meta Business Settings → Users → System users → Generate token |
| Lifetime | Under 24 hours; Meta says you'll regenerate it every few hours | 60 days or Never, chosen when you generate it |
| Represents | You, the logged-in person | Your backend software |
| Setup effort | One click | Create system user, assign app and WABA, pick permissions |
| Right for | First API call, Postman tests, template checks | Production, persistent staging, automations |
| Permissions needed | Yes | Yes: business_management, whatsapp_business_management, whatsapp_business_messaging |
| Safe in frontend code? | No | No, and it's even riskier because it doesn't expire |
What doesn't change: the endpoint, the Authorization: Bearer header, your WABA ID and your Phone Number ID. Switching tokens changes who is calling, not where the call goes.
Which WhatsApp token for which job?
| What you're doing | Use |
|---|---|
| Sending your first test message or trying the Postman collection | Temporary token |
| A local prototype you'll throw away today | Temporary token |
| A staging server with automated tests that run every night | Separate system user token |
| Production CRM, support inbox, order or OTP notifications | System user token |
| An n8n, Make or Zapier workflow that runs on a schedule | System user token, saved in the tool's credential store |
| Your company requires credentials to be rotated | System user token with 60-day expiry + a rotation reminder |
| Calling WhatsApp from browser JavaScript or a mobile app | Neither. Call your own backend, and let the backend call Meta. |
| A SaaS where many customers connect their own numbers | Embedded Signup (see below) |
Permanent or 60 days? The trade-off nobody mentions
"Permanent" sounds like the obvious choice because nothing expires. But token lifetime is also a security decision.
| Choice | Good when | The catch |
|---|---|---|
| Never expires | Small team, one integration, no rotation process | If it leaks, it works for an attacker until you notice and revoke it |
| 60 days | You already rotate secrets, or compliance requires it | Forget to renew and production stops on day 60 |
Our rule of thumb: if you have a calendar reminder and a documented swap process, 60 days is safer. If you don't, a non-expiring token plus strict secret handling is more reliable than a 60-day token nobody remembers to renew.
Also, "permanent" means no scheduled expiry. The token still dies if someone revokes it, removes the system user's access to the WABA or app, or deletes the system user.
How to tell which token you're currently using
Inherited an integration and not sure what's in the .env file? Don't guess from how the string looks. Both token types look alike.
- Paste it into Meta's Access Token Debugger.
- Check Type: "User" means a temporary token; "System User" means a production token.
- Check Expires: a time within the next day is a test token; "Never" or a date about 60 days out is a system user token.
- Check Scopes for the three WhatsApp-related permissions.
Should staging and production share one token?
Ideally, no. A shared token is quicker to set up, but a staging mistake (a leaked log, a debug screenshot, a teammate's laptop) then exposes your production credential too. Give staging its own system user and token, preferably on a test number. You'll also be able to tell from Meta's logs which environment sent what.
Building a SaaS? Neither token is the right answer
If you're building a platform where customers connect their own WhatsApp numbers, don't ask each customer to generate a system user token and paste it into your app. That's fragile and hard to support.
Meta's route for this is Embedded Signup. The customer connects their WhatsApp account through a Meta popup inside your app, and you receive a business integration system user token scoped to that one customer. On Cloud API works as a Meta Verified Tech Provider on the official Cloud API; you can read more in the On Cloud API overview.
Symptoms of using the wrong token
| What you see | Probably means |
|---|---|
| Works in the morning, fails by the next day | A temporary token is in production |
Error 190 (OAuthException) | Token expired, revoked or invalid |
| Works in Postman, fails on the server | Server still has the old token cached; restart workers and containers |
| New permanent token, same error as before | Not a token problem: check WABA assignment, permissions and Phone Number ID |
| Stopped exactly 60 days after launch | The system user token was generated with a 60-day expiry |
The same logic applies whether you're working in Laravel, PHP, Node.js, Python or n8n. The language doesn't change the token rules. For n8n specifically, our WhatsApp Business API + n8n guide shows where to store the credential so a token swap is a one-field change.
Frequently asked questions
What is the difference between a temporary and a permanent WhatsApp access token?
The temporary token is a user access token from your app's API Setup page, meant for testing, and Meta says it expires in less than 24 hours. The permanent token is a system user access token created in Meta Business Settings for backend software, and you can set it to expire in 60 days or never.
Which WhatsApp access token should I use in production?
A system user access token, with the app and WhatsApp Business Account assigned to the system user and the business_management, whatsapp_business_management and whatsapp_business_messaging permissions selected.
Can I use the temporary WhatsApp token in production?
It will work until it expires, which is less than a day. After that every API call fails, so it should never be used for a live integration.
Is a 60-day token safer than a permanent token?
It limits how long a leaked token stays useful, but production stops if nobody renews it. A 60-day token suits teams with a rotation process; a non-expiring token with strict secret handling suits teams without one.
Does a permanent WhatsApp token ever stop working?
Yes, if it is revoked, the system user is deleted, or the system user loses access to the app, the WhatsApp Business Account or a required permission. Permanent only means it has no scheduled expiry.
How can I check whether my WhatsApp token is temporary or permanent?
Paste it into Meta's Access Token Debugger. A type of User with an expiry within a day is a temporary token; a type of System User with an expiry of Never or about 60 days is a production token.
Should staging and production use the same WhatsApp token?
It is better to give staging its own system user and token so a leak or mistake in staging does not expose the production credential.
How do SaaS platforms get tokens for their customers' WhatsApp numbers?
Through Meta's Embedded Signup. The customer connects their WhatsApp account in a Meta popup and the platform receives a business integration system user token scoped to that customer, so nobody copies tokens by hand.
