Telegram Bot API Rate Limits Explained (2026): Free Usage, 429 Errors & How to Scale

Sooner or later every growing Telegram bot hits the same wall: messages stop going out, the logs fill with 429 Too Many Requests, and users start asking why the bot "stopped working". The cause is almost never a bug in Telegram — it is the Bot API's flood limits, which are generous for normal use but very easy to hit the moment you broadcast to a few thousand users at once.

This guide explains every limit that matters in plain English: whether the API is actually free, how many messages you can send per second, what the 429 error is telling you, and the techniques that let a bot deliver to tens of thousands of users without getting throttled.

Is the Telegram Bot API Free?

Yes — completely. Telegram does not charge for creating bots, for API requests, or per message sent. There is no paid tier that unlocks "more API", and there is no monthly quota that runs out. This is one of the biggest reasons businesses choose Telegram over WhatsApp, where the Business Platform bills per conversation.

What you do pay for is everything around the API: hosting the bot, a database, any third-party services it calls (an AI model, a payment provider, an exchange API) and, if you need it, Telegram's optional paid broadcasts, which are billed in Telegram Stars. For a full cost breakdown, see our guide to Telegram Bot API pricing.

Every Telegram Bot API Limit That Matters

Telegram publishes its messaging limits as guidelines in the official Bot FAQ rather than as hard, documented quotas, and they can be adjusted over time. In practice these are the numbers to design around:

The per-chat and per-group limits exist to stop bots from spamming people. The global ~30 messages per second limit is the one that bites when you announce something to your whole user base — 10,000 users at 30 messages per second takes about 5.5 minutes, and trying to do it faster is exactly what produces a flood of 429 errors.

What the 429 "Too Many Requests" Error Means

When your bot sends faster than Telegram allows, the API answers with HTTP status 429 and a JSON body like this:

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

The important field is retry_after: the number of seconds you must wait before that request will be accepted. Retrying immediately does not help — it can lengthen the penalty. The correct behaviour is to pause, then retry the same message, and to treat repeated 429s as a signal that your overall sending rate is too high.

Here is a minimal, dependency-light Python example that respects retry_after:

import time
import requests

API = f"https://api.telegram.org/bot{TOKEN}"

def send_message(chat_id, text, max_attempts=5):
    for _ in range(max_attempts):
        r = requests.post(f"{API}/sendMessage",
                          json={"chat_id": chat_id, "text": text}, timeout=30).json()
        if r.get("ok"):
            return r["result"]
        if r.get("error_code") == 429:
            time.sleep(r["parameters"]["retry_after"] + 1)  # wait, then retry
            continue
        raise RuntimeError(r.get("description"))
    raise RuntimeError("Gave up after repeated rate limiting")

How to Broadcast to Thousands of Users Without Getting Throttled

Handling 429 errors is the safety net. The real fix is to never trigger them in the first place. These are the patterns we use on production bots:

1. Put every outgoing message through a queue

Instead of sending directly from your request handlers, push messages into a queue (Redis, a database table, or an in-memory queue for small bots) and have one worker drain it at a controlled pace. This turns "send 10,000 messages now" into a steady stream Telegram is happy with.

2. Throttle globally and per chat

Cap the worker at roughly 25 messages per second overall — leaving headroom under the ~30 guideline — and track the last send time per chat so no single user or group receives more than one message per second (or 20 per minute in groups). A simple token-bucket limiter does this in a few lines.

import time

GLOBAL_RATE = 25          # messages per second, safely under ~30
last_sent_per_chat = {}

def broadcast(chat_ids, text):
    for chat_id in chat_ids:
        wait = 1.0 - (time.time() - last_sent_per_chat.get(chat_id, 0))
        if wait > 0:
            time.sleep(wait)                  # per-chat: max 1 msg/second
        send_message(chat_id, text)           # retries on 429 (see above)
        last_sent_per_chat[chat_id] = time.time()
        time.sleep(1 / GLOBAL_RATE)           # global pacing

3. Spread big announcements over time

Telegram's own guidance is to spread mass notifications over a longer window rather than sending them in one burst. Announcements rarely need to land within the same minute — sending to 50,000 users over 30 to 60 minutes is perfectly acceptable and keeps you far from the limits.

4. Edit instead of sending new messages

Live dashboards, price tickers and progress updates should edit one message with editMessageText rather than posting a new message every few seconds. It is better for users and keeps per-chat traffic low.

5. Use paid broadcasts when speed really matters

Telegram added paid broadcasts to the Bot API: eligible bots can send up to 1,000 messages per second by setting allow_paid_broadcast, paying a small fee in Telegram Stars for each message above the free limit. Telegram sets eligibility requirements (a minimum Stars balance and a minimum number of monthly active users), so check the current Bot API documentation before building around it. For most bots, a well-paced queue is enough.

Can You Get "No Rate Limits" for Personal Use?

This is one of the most searched questions about the Bot API, and the honest answer is no. There is no personal-use mode, paid plan or special request that removes the messaging limits for a bot. A few things are often confused with it:

• A local Bot API server (Telegram's open-source telegram-bot-api) raises the file limits to 2,000 MB and lets you use webhooks on any port — but it does not lift the messaging flood limits.
• Userbots built on the MTProto client API (Telethon, Pyrogram) have their own, stricter flood-wait limits and can get the account restricted if used for mass messaging.
• Multiple bot tokens spread across one audience to "multiply" the limit tends to get bots reported and limited — it is not a sustainable strategy.

If your use case genuinely needs high throughput — large communities, trading signal channels, real-time alerts — the right answer is a proper queueing architecture, sensible batching and, where it fits, paid broadcasts.

Polling vs Webhooks: Does It Affect Limits?

The way your bot receives updates — long polling with getUpdates or a webhook — does not change the sending limits. Webhooks are still the better choice in production: updates arrive instantly, you can run the bot on serverless platforms, and Telegram can deliver updates over several parallel connections (configurable with max_connections in setWebhook). See our guide on where to host a Telegram bot for how this affects hosting costs.

The Bottom Line

The Telegram Bot API is free and its limits are generous — but they are real. Design around one message per second per chat, 20 per minute per group and roughly 30 per second overall, always honour retry_after, and route outgoing messages through a paced queue. Do that from day one and your bot will scale from a hundred users to a hundred thousand without users ever noticing a slowdown.

Planning a bot that will message a large audience? Read how much Telegram bot development costs, or see how to grow your Telegram bot once it is live.

Frequently Asked Questions