Telegram Bot API Limits and How to Stay Under Them

Telegram is generous with bots, but it does enforce limits. Most bots never notice them. Then a bot grows, someone builds a broadcast feature, and suddenly messages fail with 429 Too Many Requests. This article lists the limits that matter in practice and shows how to design around them.

Sending limits

Telegram doesn’t publish a precise rate table for every method, but its FAQ gives clear guidance for sending messages:

Short bursts above these rates are sometimes tolerated; sustained traffic above them isn’t. For very large broadcasts, Telegram also offers a paid broadcast option that raises the throughput limit for a fee in Telegram Stars — check the current Bot API documentation if you need it.

What a 429 looks like

When you exceed a limit, Telegram responds with error 429 and tells you how long to wait:

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

The right response is simple: wait retry_after seconds, then retry. Retrying immediately, or in a tight loop, keeps you rate-limited for longer.

Libraries can do this for you:

• grammY — the @grammyjs/auto-retry plugin.
• aiogram — catch TelegramRetryAfter and sleep for exception.retry_after.
• Telegraf / telebot — catch the 429 error and read retry_after from its parameters.

Content limits

These are fixed limits in the Bot API. Hitting them produces a 400 Bad Request, not a 429:

The file limits apply to the public Bot API server. Running your own local Bot API server raises them substantially (up to 2,000 MB uploads), which some media bots do. See handling files and media in Telegram bots.

Designing a safe broadcast

Broadcasting — sending an announcement to every user — is where most bots hit limits. A safe broadcast:

1. Queues messages rather than sending them all at once.
2. Paces sending below ~30 messages per second (25 leaves headroom for normal traffic).
3. Honours retry_after on 429 and pauses the whole queue, not just one message.
4. Handles blocked users. A 403 Forbidden: bot was blocked by the user is permanent — mark the user inactive and stop sending to them.
5. Records progress so a restart resumes rather than starting over (and messaging everyone twice).

A compact asyncio example with aiogram:

import asyncio
from aiogram.exceptions import TelegramForbiddenError, TelegramRetryAfter

async def broadcast(bot, user_ids, text, per_second=25):
    delay = 1 / per_second
    sent = failed = 0
    for uid in user_ids:
        while True:
            try:
                await bot.send_message(uid, text)
                sent += 1
                break
            except TelegramRetryAfter as e:
                await asyncio.sleep(e.retry_after)
            except TelegramForbiddenError:
                await mark_inactive(uid)
                failed += 1
                break
        await asyncio.sleep(delay)
    return sent, failed

For large audiences, persist the queue (user ID and status) in your database, and run the broadcast as a background job so the bot keeps answering users meanwhile. See scheduling messages and background jobs.

Avoid limits in everyday features

• Edit instead of send. For progress updates or live status, edit one message rather than sending new ones — but don’t edit more than every second or two.
• Combine messages. One message with several lines is better than several one-line messages, especially in groups.
• Answer callback queries. It doesn’t count as a chat message, and it stops the loading spinner.
• Use sendMediaGroup to send up to ten photos or videos as one album instead of ten separate messages.
• Throttle per user. A middleware that ignores a user’s commands for a moment after each one prevents a single person from pushing your bot into limits. aiogram and grammY both make this easy.

Group-specific behaviour

Bots in groups have extra considerations:

• The 20-messages-per-minute guidance per group is the one busy group bots hit first. Batch replies and avoid echoing every message.
• Privacy mode, on by default, means a bot in a group only receives commands, replies to its messages and messages that mention it. That reduces the updates your bot has to process. Disable it with BotFather’s /setprivacy only if your bot genuinely needs to see every message.

Network limits on your side

Your hosting matters too. Every API call is a round trip to Telegram, so latency adds up during bursts and broadcasts. Kerit Cloud’s Telegram bot hosting runs under 40 ms from the Telegram API at the Virginia edge, so paced sends spend their time on the pacing you chose, not on the network.

Frequently asked questions

Do limits apply per bot or per server IP? Telegram’s sending limits apply per bot. Running two bots doesn’t share one bot’s allowance, and moving to a different server doesn’t reset it.

Will Telegram ban my bot for hitting 429s? Occasional 429s handled with a proper wait are normal and harmless. Ignoring retry_after and hammering the API, or sending unsolicited bulk messages that users report as spam, is what gets bots restricted.

Are replies to commands limited the same way? Yes — every message your bot sends counts, whether it’s a reply or an announcement. Replies to individual users rarely approach the per-chat limit, though, because humans can’t send commands fast enough.

How do I know how close I am to the limits? Log every 429 with the method and chat, and count messages sent per minute. If 429s appear during normal operation rather than only during broadcasts, a feature is sending too much.

Does webhook vs polling change the limits? No. Limits apply to what your bot sends, not to how it receives updates.

Summary

Keep to about one message per second per chat, twenty per minute per group and thirty per second across all users. On a 429, wait exactly retry_after seconds. Respect content limits — 4,096-character messages, 1,024-character captions, 64-byte callback data, 50 MB uploads — and build broadcasts as paced, resumable background jobs that drop users who blocked the bot. Do that, and rate limits stop being something your users ever see.