How the Meta business use case rate limit Meters Facebook Pages

What is the Meta business use case rate limit for Pages?

The Meta business use case rate limit for Pages is the 24 hour call budget Meta applies to Pages API requests made with a Page access token or a system user access token. Meta's Graph API rate limiting reference gives the formula in one line:

Calls within 24 hours = 4800 * Number of Engaged Users

The sentence above the formula sets the terms: "Requests made by your app to the Pages API using a Page access token or system User access token are counted against the app's call count. An app's call count is the number of calls it can make during a rolling 24 hour window."

So the budget belongs to the app, the window rolls rather than resetting at midnight, and the size of the budget moves with how many people engaged with the Page over the last day. A Page with 50 engaged users funds 240,000 calls in 24 hours. A Page with no engaged users funds zero, by the same arithmetic.

Business use case, which Meta abbreviates BUC, is one of two rate limiting systems Meta runs. The other is Platform Rate Limits, the app-level and user-level system that the x-app-usage header reports on. Pages is where Meta splits the two by token.

Which tokens put Pages calls under the business use case limit?

The access token decides it, and nothing else. Meta states the split at the top of the rate limiting reference: "requests made with application or user access tokens are subject to Platform Rate Limits, while requests made with system user or page access tokens are subject to Business Use Case Rate Limits."

The same call to POST /{page-id}/feed lands in a different system depending on which credential your app sends. Publishing runs on Page tokens, because the Page Feed reference requires "A Page access token" to post as the Page, and a Page access token derived from a long-lived user token has no expiry date. Those calls sit under business use case limits.

Meta also recommends the business use case route for reading public Pages. The Page Feed and Page Photos references both say: "When using the Page Public Content Access feature, use a system user access token to avoid rate limiting issues." Meta gives no reason, but the effect is plain: a system user token moves those reads off the hourly Platform budget and onto the 24 hour business use case one.

Where both systems could apply, Meta settles it: "If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied."

What counts as an engaged user for the Pages limit?

Meta's whole definition is one sentence: "The Number of Engaged Users is the number of Users who engaged with the Page per 24 hours." It names no qualifying action. Likes, comments, shares and clicks go unmentioned.

The same page then reuses the term with a different meaning. In the Messenger section, the formula is Calls within 24 hours = 200 * Number of Engaged Users, and Meta defines it differently: "The Number of Engaged Users is the number of people the business can message via Messenger." Two formulas on one document use the same term for two different populations, with multipliers of 4800 and 200.

There is also no floor. The Threads section of the same reference sets one explicitly: "The minimum value for impressions is 10 (so if the impressions is less than 10 we default to 10)." The Pages section has no equivalent line. A brand new Page, or a dormant one, has a formula that multiplies 4800 by a number close to zero.

The formula also leaves one question open. It sizes the budget from one Page's engagement, but it charges calls to "the app's call count". Meta does not say whether two Pages connected to the same app draw from two budgets or one. The header, covered next, keys usage by an ID that Meta's field table describes as "The ID of the business associated with the token making the API calls". That is a business, not a Page, and the prose never says how a Page's budget maps onto it.

How do you read X-Business-Use-Case-Usage for Pages calls?

Meta attaches this header to responses under business use case logic and describes it as "a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call." Entries are keyed by business object ID, and each entry's type names the limit it reports. For Pages calls, the value to match is pages.

Meta's sample shows a Pages entry like this:

"10153848260347724": [
  {
    "type": "pages",
    "call_count": 97,
    "total_cputime": 23,
    "total_time": 23,
    "estimated_time_to_regain_access": 0
  }
]

Two problems sit inside Meta's own example. First, the key 10153848260347724 appears twice in the sample, once holding an ads_insights entry and once holding the pages entry. JSON does not forbid that, but RFC 8259 warns against it: "The names within an object SHOULD be unique," and when they are not, "the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only." JSON.parse in JavaScript keeps the last one. If the real header ever repeats a key the way the sample does, a standard parser silently drops one of the two entries, so iterate every entry and filter on type rather than looking up a single key.

Second, call_count is defined over "a rolling one hour period" while the Pages formula counts calls over "a rolling 24 hour window". The Instagram section of the same document has the identical mismatch. Meta does not say which window the Pages percentage uses. Plan around the 24 hour window, since that is the one in the Pages formula.

The best practices under this header were written for ads, down to "Switch to other ad accounts and come back to this account later." None of them mentions Pages.

What happens when a Page hits its business use case limit?

Calls fail with error 80001. Meta's sample response:

