What Instagram's content_publishing_limit Endpoint Returns

What does the content_publishing_limit endpoint return?

Meta's content_publishing_limit endpoint returns a count of how many containers an Instagram professional account has already published inside a rolling 24-hour window, together with the ceiling that count is measured against. It is a read-only endpoint. The reference says so twice: "Creating: This operation is not supported" and the same line for updating and deleting.

The request shape, copied from Meta's reference:

GET https://graph.facebook.com/<API_VERSION>/<IG_USER_ID>/content_publishing_limit
  ?fields=<LIST_OF_FIELDS>
  &since=<UNIX_TIMESTAMP>
  &access_token=<ACCESS_TOKEN>

Apps built on Instagram API with Instagram Login send the same call to graph.instagram.com instead. The response is a data array with one object in it:

{
  "data": [
    {
      "quota_usage": 2,
      "config": {
        "quota_total": 50,
        "quota_duration": 86400
      }
    }
  ]
}

What do quota_usage, quota_total and quota_duration mean?

Three field names carry the whole response, and Meta defines each one in a sentence.

quota_usage is the field you get for free. Meta's note on the fields parameter reads: "A comma-separated list of fields you want returned. If omitted, the quota_usage field will be returned by default." Ask for config explicitly or you will not see the ceiling, only the count.

The since parameter narrows the window. Meta describes it as "A Unix timestamp no older than 24 hours," and adds that "If the since parameter is omitted, this value will be the number of times the app user has published a container within the last 24 hours." You cannot look further back than a day, which is the same thing as saying the endpoint has no memory beyond the quota it enforces.

One oddity sits in Meta's own example request. It queries fields=quota_usage,rate_limit_settings, and rate_limit_settings appears nowhere in the fields table on that page or anywhere else in the Instagram Platform reference. The example asks for a field the documentation never defines.

Is the cap 50 posts or 100?

Meta publishes both numbers on live pages, and it never reconciles them. The content publishing guide states: "Instagram accounts are limited to 100 API-published posts within a 24-hour moving period." The content_publishing_limit reference states that quota_total is "currently 50." The carousel section of that same guide states: "Accounts are limited to 50 published posts within a 24-hour period."

So the guide contradicts itself internally, and the reference sides with the lower number. This is not a stale page that Meta forgot about, it is the endpoint documentation for the exact field that reports the ceiling. The gap between the 100-post sentence and the 50-post sentence is old enough to have survived several Graph API versions.

The practical resolution is to stop reading either number and read quota_total from the response instead. That is the number the account is actually being measured against, it arrives per account, and it costs one request to get.

What counts against the quota and what does not?

Publishing counts. Creating does not. The distinction is exact in Meta's wording, because quota_usage counts "the number of times the app user has published an IG Container," and the guide names the endpoint where enforcement happens: "This limit is enforced on the POST /<IG_ID>/media_publish endpoint when attempting to publish a media container."

Container creation has its own ceiling that most teams never meet. The media endpoint reference states: "An Instagram account can only create 400 containers within a rolling 24 hour period." Eight containers per publish is a generous ratio, so a workflow that retries container creation aggressively can exhaust that budget while quota_usage still reads zero, and the failure will look nothing like a publishing rate limit.

Carousels are the case worth internalising if you batch image sets. Ten images become one unit of quota, which makes scheduling carousel posts across Instagram and Facebook far cheaper against the cap than ten single posts carrying the same images.

How should you read the response before publishing?

Call content_publishing_limit before the publish, not after the failure, and compare quota_usage against config.quota_total rather than against a number you hardcoded. Meta asks for this directly: "We recommend that your app also enforce the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future."

Three details decide whether that check is worth anything:

• Request config explicitly. Without it you get a usage count and nothing to compare it to.
• Treat the window as rolling, not daily. quota_duration is 86400 seconds measured backwards from now, so capacity returns gradually through the day rather than at a reset hour.
• Re-read before each publish in a batch, not once per batch. A queue of 20 posts that checked the quota once at the start is a queue that can walk past the ceiling on post 14.

Scheduling tools are where this bites hardest, because a queue commits to publish times hours or days in advance while the quota is spent in the present. That is the same class of problem as any social media scheduling API built on a platform quota: the schedule is written against capacity that has not been measured yet.

