Instagram API rate limit: Meta's quotas and usage headers

The Instagram API rate limit you're most likely to hit is the per-account publishing quota: Meta's own sample code puts it at 100, 50 or 25 API-published posts in 24 hours, depending on which file you read, and tells apps to check content_publishing_limit instead of trusting a number. Separately, every call counts against a usage budget that Meta reports back in the X-App-Usage or X-Business-Use-Case-Usage response header.

This reference is part of Meta API use cases: which one your app needs. It uses only what Meta publishes on GitHub (Postman collections, sample apps and SDK source) and the Meta entries in our API changelog. Meta's general rate-limit formulas live on Meta's developer site, which we don't read for these guides, so this page says plainly where its sources stop.

What this means for you

Two separate limits apply to a scheduling tool on Meta's platforms:

• A quota per account or profile. Instagram counts API-published posts per professional account. Threads counts posts, replies, deletions and location searches per profile. Both have an endpoint that tells you where you stand.
• A call budget for your app. Every request counts, including the status checks and insights reads around a post. Meta returns your usage in a response header on each call.

A tool that posts a few times a day for each client stays well under every posting quota Meta's samples quote. A tool that bulk-imports a content calendar, polls for comments or retries failed posts in a loop can meet both, and when it does, posts stop going out.

The details: how the Instagram API rate limit works

The limits in Meta's sources

Instagram content publishing limit: 100, 50 or 25 a day?

Meta's own files give three different caps:

• The publishing guide in Meta's Instagram Postman collection says "Instagram accounts are limited to 100 API-published posts within a 24-hour moving period". It adds that carousels count as a single post and that the limit is enforced on POST /media_publish.
• The carousel request in the same collection says "Accounts are limited to 50 published posts within a 24-hour period."
• Meta's Reels publishing sample, written for its version 2.0.0 in February 2023, says 25.

The 100 and the 50 were added in the same commit on September 10, 2025, so the newer files still disagree with each other. The Instagram Content Publishing API guide sets out the three side by side. The guide also asks apps to "enforce the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future", which is every scheduler.

Reading content_publishing_limit

Ask each account for its quota rather than picking one of the three numbers:

GET /{ig-user-id}/content_publishing_limit?fields=config,quota_usage

Meta's Reels sample reads config.quota_total and quota_usage from the first item in data and subtracts one from the other to show "Publishes remaining". The Python Business SDK has this call on both Instagram user classes, with the fields config and quota_usage and an optional since date. Both login paths have it, so it works whichever login your app uses (Instagram Login or Facebook Login).

Checking costs calls too. Meta's publishing guide recommends querying a container's status "once per minute, for no more than 5 minutes", which is a useful ceiling for the polling loop around each post.

Threads API rate limit: threads_publishing_limit

Threads has its own quota call:

GET /me/threads_publishing_limit?fields=quota_usage,config,reply_quota_usage,reply_config,delete_quota_usage,delete_config,location_search_quota_usage,location_search_config

That field list is the one Meta's Postman collection and its Threads sample app both request. Each *_config holds a quota_total and a quota_duration. Meta's example response shows quota_total 250 for posts and 1,000 for replies, both with quota_duration 86,400 seconds, which is 24 hours.

The delete and location search quotas were added on July 14, 2025, and Meta's example response doesn't show a figure for either. The collection itself sends readers to Meta's online documentation for "the most accurate and up-to-date details" on Threads limits. For the rest of the Threads flow, see Threads API publishing.

The X-App-Usage header

Meta's collections include example responses with their headers, which show what the usage headers look like. Sixteen example responses in the Instagram API with Instagram Login folder carry it, all with the same value:

x-app-usage: {"call_volume":0,"cpu_time":0}

The Messenger collection's examples, which call graph.facebook.com, show the same header with different keys:

x-app-usage: {"call_count":0,"total_cputime":0,"total_time":2}

So the key names depend on which API answered. Parse the header as JSON and log every key you get, rather than expecting one shape. Meta's GitHub sources don't say what unit the values are in, what value triggers throttling, or how long the window is.

