Social media API rate limits: Meta, TikTok, Telegram and LinkedIn
Every platform counts limits differently. Meta counts per app, per user and per business object (BUC) over hourly or 24-hour windows and reports usage in response headers. TikTok counts each endpoint over a sliding one-minute window. Telegram bots are limited per chat and get retry_after with a 429. LinkedIn uses daily app and member limits. The durable fix: webhooks, queues, caching and backoff with jitter.
Updated:
What is an API rate limit, and why isn't "wait and retry" enough?
A rate limit is the request volume a platform accepts within a window — a second, minute, hour, 24 hours or a day. When you exceed it, Meta returns codes 4/17/32/613 or 800xx, TikTok, the Telegram Bot API and LinkedIn return HTTP 429, and Telegram MTProto returns FLOOD_WAIT. With hourly or daily windows, fast retries just burn quota — you need a queue to shape the load.
Rate-limit models by platform
Figures from official docs as of 2026-09-17. Many are formulas or defaults — your app's actual quota may differ.
| Platform / API | How it's counted | Window | When exceeded |
|---|---|---|---|
| Meta platform limit | App: 200 × number of users; per-user limits are not published | 1 hour | Code 4 (app), 17 (user) |
| Facebook Pages (BUC) | 4800 × number of engaged users of the Page | 24 hours | 80001 (Page/system user token); 32 (user/app token) |
| Instagram Platform (BUC) | 4800 × number of impressions | 24 hours | 80002 |
| Instagram publishing | 100 API-published posts per account; a carousel counts as one | Moving 24 hours | Check with content_publishing_limit |
| Instagram messaging | Send API: text 100/s, audio/video 10/s; Conversations API 2/s — per professional account | 1 second | no |
| Lead Ads (BUC) | 4800 × number of leads generated | 24 hours | 80005 |
| Marketing API (BUC) | Ads Management: 300 + 40 × active ads (Standard Access) | 1 hour | 80004 |
| TikTok API v2 | Per endpoint; user/info, video/list, video/query default to 600 | Sliding 1 minute | HTTP 429, rate_limit_exceeded |
| TikTok posting | video/init 6/min per user token; status/fetch 30/min; typically ~15 posts/day per creator | 1 minute / 24 hours | spam_risk_too_many_posts |
| Telegram Bot API | ~1 message/s per chat; 20 messages/min per group; ~30 messages/s broadcast | Second / minute | HTTP 429 + retry_after |
| Telegram MTProto | Numbers not published | no | 420 FLOOD_WAIT_X |
| Daily app and member limits; numbers shown in the Developer Portal | Day (resets 00:00 UTC) | HTTP 429 |
yesnoScroll the table sideways
What do Facebook API errors 4, 17, 32, 613 and 800xx mean?
| Code | Meaning | What to do |
|---|---|---|
| 4 | App-level rate limit | Watch X-App-Usage, pause background calls |
| 17 | User-level rate limit | Slow the queue for that token |
| 32 | Pages API limit (with a user or app token) | Use a Page token and watch the BUC header |
| 613 | Custom rate limit; subcode 1996 means sudden traffic change | Spread requests evenly over time |
| 80001 / 80002 | BUC: Pages / Instagram | Wait out estimated_time_to_regain_access for that object |
| 80004 / 80000 | BUC: Ads Management / Ads Insights | Request reports less often, over larger ranges |
| 80005 / 80006 | BUC: LeadGen / Messenger | Rely on webhooks, remove polling |
Source: Meta Graph API Rate Limiting and Error Handling docs.
Meta usage headers: X-App-Usage and X-Business-Use-Case-Usage
Meta warns you before you hit the wall. X-App-Usage carries call_count, total_cputime and total_time — percentages of the app's quota used. X-Business-Use-Case-Usage is JSON keyed by business object ID: each entry has a type (pages, instagram, ads_management, ...), the same three percentages and estimated_time_to_regain_access, the minutes until throttling lifts.
Calls may be throttled when a value reaches 100. A practical rule: slow background work from 75–80% and stop at 95%. When both limit types apply to a call, the BUC limit wins. Several IDs in one request count as separate calls.
Reading the BUC header (plain aiohttp)
The Socialift SDK does not expose response headers on its error objects, so for proactive quota control you can inspect Graph API responses like this.
import json
import aiohttp
async def graph_get(session: aiohttp.ClientSession, url: str, params: dict) -> dict:
async with session.get(url, params=params) as r:
usage = json.loads(r.headers.get("X-Business-Use-Case-Usage") or "{}")
for object_id, items in usage.items():
for u in items:
peak = max(u.get("call_count", 0), u.get("total_cputime", 0), u.get("total_time", 0))
if peak >= 80:
await slow_down(object_id, u.get("type"),
minutes=u.get("estimated_time_to_regain_access", 0))
return await r.json()slow_down is your function: it pauses the queue for that Page or Instagram account.
Instagram API rate limit: 100 posts and messaging throughput
Instagram Platform calls count under BUC: 4800 × the account's impressions per 24 hours, so small accounts get small quotas — cache insights instead of polling.
Publishing has its own cap: an account can publish up to 100 posts via the API in a moving 24-hour window, and a carousel counts as one. GET /<IG_ID>/content_publishing_limit shows current usage. In the SDK, publishing is ig.publish(...) and ig.publish_carousel(...).
Direct messaging has per-second limits: messages with text, links, reactions and stickers — 100 calls/s per professional account; audio and video — 10/s; the Conversations API — 2/s. Rely on the messages webhook rather than re-reading conversation lists.
TikTok API rate limit: endpoint limits and the daily post cap
TikTok enforces limits separately for each endpoint over a sliding one-minute window. The documented defaults are 600 for /v2/user/info/, /v2/video/query/ and /v2/video/list/. Exceeding them returns HTTP 429 with rate_limit_exceeded; for higher limits TikTok points you to its support page.
The Content Posting API has its own limits: /v2/post/publish/video/init/ allows 6 requests per minute per user access token, creator_info 20 and status/fetch 30. Direct Post also has a per-creator daily cap (typically around 15 posts per day, shared across all API clients); hitting it returns spam_risk_too_many_posts, which no retry will fix — defer to the next day.
An unaudited client can post for at most 5 users in 24 hours, only with SELF_ONLY visibility. In the SDK, call tt.creator_info(token) before posting.
Telegram Bot API limits: 429, retry_after and broadcasts
The Telegram Bot FAQ says: avoid sending more than one message per second to a single chat (short bursts are tolerated, but 429 errors eventually follow); in a group a bot cannot send more than 20 messages per minute; broadcasts top out at about 30 messages per second.
When you exceed a limit, the response has ok: false, error_code: 429 and parameters.retry_after — the seconds to wait. Retrying sooner is pointless. Queue large broadcasts and send below 30 messages per second.
With paid broadcasts enabled in @BotFather, a bot can send up to 1000 messages per second; every message above the free 30 per second costs 0.1 Telegram Stars. Enabling it requires at least 100,000 Stars on the bot's balance and at least 100,000 monthly active users.
Telegram user accounts (MTProto) have no published numbers: exceeding a limit returns 420 FLOOD with FLOOD_WAIT_X (wait X seconds). The SDK's TelegramAccount turns this into RateLimitError with retry_after but does not sleep for you — the decision is yours.
Where do you see LinkedIn API rate limits?
LinkedIn applies two daily limits: the application limit (total calls your app can make per day) and the member limit (calls one member can make through your app). Both reset at midnight UTC, and exceeding them returns 429.
Standard limits are not published in the documentation: you see them in the Developer Portal under your app's Analytics tab (only for endpoints called at least once that day). Admins get an email when the app passes 75% of its limit, with a 1–2 hour delay.
The Community Management API development tier is tight: 500 calls per app and 100 per member per 24 hours. Production traffic needs the standard tier.
Building a rate-limit-resilient integration in 6 steps
Webhooks instead of polling
Receive comments, messages, leads and post status via webhooks (Meta, TikTok, Telegram setWebhook). Polling wastes quota.
Queue per token and account
Limits are counted per token, Page or account — give each its own queue and concurrency cap.
Cache
Store slow-changing data such as profiles, Page lists and insights with a TTL; request only the fields you need.
Exponential backoff with jitter
On a transient error, double the delay each attempt and add randomness so workers don't come back in lockstep.
Honour the platform's clock
Telegram retry_after, Meta estimated_time_to_regain_access and MTProto FLOOD_WAIT override your backoff formula.
Separate non-retryable errors
A daily post cap, missing permission (PermissionError) or invalid token (AuthError) should not go back on the queue — record the state and notify.
Socialift SDK: RetryPolicy and RateLimitError
By default the SDK makes 3 attempts in total. In a background worker it is often better to reduce in-SDK retries and let the queue decide how long to wait.
import os
from socialift import ApiError, Instagram, RateLimitError, RetryPolicy
policy = RetryPolicy(attempts=2, backoff_base=1.0, backoff_max=20.0, jitter=True)
async def publish_job(job: dict) -> None:
async with Instagram.via_facebook(app_secret=os.environ["META_APP_SECRET"],
retry=policy) as ig:
try:
await ig.publish(job["page_token"], ig_user_id=job["ig_user_id"],
image_url=job["image_url"], caption=job["caption"])
except RateLimitError as exc:
await requeue(job, delay=exc.retry_after or 15 * 60)
except ApiError as exc:
if exc.code in (80001, 80002): # BUC — 24-hour window
await requeue(job, delay=60 * 60)
else:
raiseDefault RetryPolicy: 3 attempts, delay min(0.5 × 2^(n−1), 30) seconds multiplied by a random 0.5–1.5 factor (jitter). Retries apply to RateLimitError, HTTP 429/500/502/503/504 and network errors; when retry_after is known, the SDK waits exactly that long.
The SDK maps Meta codes 4, 17, 32, 613 and HTTP 429 to RateLimitError. BUC codes (80001, 80002, ...) are not in that list — check them via ApiError.code.
Frequently asked questions
What is the Instagram API rate limit?
Instagram Platform calls are counted under BUC: 4800 × the account's impressions per 24 hours. Publishing has a separate cap of 100 API-published posts in a moving 24-hour window, with a carousel counting as one post.
What do Facebook API errors 4, 17, 32 and 613 mean?
4 is the app-level limit, 17 the user-level limit, 32 the Pages API limit with a user or app token, and 613 a custom limit (subcode 1996 signals a sudden traffic change). All are transient: reduce request volume and watch the usage percentages in the headers.
How many messages per second can a Telegram bot send?
Per the official FAQ: no more than one per second to a single chat, 20 per minute to a group and about 30 per second for broadcasts. With paid broadcasts, up to 1000 per second, and each message above the free 30 costs 0.1 Stars.
What are the TikTok API rate limits?
A sliding one-minute window per endpoint: user/info, video/list and video/query default to 600. Post initialisation (video/init) allows 6 per minute per user token. Exceeding a limit returns HTTP 429 with rate_limit_exceeded.
Where can I see my LinkedIn API limits?
Standard limits are not published in the docs. Your app's Analytics tab in the Developer Portal shows daily limits and usage per endpoint. Limits reset every day at 00:00 UTC.
Can I retry immediately after a 429?
No. If the platform tells you how long to wait (retry_after, estimated_time_to_regain_access), wait that long. If not, use exponential backoff with jitter. In hourly or daily windows, fast retries only burn quota.