Facebook API Rate Limit
How Meta’s Facebook Graph API rate limiting works, and how to avoid throttling in production.
By André LugFacebook Page publishing is governed by two budgets: an app-level limit of roughly 200 calls × active users per hour (reported on the X-App-Usage header) and a Page-level limit of roughly 4,800 calls × engaged users per rolling 24 hours (X-Page-Usage), plus a separate 30-Reels-per-Page-per-day cap. The Page-level budget usually bites first on low-engagement Pages.
Meta runs more than one rate-limiting system at once, and which one governs a given call depends on the token and endpoint, not a single global number. Publishing to a Facebook Page mostly falls under two of them: an app-level hourly limit, and a Page-level daily limit — plus a separate, much smaller cap specifically on Reels.
App-level: 200 calls per active user, per hour
200 × number of active users within a one-hour window, where "active users" is typically your app's unique daily (or weekly/monthly, for uneven usage) active user count. Usage is reported back on the X-App-Usage response header as three percentages — call count, CPU time, and total time — and you're throttled the moment any one hits 100%.Page-level: 4,800 calls per engaged user, per 24 hours
4,800 × engaged users in a rolling 24-hour window, where an engaged user is anyone who clicked on the Page or its content in that period. This is reported on X-Page-Usage, tracking the same three metrics. A low-engagement Page has a correspondingly small budget — this is usually the limit that bites first for a Page with a small audience, well before the app-level ceiling.What does throttling look like on the wire?
4 when the app hit its limit, 17 when the calling user did, and 32 ( "Page request limit reached") when it's the Page's own budget. PostGate normalizes all of these behind its own error.code — typically rate_limited or platform_transient — with retryable: true, so your client doesn't need to parse Meta's subcodes at all. See Errors & retries.{
"error": {
"code": "rate_limited",
"message": "Facebook is rate-limiting this Page.",
"platform": "facebook",
"retryable": true,
"request_id": "req_01JXYZ"
}
}Reels have their own, unrelated cap
How do you design around all of this?
retryable error, with exponential backoff and jitter, reusing the same Idempotency-Key so a retried request never doubles a post. Prefer webhooks over polling — a poll loop adds calls against the same budget you're trying not to exhaust. And when you control the schedule, spread a burst of posts for one Page across a wider window instead of firing them all in the same few minutes.Frequently asked questions
What is Facebook's app-level rate limit?
Meta’s documented formula for the app-level Platform Rate Limit is roughly 200 × number of active users within a one-hour window, where active users is typically your app’s unique daily (or weekly/monthly, for uneven usage) active user count. Usage is reported on the X-App-Usage response header as three percentages — call count, CPU time, and total time — and you are throttled the moment any one hits 100%.
What is the Facebook Page-level rate limit?
About 4,800 × engaged users in a rolling 24-hour window, where an engaged user is anyone who clicked on the Page or its content in that period. It is reported on X-Page-Usage, tracking the same three metrics as the app-level header. A low-engagement Page has a correspondingly small budget — this is usually the limit that bites first for a Page with a small audience.
What error codes does Meta return when you are rate limited?
Error subcode 4 when the app hit its limit, 17 when the calling user did, and 32 ("Page request limit reached") when it is the Page’s own budget. PostGate normalizes all of these behind its own error.code — typically rate_limited or platform_transient — with retryable: true, so your client doesn’t need to parse Meta’s subcodes at all.
How many Reels can I publish per day through the API?
Meta caps Reels specifically at 30 API-published Reels per connected Page within a rolling 24-hour period. It is a spam-prevention rule, not a percentage-of-budget one — it doesn’t show up in the usage headers and isn’t retryable the same way a throttle is.
How should I retry after a Facebook rate limit error?
Retry only on a retryable error, with exponential backoff and jitter, reusing the same Idempotency-Key so a retried request never doubles a post. Prefer webhooks over polling — a poll loop adds calls against the same budget you are trying not to exhaust — and when you control the schedule, spread a burst of posts for one Page across a wider window instead of firing them all in the same few minutes.
