Telegram Bot API Rate Limits at Scale: What Breaks (and How to Stay Under)

Telegram Bot API Rate Limits at Scale: What Breaks (and How to Stay Under)

TL;DR. Telegram's Bot API caps individual chats at roughly 1 message per second, broadcasts at 30 messages per second across different chats, and channels or groups at about 20 messages per minute. Cross any limit and you receive HTTP 429 with a parameters.retry_after value in seconds — your job is to honor it, queue everything else, and never burst. Photo uploads top out at 10 MB when uploaded as multipart (5 MB when Telegram fetches from a URL), and general file uploads at 50 MB on the public Bot API.

Run high-volume Telegram channels and want the queueing handled for you? See how Autogram batches at scale.

What the Bot API limits actually are

Photo by Brett Sayles on Pexels

Telegram publishes the headline numbers in its Bot API FAQ on broadcasting, and the numbers are easier to memorize than to obey at scale:

The two limits worth tattooing on your wrist are 20 messages per minute to the same channel (the editorial throughput cap) and 30 messages per second across different chats (the audience-broadcast cap). Long-running deployments trip the channel cap first because that's where editorial volume concentrates; broadcast bots trip the cross-chat cap first because audience growth pulls them past it without warning.

These aren't the only constraints. Anything that mutates message state — editMessageText, deleteMessage, forwardMessage, copyMessage, setMessageReaction — counts toward your send budget. Inline-mode bots have a separate set of latency constraints documented under answerInlineQuery, and they're enforced by user-facing timeouts rather than HTTP 429s.

How throttling works in practice

Photo by RDNE Stock project on Pexels

When you cross a limit Telegram returns HTTP 429 Too Many Requests with a JSON body that, per the making-requests reference, includes a parameters.retry_after integer in seconds. A real response looks like:

{
  "ok": false,
  "error_code": 429,
  "description": "Too Many Requests: retry after 17",
  "parameters": { "retry_after": 17 }
}

There are three correct things to do, in order:

1. Stop sending to the throttled scope immediately. If the 429 was on a single channel, freeze writes to that channel only — don't pause your whole worker pool.
2. Sleep retry_after seconds plus a small jitter (200–500 ms). Without jitter, every worker resumes on the same tick and re-trips the limit.
3. Retry the exact same request. Telegram's idempotency model assumes the failed call did not produce a message; a successful retry will not duplicate.

Most production libraries already do this. aiogram and python-telegram-bot ship RetryAfter exception handlers, and the pyrogram queue does the same implicitly. What they will not do is predict the limit — they react to the 429 after the fact. At scale that costs you a small wave of failed requests on every burst, which is why the next section matters.

Batching strategies that stay under the cap

Three patterns cover roughly 95% of high-volume Telegram automations:

1. Token-bucket per scope. Keep an in-memory bucket per chat ID and a global bucket sized to 30 tokens with a 1-second refill. Refuse to send a message until the bucket has a token. This eliminates the 429 bursts entirely. Redis-backed buckets work across worker pools; a single-process bot can use asyncio-throttle or equivalent.

2. Media groups instead of loops. A sendMediaGroup call posts up to 10 photos or videos as a single album and counts as one request against your channel cap. A 50-image rollout drops from 50 messages (which is impossible — it would require two and a half minutes of careful pacing on a single channel) to 5 albums, comfortably under the per-minute cap. The same logic applies whenever the API allows you to collapse N calls into one envelope.

3. Editorial smoothing. If your scheduler tries to fire 100 channel posts at 09:00 sharp, no client-side limit math will save you — you'll burst against Telegram's edge before your token-bucket even decrements. Spread the queue across the hour at runtime, or move ahead of time to staggered slots. Two-minute spacing between same-channel writes is a safe default; one-minute is the floor before you start eating into the 20-per-minute cap on a busy channel.

At-scale architecture patterns

Photo by Keysi Estrada on Pexels

Once a single bot is sending more than ~100k messages a day, four architectural decisions stop being optional:

