The Instagram API Rate Limit Is 4800 Times Your Impressions

What is the Instagram API rate limit?

One formula defines the Instagram API rate limit, and Meta prints it as a single line on both the Graph API rate limiting reference and the Instagram Platform overview: Calls within 24 hours = 4800 * Number of Impressions.

The sentence around it matters as much as the formula. Meta writes: "Calls to the Instagram Platform endpoints, excluding messaging, are counted against the calling app's call count. An app's call count is unique for each app and app user pair, and is the number of calls the app has made in a rolling 24 hour window."

Three constraints hide in that sentence. The count belongs to the app, not the account. It is scoped to one app and one app user together, so a busy client cannot starve a quiet one. And the window rolls, so nothing resets at midnight. Calls age out one by one, 24 hours after each was made.

Instagram Platform sits inside Meta's Business Use Case category rather than the older Platform Rate Limits category. Marketing API and Instagram requests are subject to Business Use Case limits; plain Graph API requests are subject to Platform limits. Where both could apply, Meta resolves it in one line: "If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied."

What does the 4800 multiplier apply to?

Impressions, and Meta defines the word narrowly: "The Number of Impressions is the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours."

Read that as a screen count, not a follower count, not a post count and not a reach count. It counts appearances, so one person scrolling past four of your posts contributes four. It covers "any content" from the account, so old posts pulling traffic count the same as this morning's. And it is measured over the same rolling 24 hours as the calls it funds, which makes the allowance move continuously rather than in steps.

That produces a budget that scales with attention. An account whose posts entered screens 50,000 times in the past day funds 240,000,000 calls, a number no publishing workflow approaches. The formula only bites at the bottom end, because Meta publishes no floor: 4800 multiplied by zero impressions is zero calls, and nowhere in the rate limiting reference does Meta state a minimum allowance for an account nobody has seen.

The same structure appears elsewhere in Meta's table. Pages API calls made with a Page or system user token use Calls within 24 hours = 4800 * Number of Engaged Users, and LeadGen uses Calls within 24 hours = 4800 * Leads Generated. The 4800 multiplier is Meta's house number for a 24 hour business use case; only the thing being multiplied changes.

How do you read the X-Business-Use-Case-Usage header?

Meta returns usage in a response header rather than in the body: "All API responses made by your app that are rate limited using the BUC logic include an X-Business-Use-Case-Usage HTTP header with a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call."

The header value is a JSON object keyed by business ID, and each entry carries these fields.

Field	What Meta says it holds
business-id	The ID of the business associated with the token making the API calls
call_count	A whole number expressing the percentage of allowed calls made by your app
total_cputime	A whole number expressing the percentage of CPU time allotted for query processing
total_time	A whole number expressing the percentage of total time allotted for query processing
estimated_time_to_regain_access	Time, in minutes, until calls will not longer be throttled
type	Type of rate limit applied, one of ads_insights, ads_management, custom_audience, instagram, leadgen, messenger or pages

For Instagram work the field to match on is type, and the value to match is instagram. An app that also touches Pages or Ads gets several objects back in the same header, and reading the wrong one tells you about the wrong budget.

Every one of the three usage numbers is a percentage, not a count. call_count at 62 means 62 percent of the allowance is spent, and Meta never tells you the denominator, because the denominator is that impressions figure recalculated continuously. No endpoint returns your current call ceiling as an integer.

The header does not appear on every response either. Meta's wording is that real time usage statistics are "included with most API responses once enough calls have been made to an endpoint." Treat a missing header as no information rather than as zero usage.

Why does the header say one hour when the formula says 24 hours?

Because Meta's two pages disagree, and the disagreement is live on the same document. The Instagram section states a "rolling 24 hour window." The header table, a few screens below it, defines call_count as "A whole number expressing the percentage of allowed calls made by your app over a rolling one hour period."

Both sentences describe the same field on the same header for the same API. One of them is wrong for Instagram. The one hour phrasing matches the Platform Rate Limits section higher up the page, where app level calls really are measured hourly, which is the likeliest origin of the mismatch.

Nothing in the docs resolves it, so plan for the longer window. If you assume the counter clears in an hour and it actually clears in 24, you retry into a wall. If you assume 24 and it clears in one, you waited longer than you needed to. Only one of those two mistakes breaks a publishing schedule.

A second published gap sits in the error tables. Meta's Business Use Case error list names error code 80002 for the Instagram type, with no subcode. The Instagram Platform error codes reference, the page you would actually read while debugging a publish, does not list 80002 anywhere. Map it yourself.

What happens when call_count reaches 100?

Requests fail with a dedicated error code. Meta writes: "When your app reaches its Business Use Case rate limit, subsequent requests made by your app will fail and the API will respond with an error code." For the Instagram type that code is 80002.

