Meta Marketing API
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.
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.
Standard Access
Own Accounts Only
✓Access to your own ad accounts
✓Development and internal testing
✗Cannot manage client ad accounts
✗Lower Marketing API rate limits
✗Not production-ready for client-facing tools
Advanced Access
Client Accounts — Requires App Review
✓Access to any user's ad accounts
✓Production-ready for client-facing tools
✓Higher Marketing API rate limits
!Requires App Review + Business Verification
!Per-permission use case justification required
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"
Effective May 4, 2026
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.
Old Requirement (pre-May 2026)
Minimum 1,500 Marketing API calls in the past 15 days. Error rate under 15% over a fixed time window. Screen recording submission required as part of the application.
New Requirement (May 2026+)
Minimum 500 Marketing API calls in the past 15 days. Error rate under 15% calculated over a rolling window of the last 500 calls. Screen recording no longer required. Progress now visible in App Dashboard under Permissions & Features.
What the Approval Process Actually Involves
Getting to Advanced Access for the Ads API 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.
1
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.
2
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.
3
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.
4
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.
5
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.
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 Ads API.
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.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.