• One token, one outbound queue. All sends route through a single FIFO queue per bot token. Multiple workers can dequeue, but the throttle decision must be central — distributed token-bucket math beats per-worker guessing every time.
• Self-host the Bot API server for high-traffic accounts. Telegram open-sources the TDLib-based local Bot API server. It removes the 50 MB upload cap (raising it to 2 GB), reduces median latency, and gives you full control over connection pooling and webhook routing.
• Separate broadcast bots from interactive bots. Broadcasts that burst against the 30/sec cap should not share a token with the bot answering /start or running an inline-mode handler. A throttled token is a throttled token — split them and treat the broadcast token as a write-only worker.
• Observability for retry_after. Counter the number of 429s per minute and the rolling average retry_after. A healthy fleet sees a flat near-zero line; a creeping average means your token-bucket sizing is drifting away from real Telegram capacity, and the platform is doing the back-pressure your scheduler should be doing.

If you're using a managed scheduler — Autogram included — most of this lives behind the API and you don't write any of the queueing yourself. The reason to read the section anyway is to know what the underlying budget is, so when a customer asks "why did the 09:00 wave land at 09:04 instead?" you have the right answer instead of a shrug.

Related reading

• Bulk Telegram Messaging Automation: A Power-User Guide — how to schedule high-volume rollouts without tripping flood control.
• Telegram Auto Post Without the Forwarded Tag — the copyMessage route, which counts against your budget the same way sendMessage does.
• No-Code Telegram Automation Comparison — how Zapier, Make, and ManyBot handle (or quietly hide) the rate-limit ceiling.

FAQ

What does "Telegram bot 429 error" actually mean?

It means a request you sent crossed one of Telegram's per-scope rate limits. The response body carries parameters.retry_after in seconds; sleep that long, then retry the exact same request. Treat 429 as load-shedding, not as a permanent failure.

Is Telegram flood control the same as the Bot API rate limit?

No. "Flood control" in the Telegram client and userbot world refers to MTProto-level limits that escalate to temporary bans on the account. Bot API rate limits are gentler, scope-specific, and reset within seconds. The 429 plus retry_after envelope is unique to the Bot API.

How many messages can a Telegram bot send per second?

Up to 30 across different chats (broadcast scope), and roughly 1 per second to a single chat. Same-channel writes are capped at about 20 per minute, which works out to one every 3 seconds on a sustained schedule.

Can I increase my Telegram bot's rate limit?

Yes, for broadcasts. Telegram's Paid Broadcasts feature (enabled via @BotFather) lifts the 30-messages-per-second broadcast cap up to 1,000 messages per second; each message above the free 30/sec costs 0.1 Telegram Stars, and the bot must hold a balance of at least 10,000 Stars. The non-broadcast caps (1/sec per chat, 20/min per channel) stay fixed. Self-hosting the local Bot API server raises the file-upload cap to 2 GB but does not raise message-send caps.

How do I avoid hitting the Bot API rate limit?

Run a token-bucket per scope (chat, channel, global), batch with sendMediaGroup where you can, smooth bursty editorial queues across the hour, and instrument 429s so you spot drift before users do.

What happens if I keep ignoring the 429 retry_after?

Telegram increases the back-off and may temporarily disable the bot token. Sustained ignoring gets you in front of the platform team — a worse problem to have than the original throughput one.

Does sendMediaGroup count as one message or many?

One. A media group is a single Bot API call regardless of whether it carries 2 or 10 attachments, which is exactly why it's the most reliable lever for staying under the per-minute channel cap.

Bottom line

Telegram's Bot API limits are gentle, well-documented, and reset within seconds — but every production bot eventually hits them, usually at 09:00 on launch day. Build a token-bucket, honor retry_after, batch with media groups, and route broadcasts through a separate token. Autogram does all of this for you so the only number you have to think about is "how many channels."

Image credits

• Hero: Photo by Brett Sayles on Pexels.
• Inline #1: Photo by RDNE Stock project on Pexels.
• Inline #2: Photo by Keysi Estrada on Pexels.