Facebook Login for Business

Configuration ID

config_id, passed to FB.login

Response type

code (with override_default_response_type: true)

Code lifetime

About 30 seconds, single use

Exchange endpoint

GET /oauth/access_token

Token produced

Business Integration System User access token

Scope inspection

GET /debug_token → granular_scopes.target_ids

1. 1

   Create a configuration

   In the App Dashboard open Facebook Login for Business, then Configurations, and create one with the WhatsApp Embedded Signup login variation, a system-user access token, WhatsApp accounts as the asset type and the WhatsApp permissions your product needs. Copy the resulting config_id.

2. 2

   Launch login with the config_id

   Call FB.login(callback, { config_id, response_type: 'code', override_default_response_type: true }). The configuration, not your code, decides what the client is asked to approve, so changing permissions means editing or replacing the configuration.

3. 3

   Swap the code server-side

   POST the code to your backend and call GET https://graph.facebook.com/v26.0/oauth/access_token with client_id, client_secret and code. The code is single-use and expires in about 30 seconds.

4. 4

   Inspect what was granted

   Call GET /debug_token?input_token={BUSINESS_TOKEN} with an app token. The granular_scopes array lists each permission with target_ids, the WABA IDs it covers; the most recently onboarded appear first.

5. 5

   Store and use the business token

   Encrypt the token at rest, key it to the client's WABA ID, and use it for that client's messaging and management calls. Never ship it to the browser and never reuse one client's token for another.

• Using classic Facebook Login scopes

  Passing scope: 'whatsapp_business_management' without a config_id produces a personal user token that expires and belongs to one employee. Always launch with a Facebook Login for Business configuration for client onboarding.

• Exchanging the code in the browser

  The exchange needs your app secret, which must never reach a browser or mobile app. Send the code to your server and exchange it there, over TLS, immediately.

• Trusting the front-end IDs

  IDs from the session event can be spoofed or stale. Confirm the WABA appears in the token's granular_scopes before writing it to your database.

• Editing permissions and forgetting existing clients

  A new permission only applies to clients who log in again. Plan a reconnect flow and track which configuration version each client authorised.

Getting this layer right decides whether a partner's onboarding is secure and repeatable. A configuration keeps the requested permissions consistent across every client, the code-for-token exchange keeps the app secret on the server, and a business-scoped token means a client's integration does not break when the employee who clicked through the pop-up leaves. Getting it wrong produces the classic support tickets: tokens that expire, tokens that see the wrong WABA, and permissions that silently were never granted.

• Keep one configuration per product permission set and record the config_id each client used.
• Alert when an exchange fails with an OAuth error: it usually means the code was reused or arrived late.
• Re-run debug_token on a schedule to catch clients who removed your access.