Facebook Graph API Rate Limits and Error Codes

The Facebook Graph API rate limit depends on which token makes the call. Platform rate limits cap an app at 200 calls per hour × its number of users. Business use case (BUC) rate limits cover Pages, Marketing API, and Instagram calls, and a Page called with a Page token gets 4,800 calls per 24 hours × its engaged users. When you hit one, the response carries error code 4, 17, 32, 613, or 80001.

This guide covers Facebook Pages and the Marketing API. Instagram has its own formulas, covered in Instagram API rate limits. For the ad account scores, write caps, and budget-change limits on ads calls, see Meta Marketing API rate limits. Every number below is from Meta's rate limiting docs unless noted.

What is the Facebook Graph API rate limit?#

The Facebook Graph API applies platform rate limits to most calls and business use case (BUC) limits to Pages, Marketing API, and Instagram calls. If both could apply to a request, Meta applies the BUC limit.

"Number of users" means unique daily active users, or weekly and monthly actives for apps with slow days. "Engaged users" means people who engaged with the Page in the last 24 hours. A small Page with little engagement gets a small budget, which is why throttling often shows up first on test Pages.

How is the Facebook Graph API rate limit calculated?#

For platform limits, multiply 200 by your app's daily active users to get your hourly call budget. An app with 1,000 daily users can make 200,000 calls an hour across all of them. Meta says plainly that this is "not a per User limit": one user can use far more than 200 as long as the app stays under the pool.

For Pages called with a Page token, the budget belongs to the Page, not your app. Meta moved Pages to Page-level limits in 2016. Vivek Hamirwasia, announcing the change on Meta's developer blog in June 2016, put it this way:

"each Page has a dedicated quota that is shared across all apps using the Page's access token."

For a platform that connects customers' Pages, that has two effects. One customer's busy Page can't drain another customer's budget. But a customer who also runs other tools on the same Page shares that Page's quota with them.

Which token you use decides which limit you hit. Pages calls made with a user or app token fall under platform limits instead. If you see code 32 on Page reads, check whether you're calling with a user token by mistake.

What does "Application request limit reached" mean?#

"Application request limit reached" means your app has hit its platform rate limit, and every call your app makes will fail until usage drops below the threshold. Developers see it as (#4) Application request limit reached with error code 4. Meta's error handling guide lists code 4 as "API Too Many Calls."

Common causes:

• A burst. A backfill, cache rebuild, or cron job that fires many calls at the top of the hour.
• Polling. Checking for new comments or posts on a timer instead of using webhooks.
• App tokens on Page data. Calls that should use Page tokens (and the Page's own budget) running against your app's shared pool instead.
• Few active users. A new app with a small user count has a small platform budget, so a test script can exhaust it.

A related message, code 341 "Application limit reached", is listed in Meta's error guide as downtime or throttling. Treat it the same way: stop, wait, and check volume.

What do Facebook Graph API rate limit error codes mean?#

The error.code in the response body tells you which limit you hit. Meta's rate limiting docs don't describe an HTTP 429 for these, so branch on the code.

Source: Meta's rate limiting docs. Instagram's code, 80002, is covered in the Instagram rate limit guide.

Subcode 1996 is the one bursty apps trip. It isn't about total volume. Meta saw irregular spikes from your app, so the fix is to spread calls out evenly.

How do I check my Facebook Graph API usage?#

Read the X-App-Usage header for platform limits and X-Business-Use-Case-Usage for Page and Marketing API limits. Both arrive on normal responses, so you can slow down before you're throttled.

• X-App-Usage: call_count, total_cputime, and total_time, each a whole-number percentage of your app's limit over a rolling hour. At 100 for any of them, calls may be throttled.
• X-Business-Use-Case-Usage: a JSON object keyed by business object ID (the Page or ad account ID). Each entry has type (pages, ads_management, ads_insights, custom_audience, leadgen, messenger, or instagram), call_count, total_cputime, total_time, and estimated_time_to_regain_access in minutes. One response can hold up to 32 entries.
• X-Ad-Account-Usage: on older Ads API calls (v3.3 and earlier), with acc_id_util_pct, reset_time_duration in seconds, and ads_api_access_tier.

{
  "1234567890": [
    {
      "type": "pages",
      "call_count": 87,
      "total_cputime": 12,
      "total_time": 15,
      "estimated_time_to_regain_access": 0
    }
  ]
}

An estimated_time_to_regain_access of 0 means you aren't blocked right now, even if you're close to the cap. At 87% call_count, slow that Page down even though the estimate is 0.

How should I handle Facebook Graph API rate limits?#

Stop calling as soon as you're throttled, and back off per Page or ad account, not across your whole app. Meta's docs say calls made while throttled keep raising your count, so a tight retry loop extends the block.

1. Branch on the error code. Treat 4, 17, 32, 613, and the 8000x codes as throttles. Pause the scope they name: the app for 4, the user for 17, the Page for 32 and 80001.
2. Use Meta's wait time. For BUC limits, back off for estimated_time_to_regain_access minutes.
3. Slow down early. Watch call_count and add delay as it climbs, well before 100.
4. Spread calls evenly. Meta recommends avoiding spikes, which also keeps you clear of subcode 1996.
5. Ask for less. Use fields to request only what you show, and avoid calls that fetch overlapping data.
6. Use webhooks for comments, feed changes, and leads, so you aren't spending calls to learn nothing changed.

const THROTTLE_CODES = new Set([4, 17, 32, 613, 80000, 80001, 80003, 80004, 80005, 80006]);
 
function backoffMinutes(response, body) {
  const code = body?.error?.code;
  if (!THROTTLE_CODES.has(code)) return 0;
 
  const usage = JSON.parse(response.headers.get("x-business-use-case-usage") ?? "{}");
  const waits = Object.values(usage)
    .flat()
    .map((entry) => entry.estimated_time_to_regain_access ?? 0);
  return Math.max(5, ...waits); // our default floor, not a Meta number
}

The 5-minute floor is our own default for platform limits, which don't return a wait estimate. Tune it to your traffic.

How do Marketing API rate limits differ?#

Marketing API limits are business use case limits counted per ad account, and they scale with active ads. At Limited Access (Meta's name for the former Standard tier since May 2026), Ads Management allows 300 + 40 × active ads per hour. Full Access raises the base to 100,000 for Ads Management and 190,000 for Ads Insights.

Meta's advice for ads integrations differs slightly from Pages: if one ad account is throttled, work on other ad accounts and come back later, and prefer creating a new ad over repeatedly editing existing ones. The Marketing API rate limiting page adds a scoring model counted per ad account: a read costs 1 point and a write 3, and hitting the maximum score triggers a throttling error.

When we built Adeli's Meta Ads endpoints, the documented contract was to pass that throttle through clearly. Adeli's Ads API returns 429 rate_limited with a Retry-After header and structured limit details when Meta throttles a request, so your code reads one status instead of a dozen error codes.

Where does Adeli fit?#

Meta's limits still apply when you call Facebook through Adeli. What Adeli removes is the setup around them. Adeli holds the Meta developer app, carried Meta's review, and refreshes every connected Page's tokens, so you hold one API key. You can publish to Facebook Pages from the same posting API endpoint as every other network, and read Page metrics and recent posts through the analytics API.

It's built for vertical SaaS and marketing platforms where each customer connects their own Page. Adeli bills per profile (one of your customers), with every platform included. See pricing.