On May 4, 2026 Meta renamed the App Review feature that controls Marketing API throughput. Ads Management Standard Access is now the Marketing API Access Tier feature, and its two levels — previously Standard Access and Advanced Access — are now Limited Access and Full Access. Almost every guide published before that date now uses names that no longer exist in the App Dashboard.
This is the tier that decides whether your app can actually serve live advertisers, or whether it stays throttled at development-grade quotas no matter how many permissions you already had approved. It is a separate gate from getting ads_management and ads_read approved, and conflating the two is the single most common reason a team believes it is approved while production still fails.
What actually changed on May 4, 2026
The feature was renamed
Ads Management Standard Access (AMSA) is now listed as “Marketing API Access Tier” in the App Dashboard. Meta’s own reason: developers kept confusing AMSA with the separate ads_management permission.
The tier labels changed
Standard Access became Limited Access. Advanced Access became Full Access. Apps that already held the upper tier keep it — the label simply changed in the UI.
The qualification bar dropped
The minimum call requirement was lowered from 1,500 to 500 Marketing API calls in the past 15 days, and the screen recording upload is no longer required for this feature.
The trap: Marketing API Access Tier is a feature, not a permission. Meta explicitly notes that platform-wide “standard access” and “advanced access” for permissions are not related to the Marketing API Access Tier’s Limited and Full levels. Two different axes, two different reviews, two different failure modes.
Limited Access vs Full Access: what is actually withheld
Limited Access is granted automatically the moment you add the Marketing API product to your app. Nothing is submitted, nothing is reviewed — and that is exactly why teams assume they are further along than they are.
Limited Access — the default
Heavily rate-limited per ad account. Meta describes it as development-only and explicitly not for production apps running for live advertisers. Limited access to Business Manager and Catalog APIs, with no Business Manager access to manage ad accounts, user permissions or Pages. One system user and one admin system user.
Full Access — after App Review
Lightly rate-limited per ad account. Access to all Business Manager and Catalog APIs. Ten system users plus one admin system user. Ad account management still depends on separately holding ads_read or ads_management from the ad account.
The throughput gap between the two is not incremental. If you want the exact per-hour formulas and the error codes each tier throws, they are broken down in the companion post on Meta Graph API rate limits, error codes and quota tiers. Note that Meta has not yet migrated every documentation page to the new labels — the Graph API rate-limiting reference still reads “Standard Access” and “Advanced Access” while describing the same numbers.
The qualification bar, precisely
Read those four numbers together, because the two windows are different and most restatements online merge them. The call volume is measured over a time window of 15 days. The error rate is measured over a rolling call-count window of your last 500 calls. An app can clear the volume bar and still fail on error rate, or vice versa, and the App Dashboard does not explain which one blocked you.
Where this actually goes wrong
The chicken-and-egg problem
You need 500 real Marketing API calls to qualify for the tier that lets you make Marketing API calls at production volume. Generating that traffic legitimately, from a working integration, without inflating the error rate, is a build-sequencing problem before it is a submission problem.
Error rate poisoned by development
Early integration work is exactly what produces malformed requests, expired tokens and bad object IDs. Those failures land in the same rolling window that decides eligibility. Teams routinely disqualify themselves during the build and never realise the counter is running.
Permission approved, tier still Limited
ads_management gets approved through App Review, the team celebrates, and production still throttles within minutes. The permission grants the right to call; the tier grants the capacity. Both have to be cleared, and they are requested in different places in the dashboard.
System user ceiling discovered late
Limited Access allows one system user and one admin system user. Agency and SaaS architectures that assumed a system user per client tenant hit an architectural wall that no amount of code can route around.
Stale documentation as a source
Because the rename is recent, most tutorials, Stack Overflow answers and vendor guides still instruct you to look for a feature name that is no longer in the dashboard. Following them costs days before anyone concludes the feature was removed — it was not, it was renamed.
What the tier does not change
Meta states this is not a breaking change: no code updates are required and existing access levels were preserved automatically. The underlying identifier is unchanged, and the ads_api_access_tier response header still reports the older values rather than the new labels. If you are debugging by header value, do not expect it to say “full”.
It also does not replace the permission review. A complete ads integration still has to pass the wider Meta Ads API approval chain — app configuration, the permission submission itself, business verification where applicable, and this throughput tier — and a failure at any one of them looks identical from the outside: calls that stop working.
What a correctly-sequenced submission looks like
The work is not filling in a form. It is arranging the integration so that by the time the tier is requested, the call history already demonstrates legitimate production-shaped usage, the error rate is clean over the measured window, the permission review and the tier request are not blocking each other, and the account and system-user architecture matches the tier being applied for. Getting that order wrong is what turns a short process into months of retries.
If your app is throttled, sitting on Limited Access, or you are unsure which of the two gates is actually blocking you, that diagnosis is the first thing to get right. I provide Meta App Review and API approval support covering submission preparation, policy-aligned documentation and the technical setup around it.
This article is informational and reflects Meta’s published documentation at the time of writing. Platform requirements change without notice — always confirm against the current official documentation. No specific outcome can be guaranteed.