Instagram content_publishing_limit: read quota_usage before a bulk run

Call GET /<IG_USER_ID>/content_publishing_limit and read config.quota_total and quota_usage instead of hard-coding a daily number. Meta's publishing guide says 100 API-published posts in a 24-hour moving period, while the limit endpoint's own example response shows quota_total of 50, so the account's live value is the only safe input.

Both facts come from Meta's pages read on 2026-10-02: the content publishing guide and the IG User content publishing limit reference. We cannot tell from those pages whether 50 is an older sample or a different account class, so we report the mismatch rather than pick a side. Sume's side comes from the bulk runs docs.

What does the endpoint return?

The reference says it shows how many containers the user has published within a period. quota_usage is the default field; config returns quota_total and quota_duration (86400 seconds, one day). The optional since parameter is a Unix timestamp that cannot be more than 24 hours old.

Why not just use 100?

Because the page that states 100 also says it is a moving window, and the reference page for this endpoint shows a different quota_total. If you size a batch of 80 Reels from the guide and the account's real total is 50, 30 containers fail late, after you paid to generate the videos.

The reference also notes the call needs Facebook Graph API with a Facebook User access token and the instagram_basic, instagram_content_publish and pages_read_engagement permissions, with ads_management or ads_read possibly needed too. If you run Instagram Login, check this endpoint against your own token before relying on it.

• Read the quota first, then size the batch.
• Count containers, not just finished Reels.
• Re-read before every batch; usage is a moving window.

How do I size a batch from it?

Subtract usage from total and cap your batch at the remainder. This sketch uses only the standard library, reads the token from the environment and prints how many Reels you can still queue.

import json, os, urllib.request

def remaining(ig_id: str, token: str) -> int:
    url = (f"https://graph.facebook.com/v26.0/{ig_id}"
           f"/content_publishing_limit?fields=quota_usage,config"
           f"&access_token={token}")
    with urllib.request.urlopen(url, timeout=20) as r:
        row = json.load(r)["data"][0]
    return row["config"]["quota_total"] - row["quota_usage"]

if __name__ == "__main__":
    ig, tok = os.environ["IG_ID"], os.environ["IG_TOKEN"]
    left = remaining(ig, tok)
    print("Reels you can still queue in this window:", max(left, 0))

How does this connect to Sume bulk runs?

Sume's bulk-run docs describe a batch with its own concurrency and spend caps, and advise a fresh Idempotency-Key per batch. Use the remainder from the Instagram call as the number of items you submit, so you never generate videos you cannot publish today.

Sume does not call Instagram, does not know your quota and will not stop at it for you. For the 24-hour-window background see Instagram 100 posts per 24 hours and bulk-run sizing.

What if the number is lower than I expected?

Do not retry your way around it. Spread the work across days, prioritise the Reels with a deadline, and keep the rest as finished MP4s. Generated videos remain on Sume as artifacts, so waiting a day costs nothing but time.

Log the quota value you read and the time you read it with every batch. When a publish fails with a limit error, that record tells you whether your code miscounted or whether the account's allowance changed, which is exactly the question Meta's two pages leave open.