Facebook Ads API permission approval is where most ad-tech builds stall. Ad-tech founders and agency developers building programmatic ad management tools expect to request ads_management or ads_read and get building.
What they find instead is a two-gate approval system that has blocked more SaaS launches than almost any other Meta permission cluster. The permissions themselves are just the start.
The real gate is the Marketing API Access Tier — formerly "Ads Management Standard Access" — and the Advanced Access review that sits above it. Most apps stall not because the code is wrong, but because the App Review submission does not demonstrate what Meta actually needs to see.
The Two Permissions — What They Actually Cover
Most apps need both permissions. They are not interchangeable — and requesting the wrong one, or the wrong access level, results in a rejection or an approval that does not actually cover real client accounts in production.
In Meta's Permissions Reference, the Meta Marketing API ads_read permission gives your app the Ads Insights API for ad accounts you own or have been granted access to, and it also covers the Server-Side API for sending web events. The Meta Marketing API ads_management permission lets an app both read and manage those ad accounts: create campaigns, manage ads and fetch metrics. It lists pages_read_engagement and pages_show_list as dependencies, so plan them into the same submission.
ads_management
Create, update, pause, and delete ad campaigns, ad sets, and ads. Any write operation on ad objects requires this permission. Client account management requires Advanced Access — Standard Access only covers your own accounts.
ads_read
Read-only access to ad performance data, campaign statistics, and account insights. Reporting and analytics tools typically request this. Server-side ad tracking needs a dataset and a system user token before it will report, so see how to set up the Facebook Conversions API. Still subject to access-tier gating when accessing client accounts.
business_management
Required for apps that create ad accounts programmatically or manage Business Manager assets on behalf of clients. A common missed dependency that returns the entire submission at review.
pages_read_engagement
Required by apps that tie ad performance to organic Page data or need to select Facebook Pages as campaign destinations. Adds a second review scope that is frequently overlooked in initial submissions.
Standard Access vs Advanced Access — The Gate Most Apps Miss
Permissions alone do not determine what your app can access. The tier of access is a separate gate — and for any app managing ad accounts belonging to other businesses, Standard Access is not enough.
The difference between the two tiers is the difference between a testing environment and a shippable product. See also: what Meta Advanced Access actually requires, and the Meta Ads API approval overview for how all the gates fit together.
If your app is a reporting dashboard, ad scheduler, or any tool that connects to a client's Meta Business Manager — you need Advanced Access. Standard Access lets you test. It does not let you ship to paying customers.
The May 2026 Update: AMSA Is Now "Marketing API Access Tier"
Meta renamed the "Ads Management Standard Access" (AMSA) feature to "Marketing API Access Tier". The old name caused persistent confusion between the AMSA feature and the separate ads_management permission.
These are two entirely different approval mechanisms — one controls what operations the app can perform; the other controls the tier of access to Marketing API rate limits and Business Manager scope. Most guides published before May 2026 use the old name and describe outdated requirements.
What the Approval Process Actually Involves
Getting to Advanced Access for the Facebook Ads API permission is not a single form. It is a staged process where each stage can independently stall or return a rejection — and the stages have prerequisites that need to be resolved in sequence.
Meta Business Verification first — The app owner's Meta Business Manager must be verified with legal business documents before any Advanced Access submission can proceed. This prerequisite gate alone has stalled projects for weeks.
Reach the 500 API call threshold — For the Marketing API Access Tier feature, the app must demonstrate real API usage: minimum 500 Marketing API calls in the prior 15 days, with an error rate under 15%. These calls must use the specific permission being applied for.
Submit for Advanced Access with per-permission justification — Each permission requires a written explanation of exactly how the app uses it, who the users are, what client data is accessed, and how that data is handled. Generic one-line descriptions fail review consistently.
Working client account integration must be demonstrable — Meta's review team verifies a live, functional integration. For ads_management, that means the app must demonstrate the client account onboarding flow — not just the developer's own test ad account.
Annual Data Use Checkup after approval — Once approved, the app must complete Meta's annual recertification within a 60-day window. Missing this window disables API access until the checkup is completed. This is a separate, ongoing obligation that many teams only discover after their access unexpectedly stops working.
Before you submit, rehearse the exact flow Meta's reviewer will record. Sign in with a Business Manager user who has a role on a real client ad account, complete the login and the account selection screen, then make one read call and one write call with the same token your production system will use.
If the write call fails because the token lacks the scope, fix the scope before you record the screencast instead of explaining the failure in the use case text.
Keep the names consistent across every artifact. The test account, the Business Manager name, the campaign names, and the app name should match across the screencast, the written justification, and the app settings.
A mismatch between what the video shows and what the text claims is one of the quieter reasons a submission is sent back, and it is easy to avoid with one test script that you run and record the same way each time.
Write the justification in the same order the screencast shows the steps, so the reviewer can follow along without pausing the video.
Check the privacy policy and data handling statement last. Reviewers compare those documents with what the app actually stores. If your tool keeps campaign statistics or client account identifiers, the policy should say so in plain language, and the retention period should match what your system really does.
Aligning these documents with the code before you submit saves a round trip and keeps the focus on the permission request itself. Keep a signed-off copy of the final version with the submission notes, so the team can answer follow-up questions quickly.
Why Most Ads API Submissions Get Rejected
Generic use case description — "Our tool manages Facebook ads for clients" fails. Meta needs per-permission justification: which specific ad objects the app reads or writes, what the end user sees, how client data is protected. This is the single most common rejection cause across all Advanced Access submissions for the Facebook Ads API permission.
Integration only demonstrates own ad account access — For ads_management Advanced Access, Meta expects a working client account onboarding flow — the mechanism by which another business grants the app access to their ad data. An app that only touches the developer's own test accounts does not demonstrate the client-facing use case the permission exists for.
Submitting before Business Verification completes — A submission while Business Verification is still in progress is returned immediately. Verification can take days to weeks. Submitting without a fully verified Business Manager adds that entire wait on top of the App Review queue.
Confusing the feature with the permission — The Marketing API Access Tier feature and the ads_management permission are two separate approval paths. Clearing one does not clear the other. Teams that pass the Marketing API threshold but skip the Advanced Access App Review — or vice versa — remain partially blocked in production.
Missing dependency permissions in the submission — ads_management submissions frequently need business_management, pages_read_engagement, or additional permissions in the same package. An incomplete permission chain causes the entire submission to fail even when the primary justification is solid.
Also see: ads_read approved after every other permission passed (case study) · hire a Facebook API developer for your Ads API submission
Need Us to Get Your Meta App 100% Approved?
Stop losing weeks to repeated rejections. With 500+ apps approved, we handle your entire submission from start to finish. You get 100% Approval or a 100% Refund — and for your complete safety, you can hire us directly through Upwork or Fiverr Escrow (or use the WhatsApp / Calendar buttons in the header & footer).
Chat on WhatsAppFAQ
Does ads_management Advanced Access need Business Verification?
Yes. Meta's Business Help Center states that business verification is required to obtain Advanced Access for any permission, and every Facebook Ads API permission is included, from ads_management to ads_read.
You can build and test on your own ad accounts with Standard Access, but plan verification before submission so an approved review is not left waiting on the business portfolio.
Do I need business_management as well as ads_read and ads_management?
Only if your app manages Business Manager assets. Meta's Permissions Reference says business_management lets an app read and write with the Business Manager API, for example managing business assets such as ad accounts and claiming ad accounts.
If people simply connect ad accounts they already control, ads_read or ads_management is enough. Unshown extra permissions are a common rejection.
What does "ad account owner has not granted ads_management or ads_read permission" mean?
The access token you used does not carry ads_read or ads_management for that ad account. Usually the person never granted the scope at login, has no role on the ad account, or is not an app role user while the permission is still at Standard Access.
Re-authorise with the correct scope, confirm the account role, and request Advanced Access for real customers.
Meta Marketing API permissions ads_read ads_management: do I need both?
Only if your product both reports and makes changes. A read-only dashboard needs just the ads_read permission; a tool that creates, edits or pauses campaigns needs ads_management.
Request only what your screencast demonstrates, because a permission the video never uses is a common rejection reason.
Is the Meta Marketing API ads_management permission enough on its own?
It can be. Meta's allowed usage for ads_management includes fetching ad metrics, because the permission lets an app both read and manage the ad accounts it owns or has been granted access to.
Add ads_read when part of your product is read-only reporting, or when you send web events through the Server-Side API.
Meta makes all Marketing API App Review and permission approval decisions independently. This service provides submission preparation, use case documentation, and technical integration support — not guaranteed approval outcomes. Amandeep Singh is not affiliated with or officially endorsed by Meta Platforms, Inc.