Meta Partner Access vs System User vs Asset Sharing: Which One Actually Grants API Access
In Meta Business Manager these three sit in the same settings panel and all appear to hand over the same control. To a human working in Ads Manager they are close to interchangeable. To the Graph API they are not remotely the same thing — and picking the wrong one is one of the quietest ways to end up with a client integration that authenticates fine and then returns nothing.
Three mechanisms, three different things
Most teams discover the difference the hard way: the client says “you have access”, the dashboard agrees, and the API still refuses. That is because access in the Business Manager UI and access to an API asset are governed by separate systems.
Asset sharing
A single asset — a Page, an ad account, a catalog — is shared to a specific person or business with a defined set of tasks. It is the narrowest grant, and it is scoped to the individual it was given to.
Partner access
A business-to-business relationship between two portfolios. Meta’s own docs describe assets owned by one Business Manager and accessed by another as proxied assets, and they behave differently from assets you own outright.
System user
Not a person at all. Meta defines system users as representing “servers or software making API calls to assets owned or managed by a Business Manager”. This is the only one of the three built for machine-to-machine access.
Why the API cares, and the dashboard does not
The important line is in Meta’s own System Users documentation: “If you try to use system user tokens to work on ad objects or Pages on behalf of a real user of your software, you cannot link this user to those actions unless you take them through Facebook Login.” That single sentence rules out an entire architecture that a lot of platforms build first and discover second.
Access that a human can see in Business Manager is not the same as access a token can exercise. The token has to have been issued under the right business, by the right user type, against the right app — and that app has to have been reviewed for the permissions in question.
What the documentation actually pins down
| Question | What Meta’s docs state |
|---|---|
| Can a system user use any app? | No. “A system user can only be granted a role on an app if both the system user and the app belong to the same business.” Cross-business access is directed to the Business On Behalf Of API instead. |
| Is App Review skippable if I own the assets? | No. To have system users, the Business Manager must own an app that has gone through App Review (and Business verification) for the permissions the system user wants access to. |
| How many system users can I have? | Meta publishes a table tied to your access level to the Ads Management Standard Access feature: Standard = 1 system user + 1 admin system user; Advanced = 10 system users + 1 admin system user. Admin system users stay capped at 1 by design. |
| Do system user tokens expire? | Meta’s On Behalf Of guide states the advantage over a user token directly: users can cycle off a business, but system user access tokens don’t expire. |
| Can a partner reach a client’s assets? | Yes, but through a defined path. Proxied assets — assets owned by another Business Manager — can be assigned to a system user for given tasks, and the Business On Behalf Of API exists specifically so a partner can create a system user under the client’s Business Manager. |
| Who stays in control? | The client. In the On Behalf Of model, “the client continues to be the owner of their business” and can revoke the system user or remove asset access programmatically. |
The dependency chain nobody maps before they build
The reason this decision is expensive to get wrong is that it is not one choice. It is a chain, and each link constrains the next.
App ownership determines everything downstream
Which business owns the app decides whether a system user can hold a role on it at all. Get this wrong and no amount of asset sharing in the UI will fix it — the fix is architectural, not a settings toggle.
Access level determines your system user ceiling
The number of system users you may create is tied to your app’s access level for Ads Management Standard Access. A one-system-user ceiling forces very different token hygiene than a ten-user ceiling, and teams routinely design for the wrong one.
App Review and Business verification gate the permissions
The system user only reaches what the reviewed permissions allow. Meta requires the app to have gone through review, and Business verification where applicable, for the permissions in scope. This is the step that converts an infrastructure decision into a Meta Business Verification and App Review problem.
Task assignment decides what the token can actually do
Tasks are granular and asset-type specific — ad accounts accept MANAGE, ADVERTISE and ANALYZE; Pages add CREATE_CONTENT and MODERATE. A token with the right permission but the wrong task fails in a way that looks like a permission problem and is not.
Client-side revocability has to be designed in, not discovered
The client can revoke the relationship or the assets at any time. Whether that is a clean disconnect or a silent outage across every client on your platform depends on which of the three mechanisms you built on.
What a correct setup gets you
Long-lived, non-expiring machine credentials instead of user tokens that die when a staff member leaves the client’s business.
Least-privilege tokens per function, with the admin system user reserved for administration — Meta’s own recommendation.
A defined revocation path the client controls, so ending a relationship does not require credential archaeology.
An app, an owner business and a permission set that line up with what App Review expects to see, instead of contradicting each other.
Where these setups break
- The app belongs to the wrong business. The system user and the app are in different portfolios, so the role can never be granted — and the error surfaces as a permissions failure, not an ownership one.
- Building on user tokens because they worked in testing. They work until the person leaves the client’s business, and then a subset of clients silently stop syncing.
- Assuming UI access equals API access. Someone shares a Page in Business Manager, everyone sees it, and the token still cannot touch it because the task assignment was never made to the system user.
- Designing for ten system users while sitting on Standard access. The ceiling is a function of your access level, so the architecture assumes headroom that App Review has not granted yet.
- Treating this as a settings problem. By the time the tokens are wrong, the review submission usually is too — the permission story you told Meta no longer matches the access model you built.
- Skipping the review requirement entirely. Owning the assets does not remove the App Review and verification requirement for the permissions the system user needs.
The part that is worth getting right first
This is a decision made once, early, and paid for repeatedly. Reversing it later means re-parenting an app, re-issuing every client credential, and in most cases going back through review with a changed access story — while live integrations are already depending on the old one.
If you are architecting client onboarding for a SaaS platform, an agency stack, or a white-label product, the access model and the App Review submission need to be designed together rather than sequentially. That is the work we do: mapping the ownership, permission and verification chain to what Meta will actually approve, then preparing the submission around it. See the services overview, and the related breakdowns on Meta system user access tokens and Meta Advanced Access.
Independent consultancy. Not affiliated with, endorsed by, or a partner of Meta Platforms, Inc. Platform requirements change; every claim above is drawn from Meta’s published developer documentation at the time of writing and should be re-checked against the current docs before you build. Review outcomes are decided solely by Meta and no specific outcome can be guaranteed.