A developer is told their app needs a verified business before Advanced Access is granted. They open the guide, which says to complete verification in Business Manager. They log in and there is no Business Manager. There is Meta Business Suite, and inside it something called a business portfolio, and a Security Centre that shows a verification status nobody on the team remembers setting.
The renaming is cosmetic. The requirement underneath it is not, and the confusion it creates is the reason a lot of Meta API projects lose weeks at exactly the wrong moment — after the code is finished and before a single permission has been approved.
What actually changed
The old standalone Business Manager interface is gone. Meta states it directly in its own help centre:
So “business portfolio” is the current name for the container that holds your Pages, ad accounts, Instagram accounts, WhatsApp accounts, pixels, catalogues, apps and the people who can touch them. It is the same object that older documentation calls a Business Manager account, and that the Graph API and most developer docs still call a Business.
Three names, one thing. That would be a trivia point, except that Meta’s own developer documentation, its business help centre, its billing screens and every third-party tutorial written before the change all use different ones — and the instructions each gives no longer match the interface the reader is looking at.
| What you will see it called | Where | What it means |
|---|---|---|
| Business portfolio | Meta Business Suite, Security Centre, billing | Current product name |
| Business Manager | Older help articles, most tutorials, some App Dashboard copy | Legacy name for the same container |
| Business | Developer docs, Graph API, App Dashboard settings | The API-side name for the same object |
What did not change: the developer requirement
Underneath the rename, the rule that matters to an API project is unchanged and is stated on Meta’s developer documentation:
Two details in that paragraph decide a lot of project timelines. The first is that verification attaches to the business, not the app — connect the app to an already-verified portfolio and there is nothing further to do. The second is the failure mode: an unverified business does not produce a clear error. Features are simply inactive and external users cannot grant permissions, which reads at the code level like a broken integration rather than an administrative gap.
There is also a role split that stalls teams routinely. Meta notes that anyone with an Administrator role on the app can connect it to a business, but only someone with an Admin role in the business can complete the verification. The developer can do half the job and then needs a person who is usually in finance or operations — and who may not exist inside the company any more.
Individual verification is not a way around this. Meta has stated that once the business verification process is complete, individual verification is no longer allowed for access.
The second verification most teams have never heard of
Business Verification is the one everybody eventually finds. Access Verification — being verified as a Tech Provider — is the one that surprises people, and it applies to exactly the situation most SaaS products are in: an app used by other businesses, not only by your own staff.
The permission list it governs is not a fringe one. It includes ads_management, ads_read, business_management, catalog_management, instagram_basic, instagram_business_basic, instagram_business_content_publish, leads_retrieval, pages_show_list, pages_manage_posts, pages_read_engagement, read_insights, the Threads permissions and whatsapp_business_management — in other words, close to the entire surface a social-media management or marketing tool is built on.
The error is a lie
A failed verification check returns error code 100 with the generic message about an object that does not exist or cannot be loaded due to missing permissions. Nothing in it mentions verification, so teams debug the endpoint instead.
It has a prerequisite and a clock
Business Verification must be completed first, and the business must carry no restrictions. Businesses already claiming affected apps get an email and 60 days; after that, calls are gradually subjected to the verification check.
Meta says a decision on access verification is made in approximately five days once a business admin completes the form. The form itself asks the business to categorise and describe how it uses other businesses’ data to provide a service to them — a positioning question rather than a technical one, and one that is answered badly far more often than it is answered wrongly.
Verified is a status, not an achievement
Both verifications can be lost. Meta lists the conditions under which a verified Tech Provider is treated as unverified again: the business’s verification status changes to unverified, the app becomes disconnected from the business that created or claimed it, or the business account becomes restricted.
The middle one is worth reading twice. An app being moved between portfolios, an ownership transfer during an acquisition, or a tidy-up of an old business account can disconnect an app from its verified business — and every external customer of that app loses the ability to grant permissions, with no code change and no deploy to point at. Meta does restore the status automatically once the condition is reversed, but the outage happens first and it happens to your customers.
How the work is actually sequenced
Find out which portfolio you are really in
Most companies have more than one, created accidentally over years by different people. The relevant question is not whether the company is verified, but whether the specific portfolio the app is connected to is — and who holds Admin on it.
Establish who can actually complete it
Business Admin, not app admin. If that person has left, or the portfolio was created under a personal account, resolving ownership is the project and everything else waits on it.
Align the entity paperwork before submitting
Legal name, registered address, phone, website domain and the documents Meta accepts have to tell one consistent story. Mismatches between the entity on the certificate and the details typed into the form are the ordinary reason a submission comes back.
Decide early whether Tech Provider applies
If the product will be used by businesses other than your own and touches any of the listed permissions, Access Verification is not optional and it is a separate queue from App Review. Discovering it after launch means customers are already failing.
Sequence verification ahead of App Review, not alongside it
Advanced Access depends on a verified business. Submitting App Review while verification is unresolved produces a review outcome that cannot be acted on, and the calendar cost lands at the end of the build rather than the start.
Where business verification goes wrong
- Following instructions for an interface that no longer exists. Guides that say Business Manager → Business Settings describe a product Meta has retired; the same controls now sit in Meta Business Suite settings.
- The app is connected to the wrong portfolio. The company is verified. The portfolio holding the app is a different one, created years earlier, and is not.
- No reachable Business Admin. App admins cannot complete verification. Without a business admin the process cannot start.
- Document and entity details do not match. Trading name on the website, legal name on the certificate and the name typed into the form pointing at three slightly different organisations.
- Access Verification was never considered. Business Verification is completed, App Review passes, and external customers still cannot grant permissions because the business is not a verified Tech Provider.
- The error was debugged as a bug. Error code
100says nothing about verification, so engineering time goes into the endpoint instead of the account. - The 60-day window was missed. Existing businesses that were notified and did not act see calls gradually subjected to the verification check.
- Verified status was assumed permanent. Disconnecting an app from its business, or a restriction on the account, removes it — and takes external permission grants with it.
Where this sits
The rename is not the problem. The problem is that Meta operates two separate verification systems with overlapping names, run through an interface whose documentation is a generation behind, and both of them sit between a finished integration and a working one.
If that is the work that needs doing, it is described under the Meta Business Verification service, with scope and pricing set out separately. Where the app is used by other businesses and the Tech Provider layer applies as well, that is covered under Meta Tech Provider and Access Verification. Where verification is one step inside a wider permission submission, the Facebook App Review service covers the rest of the sequence.
An honest note. Meta reviews and decides every verification itself, and a business that meets the published requirements may still be asked for more information or be declined. No consultant controls that decision, and no specific outcome or timeline can be promised. What can be controlled is that the right portfolio is identified, that the entity details and documents are consistent before anything is submitted, that the correct person holds the role needed to complete it, and that the Tech Provider question is answered before customers depend on the answer. This is review preparation and submission support, and it is not affiliated with or endorsed by Meta.
Sources: Meta for Developers — Business Verification (developers.facebook.com/docs/development/release/business-verification), Access Verification (developers.facebook.com/docs/development/release/access-verification), the Developer Platform business verification announcement (developers.facebook.com/blog, 1 February 2023) and the Meta Business Help Centre. Reviewed August 2026 — Meta renames and re-scopes these processes regularly; verify against the current pages before acting.