CPU and wall clock time throttle separately from call volume. Meta repeats the same two lines under every business use case: "When total_cputime reaches 100, calls may be throttled" and "When total_time reaches 100, calls may be throttled." Any one of the three hitting 100 is enough. A small number of heavy queries can exhaust total_cputime while call_count is still in single digits.

Once you are throttled, estimated_time_to_regain_access carries the wait in minutes, and the instruction that follows is the important one: "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."

Retrying makes the block longer. That is unusual enough to be worth designing around, because a default exponential backoff still sends requests, and every one of them extends the penalty. The correct behaviour on 80002 is to park the queue until the header says otherwise. The same discipline pays off on the daily publishing quota, which is a separate ceiling with its own error.

Meta's remaining advice is spacing rather than volume: "Spread out queries evenly to avoid traffic spikes" and "Use filters to limit the data response size and avoid calls that request overlapping data." There is also a counting rule that catches people batching IDs. Meta states that "each ID counts as one API call", and demonstrates it: three separate single ID requests count as three calls, and one request with ids=4,5,6 also counts as three.

Two responses to error 80002

Stop the queue

• call_count stops climbing
• estimated_time_to_regain_access counts down
• calls succeed again once the wait ends

Keep retrying

• each retry raises call_count further
• estimated_time_to_regain_access grows
• the wait before calls succeed again gets longer

Which Instagram endpoints sit outside this limit?

Two families, and Meta names them explicitly.

Surface	Limit that applies
Publishing, media, insights, comments	4800 * Number of Impressions per 24 hours
Business Discovery, Hashtag Search	Platform Rate Limits, not Business Use Case
Conversations API	2 calls per second per professional account
Send API, text and links	100 calls per second per professional account
Send API, audio or video	10 calls per second per professional account
Private Replies, Live comments	100 calls per second per professional account
Private Replies, posts and reels	750 calls per hour per professional account

Messaging is carved out of the impressions formula completely and runs on per second and per hour ceilings instead. Business Discovery and Hashtag Search fall back to Platform Rate Limits, where the app level formula is Calls within one hour = 200 * Number of Users.

The rate limit is also not the publishing quota. They are separate systems with separate errors, and confusing them wastes debugging time: a publish blocked by volume returns 80002, while a publish blocked by the content publishing quota returns code 9, subcode 2207042. Other networks split the same way, whether that is the request ceilings Bluesky publishes per endpoint or the daily unit budget YouTube meters and lets you apply to raise.

Frequently asked questions

What is the Instagram API rate limit formula?

Calls within 24 hours = 4800 * Number of Impressions. Meta publishes it on the Graph API rate limiting reference and repeats it on the Instagram Platform overview.

What counts as an impression in the Instagram rate limit?

Meta defines it as "the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours." It counts appearances of any content, not followers and not posts.

Which error code means the Instagram API rate limit was hit?

Error code 80002. Meta lists it against the Instagram business use case type with no subcode, and does not repeat it in the Instagram Platform error codes reference.

How do you check current Instagram API rate limit usage?

Read the X-Business-Use-Case-Usage response header, find the object where type is instagram, and check call_count, total_cputime and total_time. All three are percentages of the allowance.

Does retrying after a rate limit error make it worse?

Yes. Meta writes that continuing to make calls "will continue to increase your call count, which will increase the time before calls will be successful again." Stop the queue and read estimated_time_to_regain_access.

Are Instagram messaging endpoints covered by the 4800 formula?

No. Meta excludes messaging from the impressions formula and publishes per second and per hour ceilings for the Conversations, Send and Private Replies APIs instead.

Does the Instagram API rate limit reset at a fixed time each day?

It doesn't reset at midnight or any other fixed time. Meta counts calls in a rolling 24 hour window, so each call ages out and drops off the count exactly 24 hours after it was made. The allowance is always in motion rather than snapping back to zero on a schedule.

Is the Instagram API call count shared across every app connected to my account?

Each app keeps its own count. Meta scopes it to one app and one app user pair together, so a busy app cannot burn through the allowance belonging to a different app touching the same account.

How is the Instagram API rate limit different from the daily publishing quota?

They are separate systems with separate errors. The rate limit tracked here blocks with error code 80002 when call_count, total_cputime or total_time hits 100. The daily publishing quota is a different ceiling entirely, and it fails with code 9, subcode 2207042, so a block from one never explains a block from the other.

Do Business Discovery and Hashtag Search calls count toward the 4800 formula?

They fall outside it. Both endpoints run under Meta's older Platform Rate Limits category instead of Business Use Case, where the governing formula is 200 times the number of users per hour rather than 4800 times impressions.