Business Management API

Clicking through Business Settings works for one WABA and one integration. It breaks down for an enterprise running 30 WABAs across brands, an agency handing accounts back to clients, or a partner provisioning tokens for every new environment. The Business Management API turns those chores into code: an inventory of every WABA and who can act on it, system users created with only the tasks they need, tokens that rotate on a schedule, and offboarding that removes access in one reviewed script instead of a dozen manual clicks someone forgets.

1. 1

   Get portfolio-level access

   Use a token from an admin system user that holds business_management for portfolio calls. Keep this identity for provisioning scripts only, never for sending messages.

2. 2

   Inventory your assets

   List the WABAs you own with GET /{BUSINESS_ID}/owned_whatsapp_business_accounts and those shared with you with GET /{BUSINESS_ID}/client_whatsapp_business_accounts, then GET /{BUSINESS_ID}/system_users for the identities.

3. 3

   Install the app and issue tokens

   Call POST /{SYSTEM_USER_ID}/applications with business_app, then POST /{SYSTEM_USER_ID}/access_tokens with the permissions the service needs and an appsecret_proof. Prefer 60-day tokens so rotation is routine.

4. 4

   Assign WABAs with the right tasks

   Grant each system user only the WABAs it needs through POST /{WABA_ID}/assigned_users: MANAGE for full control, DEVELOP for developer access, or granular tasks such as MANAGE_TEMPLATES.

5. 5

   Rotate, audit and offboard

   Refresh tokens with fb_exchange_token, deploy, then revoke the old one. Review assigned_users per WABA regularly and remove access with DELETE when a service, agency or partner leaves.

Acts on

Business portfolio, system users, apps, assets, partners

Portfolio permission

business_management (rarely needed for messaging)

Owned WABAs

GET /{BUSINESS_ID}/owned_whatsapp_business_accounts

Shared WABAs

GET /{BUSINESS_ID}/client_whatsapp_business_accounts

Issue a token

POST /{SYSTEM_USER_ID}/access_tokens

Token lifetimes

Never-expiring, or 60 days (set_token_expires_in_60_days)

Assign a WABA

POST /{WABA_ID}/assigned_users with tasks (MANAGE, DEVELOP…)

Credit Line API limit

5,000 requests per hour

• Calling it for WhatsApp objects

  Templates, phone numbers and analytics belong to the WhatsApp Business Management API and need whatsapp_business_management. A token with only business_management cannot create a template.

• Granting business_management everywhere

  Portfolio access in a sending service turns a leaked token into control of the whole portfolio, and unneeded permissions are a common App Review rejection reason. Keep it in one provisioning identity.

• Assigning assets with a regular system user

  Adding users to a WABA needs an admin system user's token. A regular (EMPLOYEE) system user can act only on what it was given and cannot hand out access.

• Non-expiring tokens nobody rotates

  Meta suggests 60-day tokens because a leaked never-expiring token stays valid indefinitely. If you keep non-expiring ones, rotate them on a schedule anyway.

• Running audits in a tight loop

  assigned_users sits under the per-WABA business use case limit of 200 calls an hour, or 5,000 for an active WABA. Spread large audits out and read the usage header.

• Keep the approved map of system users, WABAs and tasks in Git and let the audit script report any drift.
• Name system users after their job (wa-sender-prod, wa-templates-sync) so a review can tell what each one is for.
• Use granular tasks such as MANAGE_TEMPLATES instead of MANAGE when a service needs only one kind of access.
• Remove an agency's or partner's assignments on the day the contract ends, then rotate any token they could have seen.