# Social Media API Rate Limits Compared (2026)

> Every major social API meters you differently: requests per window, points per hour, quota units per day, or a daily post cap. Here is what each one actually allows, with the figures from their own docs.

**Source:** https://posteverywhere.ai/blog/social-media-api-rate-limits
**Author:** Jamie Partridge
**Published:** 2026-09-04

---

_Last updated: September 2026._

There is no common unit for social media API rate limits. X counts requests in a 15-minute window. Bluesky counts points per hour. YouTube counts quota units per day. TikTok counts requests per minute and enforces a separate daily post cap it will not tell you the size of. LinkedIn does not publish its numbers at all.

That makes a like-for-like comparison harder than it should be, and it is why so many publishing integrations work perfectly in testing and then fall over at volume on one specific network. Teams reaching for [MCP](/blog/social-media-api-vs-mcp) or a managed layer usually do so after meeting one of these walls.

Getting approved to call these APIs at all is a separate gauntlet, covered in [how to get social media API access](/blog/how-to-get-social-media-api-access). This is a reference for the figures each platform publishes, taken from their own documentation, plus the retry behaviour that actually keeps a queue alive. Where a platform does not publish a number, that is stated rather than guessed.

## Table of Contents

1. [The Comparison Table](#the-comparison-table)
2. [X (Twitter)](#x-twitter)
3. [Meta: Facebook, Instagram and Threads](#meta-facebook-instagram-and-threads)
4. [LinkedIn](#linkedin)
5. [TikTok](#tiktok)
6. [YouTube](#youtube)
7. [Bluesky](#bluesky)
8. [Discord](#discord)
9. [Telegram](#telegram)
10. [Pinterest](#pinterest)
11. [How to Handle Limits Properly](#how-to-handle-limits-properly)
12. [FAQ: Social Media API Rate Limits](#faq-social-media-api-rate-limits)

## The Comparison Table

Each platform's own published figures. The units genuinely differ, which is the point.

| Platform | How it meters | Published limit for posting |
|---|---|---|
| **X (Twitter)** | Requests per window | 100 posts/15min per user; 10,000/24h per app |
| **Meta** | Calls per rolling hour | 200 × number of users, rolling 1 hour |
| **Instagram** | Daily post cap | 100 API-published posts per rolling 24h |
| **LinkedIn** | Calls per 24h, resets midnight UTC | **Not published**, per-app in the portal |
| **TikTok** | Requests per minute | 6 requests/min per user token |
| **YouTube** | Quota units per day | 10,000 units/day, 100 `videos.insert`/day |
| **Bluesky** | Points per hour and day | 5,000 points/h, 35,000/day; CREATE = 3 points |
| **Discord** | Requests per second | 50 requests/sec globally per bot |
| **Telegram** | Messages per second | ~30/sec bulk, 1/sec per chat, 20/min per group |
| **Pinterest** | Requests per user per app | 100 req/min (standard); 300/day (trial) |

Two things stand out. **Instagram's 100 posts per rolling 24 hours** is a hard cap rather than a throttle, so it cannot be retried past. And **LinkedIn publishes nothing**, which changes how you have to build against it.

## X (Twitter)

X's [rate limit documentation](https://docs.x.com/x-api/fundamentals/rate-limits) gives `POST /2/tweets` as **100 per 15 minutes per user** and **10,000 per 24 hours per app**. Windows are "usually 15 minutes or 24 hours".

Which limit applies depends on your auth: per-user limits apply with OAuth 1.0a or OAuth 2.0 user tokens, per-app limits with a Bearer Token. Responses carry `x-rate-limit-limit`, `x-rate-limit-remaining` and `x-rate-limit-reset` (a Unix timestamp).

Agents hit these limits faster than humans do, which is why our [agent framework comparison](/blog/ai-agent-frameworks-for-social-media) treats publishing as a solved layer rather than something to rebuild. Rate limits are entirely separate from billing. X now meters posting per call as well, and a post containing a link costs substantially more than one without, which we break down in [X API pricing](/blog/x-twitter-api-pricing). Staying inside the rate limit does not stop the meter running.

## Meta: Facebook, Instagram and Threads

Meta's Graph API calculates its allowance as **200 × the number of users** within a rolling one-hour window, tracked per app or per user depending on the token type. An app's call count is based on unique daily active users, so a new app with few users has a genuinely small budget. Meta's Graph API rate limiting documentation is the authoritative source here, though it blocks automated fetching, so we are not linking a URL we cannot verify resolves.

**Instagram is the one to design around.** Meta's documentation states that "Instagram accounts are limited to 100 API-published posts within a 24-hour moving period". That is not a throttle you can retry past, it is a rolling ceiling, and it is a common cause of "why did my scheduler stop posting" on Instagram. Note it is a *moving* window rather than a midnight reset, so a burst does not clear all at once. If you are running client accounts through one integration, the cap is per account rather than per app, which is the saving grace.

Threads applies its own separate publishing cap, more generous than Instagram's but still a daily ceiling rather than a rate.

Note also that neither Facebook Groups nor personal profiles support API publishing, a platform restriction rather than a limit you can raise, covered in our [Facebook API guide](/blog/post-to-facebook-api).

## LinkedIn

LinkedIn is the outlier, and its own [rate limiting documentation](https://learn.microsoft.com/en-us/linkedin/shared/api-guide/concepts/rate-limits) is unusually candid about it: "Standard rate limits are not published in documentation."

What it does tell you:

- Limits are per 24 hours and **reset at midnight UTC**
- There are two kinds: **Application** (total calls your app can make) and **Member** (calls a single member can make through your app)
- Exceeding either returns **429**
- Developer admins get an email when an app passes **75%** of quota, though alerts lag 1 to 2 hours and fire only on application-level breaches

To find your actual numbers you look them up in the Developer Portal Analytics tab, and the page only shows endpoints you have called at least once today. So the documented way to discover a LinkedIn rate limit is to call the endpoint and then go and look.

Build accordingly: you cannot hard-code LinkedIn thresholds, so read the 429 and back off from it rather than trying to stay under a number you do not have.

## TikTok

The [Content Posting API](https://developers.tiktok.com/doc/content-posting-api-reference-direct-post) limits each user access token to **6 requests per minute**. That is the only concrete figure TikTok publishes.

There are two further caps it acknowledges without quantifying, both surfaced only as errors: `spam_risk_too_many_posts` ("the daily post cap from the API is reached for the current user") and `reached_active_user_cap` ("the daily quota for active publishing users from your client is reached").

The second one catches agencies out. It is a limit on how many distinct users your app publishes for in a day, not on how much any one of them posts, so it scales with client count rather than volume. There is no way to discover its value except by hitting it.

## YouTube

YouTube meters in quota units, and its [quota cost documentation](https://developers.google.com/youtube/v3/determine_quota_cost) sets the default allocation at **10,000 units per day** across most endpoints, plus a separate **100 `videos.insert` calls per day** and **100 `search.list` calls per day**.

For publishing, the 100 uploads per day figure is the one that binds, and it is generous for almost any real workflow. Read-heavy applications hit the 10,000-unit pool far sooner, because search is expensive relative to simple list calls. Additional quota requires an application to Google, and the approval process is covered in our [API access guide](/blog/how-to-get-social-media-api-access).

## Bluesky

Bluesky uses a points system, documented in its [rate limits reference](https://docs.bsky.app/docs/rate-limits): **5,000 points per hour and 35,000 points per day**, where CREATE costs 3 points, UPDATE 2 and DELETE 1.

That works out to at most **1,666 records per hour and 11,666 per day**. There are separate limits on account and session creation (50 and 300 per day respectively), which matter if you are onboarding many accounts rather than publishing from a few.

It is the most transparent scheme of any platform here, and the easiest to model in advance: multiply your intended writes by 3 and check it against 5,000. Our [Bluesky scheduler](/bluesky-scheduler) and [Bluesky API guide](/blog/post-to-bluesky-api) cover the publishing side.

## Discord

Per Discord's [rate limit documentation](https://docs.discord.com/developers/topics/rate-limits), bots may make **50 requests per second** globally, independent of per-route limits. Exceeding this consistently can result in temporary IP bans, so it is not a limit to probe.

Discord is the most instrumented of the group. Responses carry `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`, `X-RateLimit-Reset-After` and `X-RateLimit-Bucket`, and 429s add `X-RateLimit-Scope` with a value of `user`, `global` or `shared`.

The bucket header is the one people miss: limits are tracked per bucket rather than per route, so a queue treating all sends as one limit will be either too slow or too aggressive. Details in our [Discord API guide](/blog/post-to-discord-api).

## Telegram

Telegram's [bot FAQ](https://core.telegram.org/bots/faq) is refreshingly direct. In a single chat, avoid more than **one message per second**. In a group, bots cannot send more than **20 messages per minute**. For bulk notifications, bots cannot broadcast more than about **30 messages per second** unless they enable paid broadcasts.

Connecting Telegram through a [scheduling tool](/telegram-scheduler) sidesteps the bulk limits entirely. Paid broadcasts raise that to roughly 1,000 messages per second, but the eligibility bar is high: a minimum balance of 100,000 Stars and 100,000 monthly active users. For ordinary publishing, treat 30 per second as the ceiling and one per second per chat as the real constraint. See our [Telegram API guide](/blog/post-to-telegram-api) for the request shape.

## Pinterest

Pinterest's [rate limits reference](https://developers.pinterest.com/docs/reference/rate-limits/) separates trial from standard access. Trial access allows **1,000 requests per day** overall; standard allows **100 requests per second per user per app**.

Pin creation falls under the `org_write` category: **300 requests per day per app** on trial, **100 per minute per user per app** on standard. Headers are `x-ratelimit-limit`, `x-ratelimit-remaining` and `x-ratelimit-reset`, and the limit header can express several windows at once, as in `100, 100;w=1, 1000;w=60`.

The jump from trial to standard is large, so an integration that feels unusably slow in development may be fine in production. Do not tune your queue against trial numbers, and see [how to get API access](/blog/how-to-get-social-media-api-access) for moving between the two.

## How to Handle Limits Properly

Four patterns cover almost every failure we see.

Auth failures are a separate class of problem from rate limits and need different handling, covered in our [OAuth guide](/blog/social-media-oauth-guide).

**Read the headers, do not count locally.** Nearly every platform tells you what is left. Tracking your own counter drifts as soon as anything else shares the credentials, and it cannot know about limits the platform applies but does not publish.

**Back off from the response, not from a constant.** X gives you a reset timestamp, Discord and Telegram give you `retry_after`, Pinterest gives you seconds until reset. A fixed exponential backoff ignores all of that and will either wait far too long or hammer straight back into the wall. Use the platform's number when it gives you one.

**Treat daily caps differently from throttles.** A 429 from a throttle clears in seconds or minutes. Instagram's 100-post rolling ceiling and YouTube's 100 uploads clear on their own schedule, not on retry. Retrying into a daily cap just burns calls, so a queue needs to distinguish the two and park the post rather than loop.

**Fan out per account, not per app.** Most caps are per user or per account. An agency running many client accounts through one integration is usually limited by TikTok's active-user quota and Meta's user-count formula rather than by raw throughput. Our [multi-account setup](/multi-account-management) is built around that distinction.

> **Do not build this nine times.** PostEverywhere handles rate limits, retries, token refresh and per-platform formatting across all top platforms behind one endpoint. [See the API docs](/developers) or [compare social media APIs](/blog/best-social-media-apis).

If you would rather not implement nine different backoff strategies, a [unified publishing API](/social-media-api) collapses them into one. The same request reaches every network, and the limit handling sits on our side.

> **Publishing on a schedule?** Queue, retries and per-network limits handled, from $9/mo with a 7-day trial and card required. [See pricing](/pricing) or [browse connectors](/connectors).

## FAQ: Social Media API Rate Limits

### Which social media API has the strictest rate limit?

TikTok is the tightest per-minute, at 6 requests per user token. Instagram's 100 API-published posts per rolling 24 hours is a hard ceiling rather than a throttle, so it cannot be retried past. TikTok's 6 requests per minute per user token is the most restrictive per-minute figure, and its undisclosed daily post cap and active-user quota constrain agencies further.

### What are X (Twitter) API rate limits for posting?

X publishes `POST /2/tweets` as 100 posts per 15 minutes per user and 10,000 per 24 hours per app. Which applies depends on your token type: per-user limits with OAuth user tokens, per-app limits with a Bearer Token. Responses carry `x-rate-limit-limit`, `x-rate-limit-remaining` and `x-rate-limit-reset`.

### Why does LinkedIn not publish its rate limits?

LinkedIn's own documentation states that standard rate limits are not published, and directs developers to the Developer Portal Analytics tab instead, where limits appear per endpoint per app. The page only shows endpoints you have called at least once that day, so discovering a limit requires making a test call first.

### How many posts can I publish to Instagram via the API per day?

Meta documents the limit as 100 API-published posts within a 24-hour moving period, per account. It is a cap rather than a throttle, so it cannot be retried past, and because the window moves rather than resetting at midnight, a burst frees up gradually. The cap applies per account, so several client accounts each get their own allowance.

### What is the YouTube Data API daily quota?

The default allocation is 10,000 units per day across most endpoints, with separate allowances of 100 `videos.insert` calls and 100 `search.list` calls per day. For publishing workflows the 100 uploads per day figure binds first; read-heavy applications exhaust the 10,000-unit pool sooner because search is costly relative to list calls.

### How should I handle a 429 response?

Read the platform's own retry signal rather than applying a fixed backoff. X returns a reset timestamp, Discord and Telegram return `retry_after`, and Pinterest returns seconds until reset. Also distinguish throttles, which clear in seconds, from daily caps like Instagram's, which clear on their own window and should park the post rather than retry.

### Do rate limits and API pricing work the same way?

No, they are separate systems. Rate limits govern how frequently you may call an endpoint; pricing governs what you are charged. X is the clearest example, metering posting per call while also enforcing rate limits, so staying inside the limit does not reduce the bill.

### Are rate limits per app or per user?

It varies, and it is the detail that most often breaks agency setups. X applies both depending on token type. Meta calculates allowance from the number of users. LinkedIn tracks application and member limits separately. TikTok caps requests per user token and separately caps how many distinct users your app may publish for daily.

### Can a scheduling tool get around platform rate limits?

No, and be sceptical of anything claiming otherwise. The limits are enforced by the platforms. What a scheduling tool does is absorb the engineering: reading headers, backing off correctly, distinguishing throttles from daily caps, and spreading sends across accounts so one client's volume does not stall another's.