The X-Business-Use-Case-Usage header

47 of the Messenger collection's example responses return a second header instead:

x-business-use-case-usage: {"106259855420533":[{"type":"messenger","call_count":1,"total_cputime":1,"total_time":1,"estimated_time_to_regain_access":0}]}

The top-level key is an object ID; in the persistent menu examples it's the Page ID from the request path. Each entry has a type, and the examples show three: messenger, pages (on the webhook subscription calls and some persistent menu calls) and messenger_utility_messages. The field to watch is estimated_time_to_regain_access. Its name suggests the wait before calls work again, but it's 0 in every example and Meta's samples don't give its unit.

In Meta's examples, the Instagram Login calls return only X-App-Usage, and the Instagram calls through Facebook Login show no usage header at all. The collections don't say whether that's how Instagram always behaves or just what these examples captured. They also don't say which header wins when both appear on the same response.

Error codes when you're throttled

Meta's GitHub sources name two rate-limit error codes:

Meta's WhatsApp tech provider sample treats code 4, or subcode 2388093, as rate limited and answers its own front end with HTTP 429 and "Too many requests. Please wait and try again." That 429 is the sample's own response to its users; the sources don't show what HTTP status the Graph API itself returns.

Third-party guides also list codes 17, 32, 613 and 80000-series codes for business use case limits. None of them appears in the Meta GitHub sources we read, so we don't describe them. Meta's Instagram publishing guide points to an error codes reference without listing codes.

What Meta's SDKs do with limits

Neither of Meta's Business SDKs throttles for you. Both give you what you need to do it yourself:

• Python: FacebookResponse.headers() returns the response headers, and a FacebookRequestError exposes http_headers(), api_error_code(), api_error_subcode() and api_transient_error(), which reads Meta's is_transient flag. The SDK's own video uploader waits one second and retries when an error is marked transient.
• Node.js: api.setShowHeader(true) adds the response headers to each result under headers, and FacebookRequestError carries headers too.
• Batches: the Python README warns that "a batch call simply improves network performance and each call does count individually towards rate limiting."

Neither SDK reads X-App-Usage or X-Business-Use-Case-Usage itself.

Facebook Pages

Meta's GitHub sources give no publishing quota or call limit for Facebook Page posts. What they show for Pages is the X-Business-Use-Case-Usage header with type pages on the webhook subscription calls, and one feature limit from Page messaging: Messenger's user-level persistent menu settings "are rate limited to 10 calls per user per 10 min."

Both Meta collections give the same advice for reacting to activity. The Instagram collection "strongly recommend[s] using webhooks to prevent rate limiting" when reading comments, and the Messenger collection says webhooks "avoid rate limits" that polling would cause. Meta webhooks covers the setup.

What this page doesn't cover

Meta's public GitHub sources don't state:

• the formula for the app-level limit or for business use case limits;
• the length of the window either header measures;
• whether Meta's Marketing API and Instagram use business use case limits, or which limit applies when both do;
• the HTTP status of a throttled response;
• any per-hour call limit for Instagram, Threads or Pages.

Those are on Meta's rate limiting page in its developer documentation. Read them there, and treat any number you find quoted elsewhere as unconfirmed until you do.

What to do next

• Business owners: If posts from a scheduling tool sometimes fail on busy days, ask the vendor whether it checks Instagram's content_publishing_limit before publishing. A tool that does can hold a post back instead of losing it.
• Marketers and agencies: Spread bulk uploads across the day. The publishing quotas run per account over 24 hours, so a full week queued for one Instagram or Threads account at once can run into them.
• Developers: Call content_publishing_limit or threads_publishing_limit before each publish and skip or delay when the quota is used. Parse X-App-Usage and X-Business-Use-Case-Usage as JSON on every response and log them, back off when estimated_time_to_regain_access is above 0 or you get code 4 or 341, use webhooks instead of polling, and keep your Graph API version current.