Social Media Posting Limits by Platform: What Official Docs Say

The Threads API overview, updated December 22, 2025, sets the official quotas: 250 posts published through the API per rolling 24h, 1,000 replies per 24h, and 100 deletions per 24h. Carousels count as one post. The split matters: the Threads app has no documented cap for humans, so 250 is an API ceiling, not an app rule.

Format limits sit beside the quota. Text posts max out at 500 characters, which our Threads character limit guide covers in depth. Carousels hold 2 to 20 items, video runs up to 300 seconds (5 minutes) with a 1GB file ceiling, and images cap at 8MB in JPEG or PNG at widths from 320 to 1440.

The call budget is separate from the post cap. The documented formula is 4,800 times impressions per 24h, with an impressions floor of 10. Above that floor it scales with impressions. Impressions are not reach, and this budget is not a flat call allowance.

Wire the numbers into your Threads API publishing workflow before you batch anything. The post, reply, and deletion caps are separate buckets, and a bulk cleanup can burn all 100 deletions fast. Quiet accounts should also check the impressions floor, since it sets the smallest call budget.

X publishes its numbers in the About X limits page. Unverified accounts get 50 original posts and 200 replies per day. Above those sits a total ceiling of 2,400 updates per day, split into half hour windows, which is why a burst can stall before you reach the headline number.

Every device and every route counts toward the same budget, including posts made through the API and any scheduling tool acting as you. Your queue and your phone share one allowance, so manual posting on a busy day eats into scheduled volume.

Length is separate from count: 280 characters is standard, up to 4,000 with X Premium, and each post can carry up to 4 media items. Longer posts do not buy extra daily volume; they just change what fits inside it.

The Instagram content publishing guide, updated June 30, 2026, caps the API at 100 published posts per 24h. Like Threads, this is an API limit: Instagram publishes no matching number for posting by hand in the app.

Carousels count as one post, not one per card. Every item in the carousel rides on that single unit of quota.

You can also read the counter directly. The Instagram content publishing guide documents a content_publishing_limit endpoint that returns how many of the 100 daily API posts an account has already used. Checking it before a bulk import beats finding the ceiling by trial, and it is the same pattern Threads offers through its own publishing limit endpoint.

TikTok has the lowest documented post cap in this set. The TikTok content sharing guidelines say the Direct Post API cap varies per creator and typically sits around 15 posts per 24h, and that budget is shared across every API client on the account rather than granted per tool.

A Bluesky create costs 3 points. Per the Bluesky rate limits page, each account gets 5,000 points per hour and 35,000 points per day. If every point goes to creates, that ceiling is 1,666 posts per hour or 11,666 per day. That is a ceiling, not a target.

Post length lives in the protocol. The post record lexicon caps text at 300 graphemes and 3,000 bytes, so emoji and scripts beyond basic Latin can hit the byte ceiling before the grapheme count does.

LinkedIn publishes no per member posting limit for humans. What the Community Management API overview documents instead, in its April 2026 version, is API traffic: the Development Tier allows 500 requests per app per day and 100 requests per member per day.

Access is the harder wall. The member posting permission, r_member_social, is closed to new access, so a new app cannot get that permission.

LinkedIn does publish how its API limits reset: at midnight UTC every day, as its rate limiting documentation states. That matters for teams in other time zones. A queue that goes quiet at 6 PM in New York is often just waiting for the UTC clock, not stuck.

Do not treat a percentage of the cap as a platform rule. The docs do not publish one. Leave room under the cap that binds the surface you post from, because replies, deletions, hand posts, and other clients can share that budget.

Plan against the surface you actually post from. A human in the app is not bound by documented API caps, while a tool publishing through the API is bound by them even on platforms with no app cap. Record the surface you post from and only the cap the docs publish for that surface.

Example: a batch drops 40 Threads posts into the queue at once. Forty is under the 250 API post cap. Replies sent through the API use a separate bucket of 1,000 per rolling 24h. A Threads posting frequency test helps you pick a cadence, but it does not set that cap.

When you schedule Threads posts in advance, judge each rolling 24h against the API cap, not a weekly total. A social media scheduler for your queue can help you spread posts inside that cap. It does not raise the cap.

Post caps get the attention, but character and media limits break more queues. A 600 character post fails before any daily cap matters. The Threads character limit is 500 characters for text posts, images top out at 8 MB in JPEG or PNG with a width range of 320 to 1,440, video runs up to 300 seconds in a file no larger than 1 GB, and a carousel needs 2 to 20 items while counting as a single post against the 250 cap.

X allows 280 characters on a standard account and up to 4,000 with X Premium, plus up to 4 media items in one post, and the X Help Center notes that media limits apply across every device and the API alike. Bluesky measures text twice: 300 graphemes and 3,000 bytes of UTF-8, whichever you hit first. Emoji and non Latin scripts consume bytes faster than graphemes, so a post that fits a character counter can still fail the byte ceiling.

None of these specs are negotiable at publish time. The platform rejects the post instead of trimming it, so a scheduler queue full of 320 character drafts or 9 MB images will report failures rather than publish shortened versions. Checking specs once, before a batch enters the queue, is cheaper than discovering them one failed post at a time.