Instagram API Rate Limits: Three Ceilings, Not One

Instagram API rate limits are three separate mechanisms, not one number. There is a publishing cap on media_publish, counted per account over a rolling 24 hours. There is a Graph API call budget derived from your account's impressions, counted per app-and-user pair. And there are per-endpoint caps on messaging and discovery that ignore both. They fire different error codes, run on different clocks, and only some of them are worth retrying.

All numbers below were verified against a mirror of Meta's documentation dated 3 August 2026, with file names and line numbers so you can check them.

Three limits, three windows, three error codes

Read the table as three independent taps. You can have room left in the publishing cap and still be throttled because the call budget is spent. Most guides pick one row, call it "the Instagram rate limit", and leave you debugging the wrong ceiling.

Note what the throttle codes do not tell you. 4 means the app's token hit its limit, 17 the user's, 32 a Pages API call, 613 a custom endpoint limit. None names the mechanism. The scope of the token does. Those codes are Meta-wide rather than Instagram-specific: the same set splits across Platform and Business Use Case limits on Facebook Pages.

The publishing cap: 25, 50 or 100?

The number everyone quotes and nobody sources. Here is what the documentation actually says.

Two numbers, fifty lines apart, in one document. The 100 sits under a heading that names the endpoint: "This limit is enforced on the POST /<IG_ID>/media_publish endpoint." The 50 sits in a bullet list attached to carousel containers. Meta reconciles neither.

So hardcode none of them. The page that gives you the contradiction is Meta's content publishing guide, and it also gives the resolution: "To check an Instagram professional account's current rate limit usage, query the GET /<IG_ID>/content_publishing_limit endpoint." That is the only answer that survives Meta editing the prose again. Our mirror lists the endpoint twice but omits its reference page, so confirm the response fields against a live call.

Two properties people still get wrong. A carousel counts as one post, however many images it holds. And the window is moving, not calendar: a burst published at 09:00 frees up at 09:00 the next day, not at midnight.

The call budget: derived from reach, not from you

The second ceiling is not a fixed allowance. Meta computes it:

Calls within 24 hours = 4800 * Number of Impressions

"Number of Impressions" is how many times content from that account entered someone's screen in the last 24 hours. The budget is per app and app-user pair, so each connected account carries its own: throughput is set by your customer's reach, not your infrastructure.

The consequence is uncomfortable and nobody writes it down: a freshly connected account has almost no budget, exactly when onboarding wants to load a content calendar. Meta documents a floor for Threads - "the minimum value for impressions is 10" - in the section immediately below the Instagram one. Instagram's carries no such note. That is not proof no floor exists; it means none is documented, so do not plan capacity as if there were.

Then the window. The formula says 24 hours. The header reference for call_count says "a whole number expressing the percentage of allowed calls made by your app over a rolling one hour period." An hourly percentage against a daily allowance, in one document. Which governs, we cannot tell you - and neither can anyone else.

The header is clear on two things: values are percentages from 0 to 100, not counters, and estimated_time_to_regain_access is in minutes - the only number that tells you how long to wait.

The third tier everyone forgets

Messaging and discovery ignore the call budget entirely. Their caps are documented per endpoint, with no header to watch:

• Send API - 100 calls/second per account for text, links, reactions and stickers; 10 calls/second for audio or video.
• Private Replies API - 100 calls/second for replies to Instagram Live comments, but 750 calls/hour for replies on posts and reels. Seconds in one branch, hours in the other.
• Conversations API - 2 calls/second per account.
• Business Discovery and Hashtag Search - carved out of Business Use Case limiting onto Platform Rate Limits: Calls within one hour = 200 * Number of Users, your app's daily active users.
• Creator Marketplace Discovery - 1,000 requests per user per hour, raised from 240 per Meta's changelog, plus an app-level 1000 * Number of Effective Users per hour.

Note the fourth bullet if you build hashtag or competitor tooling: those calls scale with your app's user base, not your customer's reach.

What one post actually costs you

The two ceilings count the same publish very differently. Take a ten-image carousel.

The publishing cap charges you 1. The call budget charges you 15 to 43.

The spread comes from polling. Our workflow checks container status on a 15s / 15s / 20s cadence with a ten-minute budget, so a fast image carousel resolves in two or three checks and a slow video walks toward thirty. Those are durable sleeps, not a held worker slot, but each check is still a Graph API call against the same budget.

One detail worth checking in your own code: we create carousel children in parallel, in a single Promise.all - ten container creates at once. Meta's best-practice list says to "spread out queries evenly to avoid traffic spikes." Parallel children are that spike, traded for latency. Know which trade you made.

Which rate-limit errors are safe to retry

That last row is a production decision, not a reading of the docs. In our retryability.util.ts, 2207042 sits in the non-retryable set with the comment: rolling 24h cap; no retry budget can beat it, so fail fast to ERROR instead of dwelling in RETRYING. A post parked in RETRYING against a 24-hour window dies anyway - later, and quietly, after the customer stopped watching.

The classifier keys on the subcode, checked before the top-level code, so whichever main code arrives alongside 2207042 does not change the outcome. Meta agrees: "when the limit has been reached, stop making API calls. Continuing to make calls will continue to increase your call count."

The broader classification problem is covered in social media API error handling; the cross-platform view lives in social media API rate limits.

What we do about it

Three ceilings, three clocks, no single place to read your state. On our side of the Instagram API, the parts that matter are unglamorous.

The publishing cap is classified as terminal, so a capped post fails immediately with a message you can show a customer instead of holding a slot for hours. Before building a container we check whether a previous attempt already published one, because Meta can return an error after succeeding and a blind rebuild posts twice. Container polling runs off-slot as durable sleeps, so a ten-minute wait on video processing does not occupy a worker.

Honest limits: we do not query content_publishing_limit before publishing and we do not forecast per-account headroom. If you need the room left before a burst, that call belongs in your scheduler.

And if you run one account and post twice a week, none of this matters - use the Graph API directly. The Instagram Graph API guide covers that path including queue design under the cap; the Instagram posting API walks through the container flow.

Frequently asked questions

How many posts can I publish per day through the Instagram API?

Meta's documentation gives two answers in one file: 100 API-published posts in a 24-hour moving period, and 50 published posts in a 24-hour period. The widely quoted 25 is not in the current docs at all. Hardcode none of them - query GET /<IG_ID>/content_publishing_limit for the account's real usage.

Is the Instagram publishing limit a calendar day or a rolling window?

Rolling. Meta calls it a "24-hour moving period". Capacity frees up 24 hours after each publish, not at midnight, so a burst sent at 09:00 unblocks at 09:00 the next day. Schedulers built on calendar days hit the cap on a day their counter shows empty.

Do carousels, Reels and Stories each count as one post?

Carousels are documented as one post, however many of the ten allowed items they hold. Reels and Stories are not settled by any sentence in the current documentation, so treat their behaviour as unverified and measure it on your own account.

What is the difference between error 4, 17, 32 and 613?

They differ by which token hit its ceiling: 4 the app's token, 17 the user's, 32 a Pages API request, 613 a custom limit on that endpoint. Subcode 1996 on a 613 means Meta saw an unusual change in request volume. None name the mechanism.

Should I retry a request that hit the publishing cap?

No. Subcode 2207042 is the rolling 24-hour cap and no retry budget outlasts it. Fail fast, surface it, let the scheduler move the post. Meta warns that calling after a limit is reached increases the time before calls succeed - retrying makes it worse.