Instagram API limit: 100 posts per 24 hours and a Reels render queue

Short answer

Instagram's content publishing documentation says an account is limited to 100 API-published posts within a 24-hour moving period. A normal content calendar of a few Reels per day is far below that, but a backfill, a bulk campaign or a bug that republishes can reach it quickly. Render in batches, publish on a schedule, and count what you have published in the last 24 hours before you submit more.

The limit is about publishing, not about rendering. Sume Timeline renders happen before publishing and are not API-published posts, so only what you publish counts toward it.

Limit and plan

The numbers below are from the Instagram page and the Sume docs.

A safe publishing queue

A moving window differs from a calendar day. If you published 100 posts at 09:00, you cannot publish again until the earliest one ages past 24 hours, not until midnight. Keep a list of timestamps for published posts and drop any older than 24 hours before you decide how many slots remain.

Keep the queue's capacity below the cap with a margin, and route over-limit items to the next day instead of retrying in a loop. The Python below shows the count check only; it does not call any API.

from datetime import datetime, timedelta, timezone

LIMIT = 100

def slots_left(published, now=None):
    now = now or datetime.now(timezone.utc)
    recent = [t for t in published if now - t < timedelta(hours=24)]
    return max(0, LIMIT - len(recent))

if __name__ == '__main__':
    now = datetime.now(timezone.utc)
    stamps = [now - timedelta(hours=h) for h in (1, 5, 30)]
    print(slots_left(stamps, now))

Where render planning helps

Cost is predictable: 100 Reels of 30 seconds, each rounded up to one output minute, is $10.00 at the public rate. If your Reels are 61 seconds, each bills as two minutes, so trimming to 60 seconds halves the render cost. Use POST /v1/timeline-1.0/plan to see billable_minutes first.

Do not render all 100 at once because the account can only publish so many; render ahead by a day or two and hold the files until their slot. For container status polling after you submit, see the container status post.

Common ways to hit the cap

The usual causes are not planned volume. A retry loop that republishes a failed post, a scheduler that fires twice after a restart, or a backfill that pushes an entire archive in one afternoon can all burn the window quickly. A cap of 100 leaves plenty of room for normal use and no room for a runaway job.

Protect against it in your own code. Make publish steps idempotent on your side by recording what has already been published, check the count before each batch and stop when the margin is gone. On the Sume side, sending an Idempotency-Key with each render request prevents a retry from creating a second paid render; the Timeline docs require the header.

Finally, spread large campaigns across days. If you have 300 Reels to publish, three days at 100 is the ceiling, and a gentler schedule is safer than running at the limit.