Meta's Threads API posting limit is 250 published posts within a rolling 24-hour period, per profile, according to Meta's own Threads API documentation. That cap is what actually bounds how many posts a scheduler, or anyone calling the API directly, can get out in a day, and it isn't the only number in play. Replies and deletions each carry their own separate limit, tracked independently of the 250.
How many posts can you publish to Threads per day through the API?
250, per profile, per rolling 24-hour window. Meta states it plainly: Threads profiles are limited to 250 API-published posts within a rolling 24-hour period. "Rolling" is the detail most third-party summaries drop: the window doesn't reset at midnight. A post made at 9 a.m. stops counting against the cap at 9 a.m. the next day, so capacity returns gradually through the day rather than all at once. That makes 250 a hard ceiling on API throughput, a different question from how often an account should post for engagement, which Synapse's guide to posting frequency on Threads covers separately.
What counts toward the 250, and what doesn't
A carousel, Meta's term for a single post carrying 2 to 20 images or videos, counts as one post against the 250 regardless of how many items it holds. A plain text post counts the same as one carrying media, and text posts are separately capped at 500 characters, a limit Synapse's Threads character limit guide covers in full; neither the text length nor the media count changes how much of the 250 a single post consumes. Replies don't touch the 250 at all. Meta gives replies their own ceiling, 1,000 within a rolling 24-hour period, tracked on a completely separate counter. Deleting a post has a cap too, 100 deletions within a rolling 24-hour period, which matters for Synapse specifically: deleting a post in Synapse also removes the live copy on Threads, so clearing out a large batch of old Threads posts in one sitting can hit that 100-deletion ceiling before it touches the post limit at all.
| What's limited | Cap | Window | Permission needed to check it |
|---|---|---|---|
| Posts (API-published) | 250 | Rolling 24 hours | threads_basic + threads_content_publish |
| Replies | 1,000 | Rolling 24 hours | threads_basic + threads_content_publish + threads_manage_replies |
| Deletions | 100 | Rolling 24 hours | threads_basic + threads_delete |
Check your real quota instead of guessing
Meta exposes the current count directly: a GET request to `/{threads-user-id}/threads_publishing_limit` returns live usage against all three caps, so an app doesn't have to track its own counter and hope it matches Meta's. Which number comes back depends on which permission scopes the call carries, as the table above shows; a token missing `threads_manage_replies`, for example, can check its post and deletion usage but not its reply usage. Querying that endpoint before a large batch publish is the only way to know how much of the 250 is actually left, rather than assuming a fresh day or a fresh hour has reset anything.
There's no scheduling endpoint, so every scheduler fakes one
Threads' API has no native "publish later" parameter. Publishing is a two-step call: create a media or text container, then publish that container in a second call, both of which happen immediately when invoked. A scheduler that shows a future date and time for a Threads post is holding that post in its own database and firing the same two-step call on a timer when the moment arrives, exactly the same create-then-publish flow a developer would call manually. Reading Synapse's own Threads integration confirms this directly: it builds a container, polls it until Meta finishes processing, then publishes, with no separate scheduling call anywhere in that path. That has a practical consequence for anyone running Instagram and Threads together from one post: the 250-post cap belongs to the Threads profile alone, so a cross-posting batch only spends Threads quota on the Threads side of it, never on the Instagram side.
How Synapse handles a Threads account that hits the limit mid-batch
Synapse's Threads integration publishes each connected account independently, inside its own try/catch, the same pattern used across every direct platform integration in the app. Reading the code directly shows no queue-and-backoff loop built against the 250-post cap: a rejected publish call surfaces as a plain per-account error carrying Meta's own response, so that account shows up as failed in the post's results rather than disappearing silently or blocking the accounts that still had room under the cap. Threads carries one extra wrinkle other platforms in Synapse don't: it issues no idempotency key, so a retry genuinely risks posting the same content twice if the first attempt actually succeeded before the error came back. Synapse's Retry failed flow checks for a matching recent post on the account before calling publish again, and only creates a new one if it doesn't find one, so re-running a failed batch after the 24-hour window rolls forward doesn't risk a duplicate.
Frequently asked questions
What is the Threads API's posting limit per day?
250 API-published posts per profile, within a rolling 24-hour period rather than a fixed calendar day, per Meta's own Threads API documentation.
Does a Threads carousel count as more than one post against the limit?
No. A carousel, which can hold 2 to 20 images or videos, counts as a single post against the 250-post cap regardless of how many items it contains.
Do replies count toward the 250-post limit on Threads?
No. Replies have a separate allowance of 1,000 within a rolling 24-hour period, tracked on its own counter independent of the post limit.
Is there a limit on deleting posts through the Threads API?
Yes, 100 deletions within a rolling 24-hour period. That matters in Synapse because deleting a post there also removes the live copy on Threads, so a large bulk cleanup can hit the deletion cap before it touches the post limit.
Can you check how much of your Threads posting quota is left?
Yes. A GET request to /{threads-user-id}/threads_publishing_limit returns live usage against the post, reply, and deletion caps, scoped to whichever permissions the access token carries.
Can you schedule a Threads post for a future date through the API?
Not natively. The Threads API only supports immediate two-step publishing (create a container, then publish it), so a scheduler holds the post itself and fires that same call when the scheduled time arrives.