# Facebook Graph API Rate Limits and Error Codes

Facebook Graph API rate limits explained: the 200 × users app formula, Page limits, X-App-Usage, error codes 4, 17, 32, 613, and 80001, and how to back off.

Canonical page: https://www.tryadeli.com/blog/facebook-graph-api-rate-limit
Last updated: 2026-10-26

By Mika Reyes, Co-founder, Adeli. Published 2026-10-26.

## The short answer

The Facebook Graph API has two kinds of rate limit. Platform limits cap an app at 200 calls per hour times its number of users. Business use case limits cover Pages, Marketing API, and Instagram calls; Pages calls made with a Page token get 4,800 × engaged users per 24 hours. Error codes 4, 17, 32, 613, and 80001 mean throttling, and the X-App-Usage and X-Business-Use-Case-Usage headers show how close you are.

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](https://www.tryadeli.com/blog/instagram-api-rate-limit). For the ad account scores, write caps, and budget-change limits on ads calls, see [Meta Marketing API rate limits](https://www.tryadeli.com/blog/meta-marketing-api-rate-limit). Every number below is from Meta's [rate limiting docs](https://developers.facebook.com/docs/graph-api/overview/rate-limiting) 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.

| Limit | Applies to | Meta's formula | Window |
|---|---|---|---|
| **Platform, app level** | Calls with an app access token | 200 × number of users | Rolling 1 hour |
| **Platform, user level** | Calls with a user access token | Not published | Rolling 1 hour |
| **Pages BUC** | Pages API calls with a Page or system user token | 4,800 × engaged users | Rolling 24 hours |
| **Ads Management BUC** | Marketing API management calls | 300 + 40 × active ads (Limited Access) | Per hour |
| **Ads Insights BUC** | Marketing API insights calls | 600 + 400 × active ads − 0.001 × user errors (Limited Access) | Per hour |
| **LeadGen BUC** | Lead retrieval | 4,800 × leads generated | Rolling 24 hours |
| **Messenger BUC** | Messenger Platform | 200 × engaged users | Rolling 24 hours |

**"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](https://developers.facebook.com/blog/post/2016/06/16/page-level-rate-limits/) 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](https://developers.facebook.com/docs/graph-api/guides/error-handling) 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.

| Code | Meaning | Limit type |
|---|---|---|
| **4** | The app whose token made the call hit its rate limit | Platform |
| **17** | The user whose token made the call hit their rate limit | Platform |
| **17** (subcode 2446079) | A v3.3 or older Ads API call hit its limit | Ads |
| **32** | The user or app in a Pages API request hit its limit ("Page request limit reached") | Pages, user or app token |
| **613** | A custom rate limit was reached | Platform |
| **613** (subcode 1996) | Meta noticed inconsistent request volume from your app | Platform |
| **80001** | Too many calls to this Page with a Page or system user token | Pages BUC |
| **80000** | Ads Insights limit | Marketing API BUC |
| **80004** | Ads Management limit | Marketing API BUC |
| **80003** | Custom Audience limit | Marketing API BUC |
| **80005** | LeadGen limit | BUC |
| **80006** | Messenger limit | BUC |

Source: Meta's [rate limiting docs](https://developers.facebook.com/docs/graph-api/overview/rate-limiting). Instagram's code, 80002, is covered in the [Instagram rate limit guide](https://www.tryadeli.com/blog/instagram-api-rate-limit).

**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`.

```json
{
  "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.

```javascript
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](https://developers.facebook.com/documentation/ads-commerce/marketing-api/overview/rate-limiting) 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](https://www.tryadeli.com/docs/api/ads) 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](https://www.tryadeli.com/product/facebook) 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](https://www.tryadeli.com/social-media-posting-api) endpoint as every other network, and read Page metrics and recent posts through the [analytics API](https://www.tryadeli.com/social-media-analytics-api).

It's built for [vertical SaaS](https://www.tryadeli.com/use-cases/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](https://www.tryadeli.com/pricing).

## Frequently asked questions

### Is the Facebook Graph API limit 200 calls per user per hour?

Not exactly. Meta's formula is 200 calls per hour multiplied by your app's number of users, pooled across the app. Meta says outright it is not a per-user limit, so one heavy user can use more than 200 calls. User tokens also have their own per-user limit, which Meta doesn't publish.

### How long does a Facebook Graph API rate limit last?

Platform limits use a rolling one-hour window, and Page limits a rolling 24-hour window, so there's no fixed reset time. For business use case limits, the X-Business-Use-Case-Usage header includes estimated_time_to_regain_access in minutes. Calls made while throttled still count, so retrying early delays recovery.

### Does the Facebook Graph API return HTTP 429 when rate limited?

Meta's rate limiting docs describe throttling by error code in the response body, not by HTTP status. Branch on error.code (4, 17, 32, 613, or a BUC code such as 80001) rather than waiting for a 429.

### Can I ask Meta to raise my Graph API rate limit?

For platform limits, the cap grows with your app's active users. For the Marketing API, moving from Limited Access to Full Access (formerly Standard and Advanced) raises the Ads Management and Ads Insights formulas. Meta's docs don't describe a request form for raising Page limits.

## Related Adeli pages

- [Facebook API for Developers](https://www.tryadeli.com/product/facebook.md): Publish, schedule, and read analytics for Facebook Pages through one API. Adeli owns the Facebook developer app, token refresh, and Meta review. Free to start.
- [Social Media Analytics API](https://www.tryadeli.com/social-media-analytics-api.md): Adeli's analytics API: Instagram, TikTok, Facebook Page, and YouTube insights endpoints, plus per-post engagement on every post an account has made.
- [All posts on the Adeli blog](https://www.tryadeli.com/blog.md)

## About the author

Mika Reyes is the CEO behind Adeli and a tech and AI content creator. She was previously co-founder and CEO of Parallax, which was acquired by Phantom, and a product lead at LinkedIn. She is a Forbes 30 Under 30 honoree.