Instagram Reels API: a 100-posts-per-24-hours publish budget

Instagram accounts are limited to 100 API-published posts in any moving 24-hour period, and a Reel is published by creating a container with media_type=REELS and a video_url. A batch run can produce far more than 100 clips in an afternoon, so the publishing side needs its own budget, not the generation side.

What the docs state

The cap is per account, and it is a moving window, not a midnight reset. A post made at 3 pm yesterday stops counting at 3 pm today.

A moving-window queue

The class below is plain Python with no dependencies. It records publish times and answers how long to wait before the next post. It only models the limit; the Graph API calls are yours to add, and video_url must point at a public file.

import time
from collections import deque

class PublishBudget:
    def __init__(self, limit=100, window=86400):
        self.limit, self.window = limit, window
        self.sent = deque()

    def wait_seconds(self, now=None):
        now = time.time() if now is None else now
        while self.sent and self.sent[0] <= now - self.window:
            self.sent.popleft()
        if len(self.sent) < self.limit:
            return 0.0
        return self.sent[0] + self.window - now

    def record(self, now=None):
        self.sent.append(time.time() if now is None else now)

b = PublishBudget(limit=3, window=60)
for t in (0, 1, 2):
    b.record(t)
print(b.wait_seconds(now=10))  # 50.0

Planning generation against the cap

If you can publish 100 a day, there is no gain in finishing 400 clips today. Submit generation in waves that match the publishing rate, and keep the video_url source stable until the post is created. The video API returns unsigned_urls on a completed job, and the jobs docs describe the shared job endpoints and batch waits.

Sume's own admission limits are separate: the generation admission page describes queued and running job limits per plan, and 429 queue_full when a workspace has no capacity left. Back off before retrying, and reuse the same Idempotency-Key for any retried submit.

Operational notes

This post covers only the volume cap. Format requirements for Reels are a separate topic.

• Keep a published log so a restart does not double-post.
• Hold 5 to 10 percent of the 100 in reserve for fixes and reposts.
• Check the container status before counting a post as sent.
• Re-read Meta's page before launch; limits and fields change.

Spreading a batch

Divide the daily budget across the day instead of firing it in one burst. If you hold 90 posts a day, one post every 16 minutes uses the budget evenly and leaves room for fixes. A burst is more likely to hit errors together and harder to recover from.

Keep the generation queue a few hours ahead of the publish queue. That way a slow render does not leave the publisher idle, and a failed render does not stall a scheduled post.

Log every container ID next to its job ID. When a post fails, you can tell whether the video, the container or the publish call was the problem, and you do not recount a failed attempt as a published post unless Meta's limit says it counts.