{
  "error": {
    "message": "(#80001) There have been too many calls to this Page account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.",
    "type": "OAuthException",
    "code": 80001,
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"
  }
}

The Page Photos and Page Post references carry the same text for 80001 in their own error tables, so this is the code a publishing or reading job actually sees.

The message says "Wait a bit and try again." The best practices section on the same page says something stricter: "When the limit has been reached, stop making API calls. Continuing to make calls will continue to increase your call count, which will increase the time before calls will be successful again." Follow the second one. Read estimated_time_to_regain_access from the pages entry, park that Page's queue for that many minutes, and do not probe with test calls in between.

Meta's error table for business use case limits has a slip worth flagging. It lists "error code 32" against "Page calls made with a User access token", in a table about business use case limits, while the same document says user token calls on Pages follow Platform logic. The Platform table is the accurate one: code 32 "Indicates that the User or app whose token is being used in the Pages API request has reached its rate limit." Treat 32 as a Platform error and 80001 as the business use case error, and route them to different recovery paths.

None of this covers how many posts a Page may publish. Facebook's daily posting limits are a separate system with separate failures.

How is the business use case limit different from the app-level limit?

Almost every property differs, including the unit of time. The multipliers are closer than they look: 200 calls an hour for 24 hours is 4800 calls a day, so both formulas grant the same daily rate per counted person. What differs is who gets counted.

A scheduling tool with few daily active users but busy client Pages gets far more room from Page tokens than from app tokens. A popular app pointed at quiet Pages gets the reverse.

The 4800 multiplier is not unique to Pages. Meta uses the same number for Instagram, where it multiplies impressions instead of engaged users, and the Instagram version of this formula has its own header quirks. Only the Pages version depends on which token you send.

Frequently asked questions

What is the formula for the Meta business use case rate limit on Pages?

Calls within 24 hours = 4800 * Number of Engaged Users, where Meta defines engaged users as "the number of Users who engaged with the Page per 24 hours." It applies to Pages API calls made with a Page or system user access token.

Which error code means a Page hit its business use case rate limit?

Error 80001, with the message "There have been too many calls to this Page account. Wait a bit and try again." Error 32 is the Platform Rate Limits code for Pages API calls made with a user or app token.

Does a user access token use the business use case rate limit on Pages?

No. Meta routes Pages API calls made with application or user access tokens to Platform Rate Limits. A user token's calls count against that user's own hourly call count, which Meta does not disclose, and an app token's calls count against the app's hourly budget of 200 * Number of Users. Only Page and system user tokens use the business use case limit.

How long do I wait after error 80001?

Read estimated_time_to_regain_access in the pages entry of the X-Business-Use-Case-Usage header. Meta defines it as the time, in minutes, until calls stop being throttled. Make no calls on that Page until then, since Meta says further calls extend the block.

What does engaged users mean in Meta's Pages rate limit?

Meta says only that it is the number of users who engaged with the Page per 24 hours, and lists no qualifying actions. The same rate limiting page uses "Engaged Users" for Messenger with a different definition, the number of people the business can message.

Why does Meta recommend a system user token for Page Public Content Access?

The Page Feed and Page Photos references tell apps using Page Public Content Access to use a system user access token "to avoid rate limiting issues." A system user token moves those reads from the hourly Platform budget to the 24 hour business use case budget.

What is the difference between error 80001 and error 32 on Pages calls?

Error 80001 is the business use case error for Page and system user tokens, with the message "There have been too many calls to this Page account". Error 32 is a Platform Rate Limits code for Pages API calls made with a user or app token. Meta's business use case error table lists 32 against user token calls, which contradicts the rest of the document. Treat 32 as a Platform error and route the two to different recovery paths.

How many calls does a Facebook Page with 50 engaged users get in 24 hours?

The Page funds 240,000 calls, which is 4800 multiplied by 50, over a rolling 24 hour window. A Page with no engaged users funds zero by the same arithmetic. The Pages section sets no minimum, unlike the Threads section, which defaults impressions to 10.

Do two Pages connected to the same app share one rate limit budget?

Meta does not say. The formula sizes the budget from one Page's engagement, but it charges calls to the app's call count. The X-Business-Use-Case-Usage header keys usage by the ID of the business associated with the token, not by Page, so read every entry instead of assuming a separate budget per Page.

Does the business use case rate limit cap how many posts a Page can publish?

It caps API calls, not posts. Facebook's daily posting limits are a separate system with separate failures. Publishing calls to POST /{page-id}/feed still count against the call budget, because they run on Page tokens.