What error does Instagram return when you hit the cap?

Meta's error codes reference lists it precisely. An account that has exhausted its publishing quota gets HTTP 400, code 9, subcode 2207042, with the user message: "You reached maximum number of posts that is allowed to be published by Content Publishing API."

The recommended solution reads: "The app user has reached their daily publishing limit. Advise the app's user to try again the following day." Note the mismatch. The window is documented as a moving 24-hour period everywhere else, and the advice here says "the following day," which is calendar language for a rolling window. Capacity frees up 24 hours after each individual publish, not at midnight.

Adjacent failures look different and should be handled separately. Code 4, subcode 2207051 returns "We restrict certain activity to protect our community. Tell us if you think we made a mistake," which Meta attributes to publishing "suspected to be spam." That is not a quota problem, and retrying tomorrow will not clear it. Other platforms draw the same line between a quota you can wait out and a restriction you cannot, which is why Pinterest's published rate limits and Instagram's both need separate handling paths in the same queue.

Which permissions does the call need?

The token scopes differ by login flow, and Meta lists both. Instagram API with Instagram Login needs instagram_business_basic and instagram_business_content_publish. Instagram API with Facebook Login needs instagram_basic, instagram_content_publish and pages_read_engagement, plus ads_management or ads_read when "the app user was granted a role via the Business Manager on the Page connected to the targeted IG User."

Those are the same scopes the publish call itself requires, so a token that can publish can also read the quota. There is no cheaper read-only scope for checking capacity, which means the quota check is available to every app that would ever need it.

Frequently asked questions

What is the full path of the endpoint?

GET /<IG_USER_ID>/content_publishing_limit, on graph.facebook.com for Instagram API with Facebook Login and on graph.instagram.com for Instagram API with Instagram Login.

Does the endpoint return the limit by default?

No. Only quota_usage comes back by default. Meta's reference says the config object, which holds quota_total and quota_duration, has to be requested through the fields parameter.

How far back can the since parameter reach?

24 hours. Meta describes the value as "A Unix timestamp no older than 24 hours," so the endpoint cannot report usage from any earlier window.

Do failed publish attempts count against quota_usage?

Meta does not say. The field counts times the user "has published an IG Container," which reads as successful publishes, but the documentation never addresses a publish that errors after being accepted.

Does creating a media container use quota?

No. Container creation is governed by a separate rule, that an account "can only create 400 containers within a rolling 24 hour period," and containers expire after 24 hours whether or not they are published.

Why does quota_total say 50 when the guide says 100?

Meta publishes both numbers and never resolves them. The reference for the endpoint says quota_total is "currently 50," the content publishing guide says 100 in its rate limit section and 50 again in its carousel section. Read the value from the response rather than trusting either page.

How often should you recheck the quota in a publishing queue?

Recheck before every publish in the queue, not just once at the start. The window is rolling, so a batch of 20 posts that only checked capacity at the beginning can walk past the ceiling by the time it reaches post 14. Comparing quota_usage against config.quota_total on each send catches that drift before Instagram does.

Does a carousel count as one post or several against quota_usage?

A carousel counts as one post regardless of how many images it holds, per Meta's line that "Carousels count as a single post." Ten images published together spend the same single unit of quota_usage as one image published alone. That makes carousels far cheaper against the cap than posting the same images one at a time.

What happens if an app ignores the publishing rate limit?

Meta recommends that apps enforce the rate limit themselves, especially when they let users schedule posts in advance, because skipping the check only delays the failure to publish time. An account over the quota gets HTTP 400, code 9, subcode 2207042, and capacity returns 24 hours after each publish, not at a daily reset. A scheduling tool that skips the pre-check finds this out after it has already committed to a publish time it can no longer keep.

Is a spam restriction the same thing as hitting the publishing quota?

A spam restriction is a separate failure from a quota limit. Code 4, subcode 2207051 fires when a publish is "suspected to be spam," and retrying the next day will not clear it the way waiting out the quota does. That distinction matters for a queue, because the two errors need different handling paths, one that waits and one that stops and flags the content.