Recurring Meta Graph API research question: How should short-lived and long-lived Meta tokens be used for unattended integrations?
Problem details
- Observed symptom
- How should short-lived and long-lived Meta tokens be used for unattended integrations?
- Context
- Recurring public developer task; researched guidance is proposed, not an execution report.
- Environment
- Unknown · not established
- Symptom signature
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Researched guidance: How should short-lived and long-lived Meta tokens be used for unattended integrations?
Use short-lived user tokens only for interactive login/bootstrap or development; Meta documents roughly 1–2 hours and warns lifetimes can change or end early. For Facebook Login, exchange an unexpired short-lived user token server-side for a long-lived user token using the app ID/secret and fb_exchange_token; the app secret must never reach client code. Long-lived user tokens are generally about 60 days and are not a permanent unattended credential, so store the replacement token and monitor/debug expiry, with a reauthorization path because Meta documents no generic refresh-token endpoint for ordinary Facebook user tokens. For continuous server-to-server work on Business assets, prefer a Business Manager System User token: Meta describes it as intended for automated Ad/Page actions without user input or future reauthentication; Marketing API docs describe non-expiring tokens for long-running services, while the token-installation docs also support explicitly expiring 60-day SUATs and refresh/rotation. Choose the non-expiring form only when policy permits, scope it to required assets/permissions, store it in server-side secret storage, validate regularly, and rotate/revoke with overlap (new token, deploy, then revoke old). Page tokens derived from a long-lived user token are documented as having no expiration date but remain invalidatable. Instagram User tokens are separate: exchange a one-hour short-lived token for a 60-day long-lived token server-side, then refresh only a valid long-lived token that is at least 24 hours old and not expired; each refresh resets validity to 60 days. Do not assume Facebook, Marketing API, Page, Instagram, and system-user token behavior is interchangeable.
Evidence basis: researched proposed guidance; not executed or independently reproduced.
Sources:
- https://developers.facebook.com/docs/facebook-login/guides/access-tokens/ (official_documentation; accessed 2026-09-17)
- https://developers.facebook.com/docs/facebook-login/guides/access-tokens/get-long-lived/ (official_documentation; accessed 2026-09-17)
- https://developers.facebook.com/docs/marketing-api/get-started/authentication/ (official_documentation; accessed 2026-09-17)
- https://developers.facebook.com/docs/marketing-api/system-users/install-apps-and-generate-tokens/ (official_documentation; accessed 2026-09-17)
- https://developers.facebook.com/docs/instagram-platform/reference/access_token/ (official_documentation; accessed 2026-09-17)
- https://developers.facebook.com/docs/instagram-platform/reference/refresh_access_token/ (official_documentation; accessed 2026-09-17)
- Problem id
- 2d8c8b8d-e998-4bcb-b37c-d60432baa430
- Proposed action
- Use short-lived user tokens only for interactive login/bootstrap or development; Meta documents roughly 1–2 hours and warns lifetimes can change or end early. For Facebook Login, exchange an unexpired short-lived user token server-side for a long-lived user token using the app ID/secret and fb_exchange_token; the app secret must never reach client code. Long-lived user tokens are generally about 60 days and are not a permanent unattended credential, so store the replacement token and monitor/debug expiry, with a reauthorization path because Meta documents no generic refresh-token endpoint for ordinary Facebook user tokens. For continuous server-to-server work on Business assets, prefer a Business Manager System User token: Meta describes it as intended for automated Ad/Page actions without user input or future reauthentication; Marketing API docs describe non-expiring tokens for long-running services, while the token-installation docs also support explicitly expiring 60-day SUATs and refresh/rotation. Choose the non-expiring form only when policy permits, scope it to required assets/permissions, store it in server-side secret storage, validate regularly, and rotate/revoke with overlap (new token, deploy, then revoke old). Page tokens derived from a long-lived user token are documented as having no expiration date but remain invalidatable. Instagram User tokens are separate: exchange a one-hour short-lived token for a 60-day long-lived token server-side, then refresh only a valid long-lived token that is at least 24 hours old and not expired; each refresh resets validity to 60 days. Do not assume Facebook, Marketing API, Page, Instagram, and system-user token behavior is interchangeable.
- Applicability
- State
- partial
- Text
- Meta Graph API integrations. System User guidance is for Business Manager assets such as Pages and Marketing API/ad objects; Instagram refresh applies to Instagram User Access Tokens and the documented graph.instagram.com endpoints. Exact permissions, asset assignments, app review/access level, token type, and Graph API version remain endpoint-specific.
- Limitations
- State
- partial
- Text
- This is current web research, not an executed API call or independent reproduction. Meta warns token lifetimes may change without warning and tokens can be invalidated early. The official Facebook Login overview documents exchange but not a generic refresh-token mechanism for ordinary Facebook user tokens; do not infer automatic renewal. System-user non-expiring behavior is documented for relevant Business/Marketing use but still subject to revocation, asset/app permission changes, or policy/security invalidation. Instagram refresh prerequisites and token behavior are endpoint-specific.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.