Every SaaS platform, agency and white-label reseller that touches the Meta APIs eventually hits the same fork: do you run one app that serves every client, or do you create a separate app for each client?
It reads like an engineering question. It is not. It is an App Review question, and the answer is decided by Meta’s access-level model, its business verification rules and its ownership-transfer policy — not by your codebase. Most teams find this out after a rejection, when the fix means rebuilding client onboarding from scratch.
Search the question and you get generic SaaS multi-tenancy articles about databases, tenant isolation and connection pooling. None of them mention Meta. That gap is exactly why the decision gets made wrong so often: the architecture literature and the platform policy are answering two completely different questions.
This page explains what each model commits you to, what Meta’s own documentation actually states, and where the expensive mistakes happen. It is not a click-path tutorial — the execution detail is where the real work sits.
The two models, and what each one really commits you to
Model A — One app, many clients
A single Meta app owned by your business. Clients connect their own Pages, Instagram accounts, WhatsApp Business Accounts or ad accounts to it through an authorisation flow.
This is the model Meta’s own tooling is built around. It is also the model that puts your app squarely inside the strictest review path, because your app is handling business data owned by other business portfolios.
Model B — One app per client
A new Meta app for every customer, often created inside the client’s own business portfolio, or created by you and then handed over.
It feels safer — blast radius is smaller, one client’s enforcement does not touch another. What teams underestimate is that every one of those apps carries its own review, its own verification state and its own ongoing compliance obligations.
What Meta’s documentation actually pins down
Before anyone argues architecture, these are the constraints published in Meta’s own developer documentation. They shape the decision more than any internal design preference.
Access levels decide everything. Meta states that permissions with Standard Access “can only be requested from app users who have a role on the requesting app.” Permissions with Advanced Access can be requested from any app user. If your clients are not staff on your app — and they are not — you are in Advanced Access territory. There is no third option.
Advanced Access requires Business Verification. Meta’s access-levels documentation states plainly that Business Verification is required to get Advanced Access, and that additional App Review on an individual permission and feature basis may also be required. Under Model B, that is not one verification — it is a verification question for every portfolio involved.
App types cannot be changed. Meta’s documentation is explicit: “App types cannot be changed. If your app needs products, permissions, or features that are unavailable to its current type you must create a new app with a different type instead.” A wrong choice at creation time is not a settings fix.
Advanced Access brings an annual obligation. Apps holding Advanced Access for a permission or feature must complete Data Use Checkup, an annual certification that the app uses Meta APIs, products and data in line with the Platform Terms and Developer Policies. Under Model B, that annual obligation multiplies by your client count — and nothing about it is automatic.
Handing an app to a client is a policy event, not an admin task. Meta’s ownership-transfer documentation exempts only changes within the same company and transfers between subsidiaries. Everything else requires Meta’s prior written consent through a submitted request form — and until it is approved, the transfer is not recognised by Meta and the new owner’s use of Platform Data may breach the Platform Terms.
Serving other businesses’ data has its own gate. On WhatsApp, Meta’s Tech Provider documentation states that Advanced Access to whatsapp_business_management is “required to access your clients’ WABAs” and that without it, API calls using that permission on WABAs not owned by your business return error code 200. The multi-client capability is a reviewed permission, not a configuration flag.
The five checks that actually decide it
In practice, the model is not chosen — it is forced, by the answers to these five questions. This is the shape of the assessment, not the execution.
Who owns the data your app touches?
If your app reads or writes business data owned by other business portfolios, you are on the Tech Provider path and the associated permissions need Advanced Access. This single answer eliminates most of the design space before anything is built.
Who will actually be verified?
Advanced Access requires a verified business behind the app. Under one shared app, that is your business, once. Under one app per client, the question repeats for every portfolio, and each answer depends on documentation you do not control. See our guide to Meta Business Verification and why it gets rejected.
How will tokens survive staff turnover?
Client-side user tokens die when a person leaves or revokes access. Server-to-server access is normally built on system user access tokens, and the way those are provisioned differs sharply between the two models. Getting this wrong shows up months later as silent integration failures.
What does the reviewer need to see working?
App Review is evidence-driven. A reviewer has to be able to reach and exercise the flow, end to end, as a user who has no role on your app. Under Model B that demonstration has to be reproducible per app — and the environment that makes it reproducible is usually the part nobody planned for.
What happens when one client goes wrong?
Enforcement, restriction and appeal all operate at the app and portfolio level. The isolation benefit of per-client apps is real — but so is the multiplied compliance surface. This trade-off should be a deliberate decision, made before onboarding is built, not discovered during an incident.
Where teams actually get stuck
Building on Standard Access and calling it done. Everything works in testing because the testers have roles on the app. The first real client sees permission errors. This is the single most common way the multi-tenant question surfaces — far too late. Our explainer on Meta Advanced Access covers what actually changes at that boundary.
Choosing the app type by guesswork. Because the type cannot be changed afterwards, an early wrong pick means starting a new app and repeating verification and review. Teams frequently discover the constraint at the moment they try to add the product they actually need.
Promising clients “their own app, in their own account”. It sounds reassuring in a sales call. It commits you to an ownership-transfer process that requires Meta’s prior written consent in most scenarios, on a timeline you do not control.
Asking clients for logins instead of access. Password sharing fails both platform expectations and any serious security review. Meta’s access model is built around roles, partner access and system users precisely so that credentials never change hands. If your onboarding depends on collecting client passwords, it needs rework before submission, not after.
Writing the use-case description around your architecture. Reviewers assess what the app does for people, not how your tenancy layer works. A submission written from the engineering diagram rather than the user journey reads as unclear intent — and unclear intent is one of the most reliable ways to draw a rejection.
Why the wrong choice is expensive to reverse
Neither model is universally correct. What makes this decision unusual is the asymmetry of unwinding it. Changing your mind after launch can mean: creating new apps because types are fixed, repeating business verification, resubmitting App Review per permission, renegotiating who owns each app, and re-authorising every connected client — while the existing integration is live and billing.
That is why the model should be settled before the first client is onboarded, against Meta’s current documentation rather than a blog post or a forum thread. Platform requirements in this area change, and the version you designed against two years ago is unlikely to be the version being reviewed today.
Where support helps
Most of the value here is in the assessment and the submission, not the code: reading your intended client model against current platform documentation, identifying which permissions genuinely need Advanced Access, structuring the reviewer-facing demonstration so the flow can be exercised without a role on the app, and writing the use-case narrative in the terms a reviewer assesses. That is the work we do on Meta App Review and API approval projects — review preparation and policy-aligned guidance.
Independent service. Not affiliated with, endorsed by, or a partner of Meta Platforms, Inc. All platform requirements described here are drawn from Meta’s public developer documentation at the time of writing and can change without notice — always confirm against the current official documentation before making an architecture decision. Review outcomes and timelines are decided solely by the platform and cannot be guaranteed.