How the Threads API 250 Posts Per Day Limit Works

What is the Threads API 250 posts per day limit?

Meta applies the Threads API 250 posts per day limit to the publish step, so a Threads profile can turn 250 media containers into live posts in any rolling 24 hours. The sentence sits in the Rate Limiting section of Meta's Threads overview and reads: "Threads profiles are limited to 250 API-published posts within a 24-hour moving period. Carousels count as a single post. This limit is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container."

Three details in that passage decide how a queue behaves. "API-published" scopes the count to posts pushed through the Threads API rather than typed into the Threads app. "Moving" rules out a midnight reset. And naming threads_publish as the enforcement point means container creation is free, because the count only moves when a container becomes a post.

Meta adds a fourth sentence that is aimed squarely at anyone building a scheduler: "We recommend that your app also enforces the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future."

How does the 24-hour window work?

The window slides, and each publish ages out of the count 24 hours after it happened rather than at a fixed hour. A profile that burns all 250 slots between 08:00 and 09:00 on Monday gets that capacity back between 08:00 and 09:00 on Tuesday, one publish at a time, not in a single block at midnight.

The quota endpoint puts a number on the window. Its config object carries quota_duration: 86400, which is 24 hours in seconds, alongside quota_total: 250. Nothing in the Threads documentation exposes the timestamps of individual publishes, so the only way to know how much room is left at this second is to ask Meta for the current usage.

Which endpoint reports the remaining quota?

GET /{threads-user-id}/threads_publishing_limit returns the profile's own count, and Meta describes it as the way "To validate that a user has not exhausted their API quota limits for publishing, reply publishing, deleting, and location search." Two fields cover publishing: quota_usage, which Meta defines as "Threads publishing count over the last 24 hours", and config, which holds quota_total and quota_duration.

curl -s -X GET \
"https://graph.threads.net/v1.0/<THREADS_USER_ID>/threads_publishing_limit?fields=quota_usage,config&access_token=<ACCESS_TOKEN>"

{
  "data": [
    {
      "quota_usage": 4,
      "config": {
        "quota_total": 250,
        "quota_duration": 86400
      }
    }
  ]
}

The call needs the threads_basic and threads_content_publish permissions. Reading quota_total rather than hardcoding 250 is the difference between an integration that survives a quota change and one that silently throttles itself for a year after Meta raises the ceiling.

What are the other Threads API quotas?

The same endpoint reports four separate budgets, each with its own field pair and its own ceiling. Every one of them uses a quota_duration of 86400 seconds.

Replies get their own budget of 1,000, which Meta states as "Threads profiles are limited to 1,000 replies within a 24-hour moving period." A bot that answers comments therefore has four times the headroom of one that publishes, and burning reply quota never touches the 250. None of these budgets interacts with the 500-character ceiling on post text, which is enforced at container creation rather than at publish and is covered in the Threads character limit.

Does a carousel count as one post or as twenty?

A carousel counts as one publish, whatever it holds. Meta writes it twice: "Carousels count as a single post" on the overview page, and "Publishing a carousel counts as a single post" in the carousel walkthrough. Since a Threads carousel takes up to 20 children, a profile publishing nothing but full carousels moves 5,000 individual images and videos through 250 publishes.

That ratio is the only real lever anyone has on this cap. Ten separate images cost ten of the 250 slots. The same ten shipped as one carousel cost one. Anyone close to the ceiling should be grouping media before asking for more headroom, which is the same arithmetic behind the Instagram API cap of 100 posts per 24 hours.

Why do Meta's two pages word the same limit differently?

The number agrees across pages and the wording does not. The overview page says "250 API-published posts within a 24-hour moving period". The carousel walkthrough, in a note above Step 3, says "Profiles are limited to 250 published posts within a 24-hour period."

The second version drops "API-" and drops "moving". Read literally, it would cover posts made by hand in the app and reset on a fixed clock. Meta never reconciles the two, and only the overview page carries the enforcement detail naming threads_publish, so the overview is the fuller statement of the same rule. Treat the shorter sentence as an abbreviation rather than a second policy.

What error does Threads return when the quota is gone?

Meta documents no error code for exceeding the publishing quota. The Threads API Reference index lists nine endpoint pages and no error codes page at all, and the troubleshooting page only covers container outcomes: the status values EXPIRED, ERROR, FINISHED, IN_PROGRESS and PUBLISHED, plus video error_message values such as FAILED_DOWNLOADING_VIDEO and INVALID_ASPEC_RATIO.

The one publish-time failure string Meta does document is unrelated to volume. From December 22, 2025, a post carrying more than five links fails at the container step with THREADS_API__LINK_LIMIT_EXCEEDED. There is no matching constant for the 250.

