System User

Why it matters for WhatsApp on the API

The whole promise of the WhatsApp Business API is unattended, always-on messaging — order confirmations at 2am, OTPs the moment a user hits submit, campaign broadcasts to thousands of contacts. None of that can depend on a person being logged in. If you connected your automation using a personal user token, it would expire, break the day that employee left, or fail the next time Meta forced a re-login. A System User token issued as long-lived does not carry that fragility: it stays valid until you revoke or regenerate it. That stability is what lets your WhatsApp flows run for months without a human touching the credentials, and it is what keeps template sends, delivery webhooks, and message-status reads reliably authenticated.

• Continuity: automations keep running when staff change or reset passwords
• Security: least-privilege scoping limits blast radius if a token leaks
• Ownership: the WABA and its assets stay under your business, not a vendor's
• Auditability: service traffic is separated from individual employee actions

How a System User is set up and used

The flow is straightforward once you know the pieces. An admin opens Meta Business Manager, goes to Business Settings, and creates a System User under Users > System Users. That System User is then assigned access to the relevant assets — most importantly your WhatsApp Business Account and the app that will call the API. Finally, the admin generates an access token, selecting the specific permissions the integration needs (for WhatsApp this typically includes whatsapp_business_messaging and whatsapp_business_management) and choosing a long-lived expiry. That token is handed to the platform once, securely. When you onboard with InfiQ, our team walks you through this end to end so that the WABA, phone number, and token all sit inside your own Business Manager with the correct scopes — you keep control while we handle the wiring.

• Create the System User in Business Settings
• Assign the WABA and app as assets
• Generate a long-lived token with only the permissions needed
• Store the token in the platform once, never in personal chats or code repos

Common mistakes to avoid

Most System User problems trace back to a handful of avoidable errors. The first is using a personal profile token instead of a System User token, which works in a demo and then silently expires in production. The second is over-permissioning — granting an Admin System User full control when a scoped Employee would do, which turns a single leaked token into a full-business risk. A third is losing track of ownership: if a vendor sets up the System User inside their own Business Manager rather than yours, you can find yourself locked out of your own WABA and number. Others include failing to remove a departing team member's admin rights, storing raw tokens in code repositories or shared documents, and forgetting that if you ever regenerate a token you must update it everywhere the old one was used. Getting these right early prevents the painful outages that surface at exactly the wrong moment.