Meta Ads API Rate Limits: How to Avoid Getting Throttled

You're mid-campaign. Budgets are being reallocated, new creatives are going live, and your reporting script is pulling fresh performance data. Then every call returns the same response: error 613. Nothing moves until someone figures out what happened.

Meta's Marketing API rate limits are behind more campaign disruptions than most teams realize. Here's a clear breakdown of how the system works and what to do when it pushes back.

In this post:

• How Meta's Business Use Case (BUC) scoring system works
• The three error codes that signal rate limit problems
• How to read the warning signs before you hit the wall
• Five strategies to stay under the limit at scale

How Meta's Rate Limiting System Works

Meta doesn't enforce a simple "X requests per hour" ceiling. The Marketing API uses a Business Use Case (BUC) scoring system — a dynamic, point-based quota that varies by operation type, app access tier, and ad account size.

Every ad account carries a separate BUC score, tracked independently for each use case category:

ads_management

ads_insights

custom_audience

catalog_management

ads_insights

ads_management

Your app's access tier determines the base quota. Standard Access apps get dramatically more headroom than Development Access apps:

The bonus quota matters. An account running 500 active ads gets 20,000 additional

ads_management

One more constraint sits above the BUC system: a hard cap of 100 POST requests per second, regardless of your score. Burst traffic that looks fine on an hourly basis can still trigger throttling if it's too concentrated in a single second.

The Error Codes That Signal Rate Limit Problems

Three error codes indicate rate limit issues. Each maps to a different layer of the throttling system.

Error 4 (subcodes 1504022 or 1504039): App-level throttling. The message is "There have been too many calls from this app." This affects every ad account the app manages — not just one. If you're using a shared integration that touches many accounts, a spike in one account can affect all of them.

Error 17 (subcode 1885172): Specific to spend limit changes. Triggered when spend limits are modified too frequently across accounts.

Error 613: The most common. "Calls to this API have exceeded the rate limit." Subcode 1487632 is a budget-change variant — Meta enforces a hard limit of 4 budget changes per ad set per hour. Hitting this repeatedly is a sign your automation is making redundant updates.

None of these errors flag your account for policy violations. They're temporary throttle signals. The problem is what happens downstream when your system doesn't handle them gracefully — calls silently fail, updates don't land, and campaigns drift from their intended state.

Reading the Warning Signs Before You Hit the Wall

Every Marketing API response includes an

X-Business-Use-Case-Usage

• call_count

  — percentage of your API calls consumed in the current window

• total_cputime

  — CPU time consumed as a percentage of the cap

• total_time

  — total time as a percentage of the cap

• estimated_time_to_regain_access

  — if you're already throttled, how long until you're unblocked

When

total_cputime

total_time

Most teams don't monitor this header at all. They discover they're throttled when campaigns stop updating — not from a proactive signal. Building monitoring around this header turns rate limits from a surprise failure into a predictable, manageable condition.

Five Strategies to Stay Under the Limit

1. Batch your requests. The Marketing API supports request batching — multiple operations bundled into a single HTTP call. Instead of 300 separate budget update calls, consolidate them into one batch request. Same outcome, fraction of the quota cost.

2. Use async for Insights pulls. The Ads Insights API supports asynchronous requests. For large historical data queries — performance across 50 campaigns over 90 days — async jobs let you retrieve the data without blocking your synchronous quota window. The job runs on Meta's side; you poll for completion.

3. Distribute traffic evenly across the hour. Rate limits reset hourly. If your system front-loads 80% of its calls in the first 10 minutes, you hit the ceiling before the window closes. A simple request queue with rate governance resolves this without changing what you're fetching.

4. Cache account structure. Campaign names, ad set hierarchies, and targeting configurations rarely change mid-flight. If your system re-fetches the full account tree before every operation, it's burning quota on stable data. Cache what doesn't change. Only poll for what does.

5. Implement exponential backoff with jitter. When you receive a 613, don't retry immediately. Wait, then retry with progressively longer intervals and a small random delay offset. This prevents retry storms — multiple processes hammering the same endpoint simultaneously, making recovery slower for everyone.

All five strategies together are a meaningful engineering investment. bulk implements them at the infrastructure level — batching is built in, backoff is automatic, account structure is cached from the first connection. You get quota-efficient API behavior without writing the plumbing yourself.

Meta's Marketing API best practices documentation covers async and batching patterns in detail, and the rate limiting reference documents BUC score calculations per use case.

Why This Gets Harder as You Scale

Single-account operators rarely hit rate limits in everyday work. The problem compounds when you're managing 10+ accounts, running automated performance checks, or routing campaign work through tools that call the Marketing API on your behalf.

Every tool connected to your ad account draws from the same BUC quota. A reporting platform, a bidding optimizer, and an automation agent hitting the same account simultaneously aren't each getting their own limit — they're all drawing from yours. Three tools running in parallel can exhaust quota that any one of them would handle alone.

This is where unauthorized API integrations create a second problem beyond policy risk. As covered in Meta API Bans: Why DIY MCP Setups Put You at Risk, unofficial tools often make redundant calls because they can't read the full account state from a position of trust. An authorized agent reads what it needs, caches what's stable, and batches changes — consuming less quota per operation than a tool that fetches fresh data on every call.

bulk manages the Marketing API layer for Meta campaigns — batching mutations, caching account structure, and handling retry logic automatically. Rate limit errors don't surface as campaign gaps; they're absorbed at the infrastructure level before they reach your workflows. That's the difference between an authorized agent built on Meta's official API and a patchwork of tools that each compete for your quota.

bulk handles the execution layer for Meta ads — including the API rate limit management that keeps automation reliable at scale. Try bulk free →