ALTINERISRequest access

Instagram API publishing limits, explained properly

Instagram's Graph API allows 100 API-published posts per professional account per rolling 24-hour window; a carousel counts as one post regardless of how many cards it carries, and current usage is queryable at any time via GET /content_publishing_limit.

PUBLISHED 20 AUG 2026 · CHECKED AGAINST PRIMARY SOURCES ON THE UPDATE DATE

CLAIMS CARRY THEIR CONFIDENCE: DOCUMENTED = STATED BY THE PLATFORM OR IN A CITED PUBLIC SOURCE ·INFERENCE = REASONABLE DEDUCTION, NOT CONFIRMED · UNKNOWN = NOT PUBLIC, SAID SO INSTEAD OF GUESSED

Publishing is two steps, not one

The Graph API does not accept an upload in a single call. Publishing is container creation followed by publication, and the gap between them has its own failure modes.DOCUMENTED

  1. POST /media creates a container. You pass Meta a URL — not bytes. Meta's crawler fetches your media from your own public host; if your host blocks that crawler, container creation fails with error 479. DOCUMENTED
  2. POST /media_publish publishes the container. A container left unpublished expires after 24 hours — a queue that creates containers ahead of a scheduled slot has to respect that lifetime. DOCUMENTED

Two practical consequences follow directly: your media host must be reachable by Meta's crawler at publish time (a private bucket or an aggressive WAF rule reads as a publish outage), and "schedule far in advance by pre-creating containers" is bounded by the 24-hour ceiling.

The quota is a moving window, not a daily allowance

RuleDetailConfidence
The limit100 API-published posts per Instagram professional account, per 24-hour moving periodDOCUMENTED
CarouselsCount as one post toward the limit — up to 10 items, all cropped to the first item's aspect ratioDOCUMENTED
Checking usageGET /content_publishing_limit reports current consumption — quota is queryable, never guessedDOCUMENTED
App-level pathsPrecise limits for non-API app paths are not published with API-level detailUNKNOWN

"Moving period" is the part schedulers get wrong: the window slides continuously, so a burst does not reset at midnight. If you publish 100 posts between 14:00 and 16:00, capacity returns gradually from 14:00 the next day — not all at once at 00:00.

Infographic: Instagram's 100-posts-per-24-hours quota drawn as a sliding window over a timeline (no midnight reset), beside the two-step flow — create container with its 24-hour lifetime, then publish, with error 479 as the blocked-crawler failure branch
THE MOVING WINDOW AND THE TWO-STEP PUBLISH — THE FACTS OF THIS PLATE ARE IN THE TABLE ABOVE

The 100-vs-50 discrepancy, resolved

A long tail of third-party scheduler blogs cites 50 posts per day. Meta's own developer documentation for content publishing states 100 per 24-hour moving period. When a primary source and secondary sources disagree, the primary source wins — but the honest record is that the discrepancy exists (Meta's documentation set has itself carried both figures in different places), so treat 100 as the documented ceiling and design your own budget with margin rather than flying at the limit. DOCUMENTED (the figure) · INFERENCE (fly with margin)

What the API will not do

These constraints shape what an automated pipeline can produce at all: DOCUMENTED

ConstraintDetail
ImagesJPEG only — MPO and JPS explicitly unsupported
FiltersNot supported — every visual treatment must be baked into the file before upload
Shopping tagsNot supported via the content-publishing path
CarouselMax 10 items; all items crop to the first item's aspect ratio
Alt textSettable for images only (supported since 24 March 2025)

The five ways a publish fails

  • Error 479 — Meta's crawler was blocked by your media host. This is a host-reachability problem, not a transient API error: retrying without fixing the host is a retry storm.
  • Container expired — more than 24 hours passed between create and publish.
  • Spec violation — container format, codec, moov atom position, edit lists, aspect ratio. All of it is checkable locally with ffprobe before submission, which is far cheaper than a failed container. DOCUMENTED
  • Quota exhausted — the 100/24h moving window (above).
  • Transcode failure — video publishing failures commonly require re-encoding and retry.DOCUMENTED

Engineering a publisher around these rules

The pattern that survives production, and the one Altineris builds on:

  • Reserve before you create. Claim quota against the moving window as a database constraint at scheduling time — so a launch discovers "no capacity" on the ground, never at the dock.
  • Treat rate-limit headers as authoritative and scope any 429 backoff to the single token that received it — one throttled account should never pause a fleet.
  • Priority classes. Publishes outrank reconciliation, reconciliation outranks analytics polling. Background housekeeping lives on leftover budget, not the other way around.
  • Validate the file locally first. An ffprobe preflight against the published spec catches the moov/edit-list/codec failures before they burn a container.
  • Reconcile against GET /content_publishing_limit — never trust only your own arithmetic about the window.

Sources