That absence is why Meta tells apps to enforce the limit themselves. Code written against an undocumented failure response is a guess; code that reads quota_usage before publishing is checking the same counter Meta is.

How is the per-app rate limit different from the 250?

The 250 is a profile-level publishing budget. Separately, every Threads API call counts against the calling app, and Meta gives that a formula instead of a constant: Calls within 24 hours = 4800 * Number of Impressions, where impressions are "the number of times any content from the app user's Threads account has entered a person's screen within the last 24 hours". The minimum value for impressions is 10, so the floor is 48,000 calls per app and user pair.

Two CPU budgets ride along with it, 720000 * number_of_impressions for total CPU time and 2880000 * Number of Impressions for total time. The same impressions-based shape governs the Instagram API rate limit of 4800 impressions, which is unsurprising given both run on Meta infrastructure.

A profile can therefore hit 250 publishes while nowhere near its app call budget, since polling container status, reading insights and fetching replies all spend calls without spending publishes.

What does the cap mean for a scheduling queue?

The 250 belongs to Threads, and every tool publishing through the official API works inside it. No scheduler raises a platform quota, so the work is in the shape of the queue: grouping media into carousels, spreading a launch across days, and reading quota_usage before a batch fires rather than after a publish fails.

Meta's own advice points the same way, since it asks apps that let people schedule posts to enforce the publishing limit locally. The mechanics of queueing a Threads post in the first place are covered in how to schedule Threads posts. Seeing a week at once is what stops a burst from being scheduled, which is the job of a content calendar, and for anyone loading a month in one sitting bulk scheduling is where the spread gets decided. AdaptlyPost publishes to Threads through the official API, so the same 250-post window applies; the Threads scheduling tool page covers how that connection works.

Frequently asked questions

Do posts made in the Threads app count toward the 250?

Meta's overview sentence limits profiles to 250 "API-published posts", which names posts created through the Threads API. The carousel page drops the "API-" prefix and says "250 published posts", and Meta never says which reading governs. Query GET /{threads-user-id}/threads_publishing_limit when manual posting volume is high enough to matter, since that endpoint reports whatever Meta is actually counting.

Do replies count against the 250-post quota?

No. Replies have a separate budget of 1,000 within a 24-hour moving period, reported through the reply_quota_usage and reply_config fields on the same endpoint. Publishing a reply never reduces the 250 available for posts.

When does the 24-hour window reset?

It never resets, because Meta calls it a "24-hour moving period". Individual publishes age out one at a time, 24 hours after each one happened. The quota_duration field states the same thing numerically as 86400 seconds.

How many images can one profile publish per day through the Threads API?

Up to 5,000, if every publish is a full carousel. Meta caps a carousel at 20 children and counts it as a single post, so 250 publishes carry 250 times 20 pieces of media. Publishing single images instead caps the same profile at 250 images.

Does creating a media container use up quota?

Meta states that the limit "is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container", which puts the count on the publish call. Containers do carry their own clock: an unpublished container returns EXPIRED, described as "The container was not published within 24 hours and has expired."

Where is the 250-post limit documented?

On Meta's Threads overview page at developers.facebook.com/documentation/threads/overview, under Rate Limiting, in the Posts subsection. The carousel walkthrough at developers.facebook.com/documentation/threads/posts repeats the number in a note above Step 3, and the quota endpoint that reports it is documented on both the troubleshooting page and the User reference.

Is the 250-post limit tied to a Threads profile or to an app?

The 250 is a profile-level publishing budget attached to the Threads account itself. A separate per-app rate limit runs alongside it, calculated from impressions rather than a flat number, so a profile can reach its 250 publishes while the connected app still has plenty of call budget left.

Can a developer get Meta to raise the 250-post cap?

Meta's documentation states the 250 number on both the overview and carousel pages without offering a request path for a higher ceiling. The only lever documented anywhere is grouping media into carousels, since a carousel counts as one publish no matter how many of its 20 possible children it carries. Reading quota_total instead of hardcoding 250 is the only preparation Meta suggests for the day that number changes.

What should a scheduler do when a Threads batch would exceed the 250 quota?

Meta documents no error code for exceeding the publishing quota, so a scheduler that waits to catch a failure has nothing reliable to catch. Meta's own recommendation is to check quota_usage before a batch fires and hold posts back locally, which is the same enforcement it asks of any app that lets people schedule future posts.

Is the Threads 250-post limit the same as Instagram's posting limit?

The numbers differ. Threads profiles get 250 API-published posts within a 24-hour moving period, while the comparable Instagram API cap is 100 posts per 24 hours. Both limits run on the same Meta infrastructure and both come with a per-app call limit built from the same impressions-based formula.