You created a Meta app for a SaaS platform, a WhatsApp integration, or a marketing tool — and the login dialog refuses to load, throws an "Invalid config_id" error, or the standard Facebook Login product simply is not available in your App Dashboard. That is not a bug. Meta now splits login into two different products, and Business-type apps are routed to Facebook Login for Business — a product that works on a completely different model than the classic scope-based login most tutorials still describe.
Facebook Login vs Facebook Login for Business: What Actually Differs
Facebook Login (consumer)
- Built for consumer authentication — "log in with Facebook" for regular users
- Login dialog is invoked with a scope parameter listing permissions
- Returns user access tokens
- Recommended by Meta when you are not a tech provider building on business APIs
Facebook Login for Business
- Meta's preferred authorization product for tech providers building marketing, messaging, and selling integrations
- Available to Business-type apps
- Login dialog is invoked with a config_id — no scope list
- Configuration defines token type, assets, and permissions in the App Dashboard
- Used by WhatsApp Embedded Signup and business-asset onboarding flows
What config_id Actually Changes
With Facebook Login for Business, you build a configuration in the App Dashboard: which access token type your app receives, which business assets (Pages, ad accounts, WhatsApp Business Accounts, catalogs) the client is asked to share, and which permissions are requested. That configuration gets an ID, and your login call passes config_id instead of a scope list. Your app users see the configuration's asset-sharing flow and grant your app access to their business assets in one pass.
One rule surprises many teams: all permissions requested in the configuration must be granted by the user, or the app is granted none of them. And while email and public_profile are granted automatically, a configuration must include at least one other supported permission per app installation.
The Token Decision Inside the Configuration
User access token
- Represents the person who logged in
- Suitable when a human is present in the flow each time
- Expires — long-running automation breaks when it does
Business Integration System User token (BISU)
- Long-lived token representing the client's business, not a person
- Built for unattended, automated API access — the model tech providers are expected to use
- Generated by exchanging the code returned when a client completes the flow (this is also how WhatsApp Embedded Signup issues tokens)
- Scoped per client business — a granular token only exposes that client's assets
How the Setup Path Looks (High Level)
Confirm the app type and login product
Business-type app with business-API use case → Facebook Login for Business. Pure consumer authentication → standard Facebook Login. This decision shapes everything downstream, including App Review.
Build the configuration
Choose the access token type, the business assets the client must share, and the permission set. Getting this combination wrong is the most common source of broken onboarding flows.
Invoke the login dialog with config_id
The SDK call replaces scope with config_id — and a System User token configuration additionally requires the correct OAuth grant type (authorization code) in the call.
Pass App Review for Advanced Access
The configuration only requests permissions. To serve real client businesses, each permission still needs Advanced Access through Meta App Review — with use case descriptions, screencasts, and Business Verification.
Where Business Login Integrations Get Stuck
Common failure points
- "Invalid config_id" or a dialog that never loads — usually a config_id used with the wrong login product, a deleted/mismatched configuration, or an app type that does not match the product.
- Mixing scope and config_id — standard Facebook Login does not support config_id at all; if you roll back, every login call must be rewritten to use scope again.
- The one-way door — newly created Business-type apps cannot switch back to standard Facebook Login. Teams discover this after building against the wrong product.
- Wrong token type for the use case — user tokens expiring mid-automation, or a BISU flow attempted without the Embedded Signup-style code exchange it requires.
- Assuming the configuration replaces App Review — permissions in a config still require Advanced Access approval before they work for client businesses.
Why This Is Harder Than the Docs Make It Look
The configuration model touches four systems at once: app type, login product, token architecture, and App Review. Each has its own failure mode, and the error messages rarely point at the real cause. A SaaS platform that picks the wrong token type, or requests a permission set the client's role cannot grant, ends up with an onboarding flow that fails silently for some clients and works for others — the hardest kind of bug to trace. This is exactly the stage where most teams either lose weeks in trial-and-error or bring in someone who has already been through the review side of it.
Related reading on this site: which Facebook Login permissions require App Review, WhatsApp Embedded Signup and Tech Provider onboarding, and the Facebook App Review service if your permissions are stuck in review. If the login rebuild is bigger than your team has time for, you can hire a Facebook API developer to implement it.
Building on Facebook Login for Business?
I help SaaS platforms and tech providers set up the right login product, configuration, and token model — and prepare the App Review submission that gets the permissions working for real clients. Share where your integration is stuck and I will tell you what it needs.
Disclaimer: Meta makes all login product availability, configuration, App Review, and permission approval decisions independently. Product behavior and requirements reflect publicly available Meta for Developers documentation at the time of writing and can change. Outcomes and timelines cannot be guaranteed. This site is not affiliated with or endorsed by Meta Platforms, Inc.