How to fix the "Too Many Requests" error

The "Too Many Requests" error (HTTP 429) in Telegram means you've exceeded the platform's rate limits — the built-in throttling mechanism that prevents API abuse and ensures fair usage for all users. Fixing it requires understanding which specific limit you've hit, waiting the appropriate cooldown period, and adjusting your behavior to avoid triggering it again.

What Causes the "Too Many Requests" Error

Telegram enforces strict rate limits across its Bot API, Client API (TDLib/MTProto), and even regular user actions. When you send too many requests within a short timeframe, the server responds with a 429 Too Many Requests status code and a retry_after parameter telling you how many seconds to wait.

Common Triggers

  • Sending messages too fast — bots are limited to approximately 30 messages per second globally and 1 message per second to the same chat
  • Bulk operations — adding members, editing messages, or deleting posts in rapid succession
  • Frequent API polling — calling getUpdates or other methods without proper intervals
  • Forwarding sprees — forwarding many messages from or to channels quickly
  • Joining/leaving groups rapidly — Telegram flags this as suspicious behavior
  • Inline bot queries — handling too many inline results without throttling

Rate Limits by Context

Action Approximate Limit Cooldown Messages to same chat ~20 per minute 1-60 seconds Messages to different chats ~30 per second Varies Bulk notifications ~30 users per second Increases with violations Group/channel actions ~20 per minute 1-15 minutes Editing messages ~30 per minute per chat 30-60 seconds File uploads ~10 per minute per bot 60 seconds

Important: Telegram does not publish official rate limit numbers. These are community-observed approximations and may change without notice. Always rely on the retry_after value returned in the error response.

Step-by-Step Fix for Bot Developers

Step 1: Read the retry_after Value

Every 429 response includes a retry_after field in seconds. This is the minimum time you must wait before retrying.

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

Parse this value and implement a sleep/delay for at least that duration before making the next request.

Step 2: Implement Exponential Backoff

Rather than retrying immediately after the cooldown, use exponential backoff to gradually increase delays:

  1. First retry: Wait the retry_after value (e.g., 35 seconds)
  2. Second retry: Double the wait time (70 seconds)
  3. Third retry: Double again (140 seconds)
  4. Cap the maximum at 5-10 minutes to avoid infinite delays

This approach signals to Telegram's servers that your application is behaving responsibly.

Step 3: Add a Message Queue

Instead of sending messages directly, push them into a queue and process them at a controlled rate:

  • Set a global limit of no more than 25-28 messages per second
  • Set a per-chat limit of 1 message every 3 seconds for safety margin
  • For group chats and channels, limit to 15-18 messages per minute per chat
  • Process the queue with consistent spacing between sends

Step 4: Use Webhooks Instead of Polling

If you're using getUpdates (long polling), switch to webhooks. Polling requires repeated API calls that count toward your rate limit. Webhooks let Telegram push updates to your server, eliminating unnecessary requests entirely.

Step 5: Batch Operations Where Possible

When you need to edit or delete multiple messages, space operations at least 1-2 seconds apart. For bulk notifications to many users, process them in batches of 25-30 with a 1-second pause between batches.

Fixing the Error for Regular Users

If you encounter "Too Many Requests" as a regular Telegram user (not a developer), the causes and solutions differ.

Scenario 1: Joining Too Many Groups/Channels

Telegram limits how many groups or channels you can join in a short period. If you hit this limit:

  • Wait 24 hours before attempting to join more groups
  • Join groups gradually — no more than 5-10 per hour
  • If you were recently reported for spam, the restriction may last longer

Scenario 2: Sending Too Many Messages

Rapid-fire messaging, especially in multiple chats, can trigger throttling:

  • Slow down your messaging pace
  • Avoid copy-pasting the same message to multiple chats (Telegram flags this as spam)
  • Wait 15-30 minutes if you get the error, then resume at a normal pace

Scenario 3: Forwarding Content in Bulk

Forwarding messages to many chats simultaneously is a common trigger:

  • Limit forwarding to 5-10 chats at a time
  • Wait at least 30 seconds between batches
  • Consider using a channel and sharing the link instead of forwarding

Understanding FloodWait in MTProto/TDLib

If you're working with the full Telegram Client API (MTProto), the error appears as a FLOOD_WAIT_X exception, where X is the number of seconds to wait. These limits are generally stricter:

  • Account-level limits apply across all sessions
  • Method-specific limits vary by API call type
  • Repeated violations result in exponentially longer cooldowns — from seconds to hours or even days
  • channels.getParticipants, messages.search, and contacts.resolveUsername are particularly strict

For services like tgchannel.space that interact with Telegram channel data, respecting these rate limits is essential for maintaining reliable synchronization and content delivery.

Tips & Best Practices

  • Always respect retry_after: Never ignore or bypass this value. Repeatedly hitting the limit without waiting will result in increasingly longer bans, potentially lasting hours or days
  • Build in safety margins: If the observed limit is 30 messages/second, target 20-25 to account for fluctuations and shared limits across your bot's operations
  • Log all 429 responses: Track when and where rate limits occur to identify which operations need better throttling. Include timestamps, chat IDs, and method names
  • Use separate bots for separate tasks: If you have a bot that both sends notifications and processes commands, consider splitting into two bots to get independent rate limits
  • Cache API responses: Store results from methods like getChat, getChatMember, or getFile locally instead of calling the API repeatedly for the same data
  • Implement circuit breakers: If you receive multiple 429 errors in a short period, temporarily halt all non-critical API calls rather than continuing to hit limits on other endpoints
  • Monitor across instances: If you run multiple instances of your bot, they share the same rate limit. Coordinate request rates across all instances through a shared rate limiter (e.g., Redis-based)

Common Mistakes

Mistake 1: Retrying immediately after the error
Why it's wrong: Sending another request before the retry_after period expires resets or extends your cooldown, making the problem worse.
How to avoid: Always parse and respect the retry_after value. Add a small buffer (2-5 seconds extra) for safety.

Mistake 2: Using fixed delays instead of dynamic throttling
Why it's wrong: A hardcoded sleep(1) between messages may work today but fail tomorrow if Telegram adjusts limits or your traffic increases.
How to avoid: Implement adaptive rate limiting that responds to actual 429 errors and adjusts dynamically.

Mistake 3: Sending identical messages to many chats
Why it's wrong: Telegram's anti-spam system specifically watches for identical content sent to multiple recipients. This triggers stricter limits than varied messages.
How to avoid: If you must broadcast, use slight variations or, better yet, use a Telegram channel and share its link.

Mistake 4: Not distinguishing between per-chat and global limits
Why it's wrong: You might be under the global limit but over the per-chat limit, or vice versa. Treating them as one limit leads to inefficient throttling or continued errors.
How to avoid: Track request counts both globally and per individual chat. Enforce both limits independently.

Mistake 5: Ignoring rate limits during development/testing
Why it's wrong: Rapid test iterations with real API calls can get your bot token flagged, and those restrictions carry into production.
How to avoid: Use Telegram's test environment (api.telegram.org/bot<token>/test) when available, and always include rate limiting logic even in development builds.

Frequently Asked Questions

How long does a "Too Many Requests" ban last?
The ban duration is specified in the retry_after field and typically ranges from 5 seconds to several minutes for first offenses. Repeated violations can escalate to hours or even days. There is no permanent ban from rate limiting alone, but persistent abuse may lead to a full account or bot restriction.

Can my bot get permanently banned for hitting rate limits?
Rate limiting alone won't cause a permanent ban, but consistently aggressive behavior combined with user reports could lead Telegram to revoke your bot token. If your bot regularly triggers 429 errors, it's a signal to fundamentally redesign your request patterns.

Does each bot token have its own rate limit?
Yes, rate limits are applied per bot token. However, if multiple bots operate from the same IP address, there may be additional IP-level throttling. Running multiple bots on the same server does not multiply your combined allowed throughput linearly.

Is there a way to request higher rate limits from Telegram?
Telegram does not offer official rate limit increases for standard bots. However, bots verified through @BotFather with a large legitimate user base may receive slightly more favorable treatment. For very high-volume use cases, consider the Telegram Bot Payments API documentation or reaching out to Telegram's support for business accounts.

Does using webhooks vs. polling affect rate limits?
Webhooks eliminate the overhead of getUpdates calls, which count toward your rate limit. Switching to webhooks frees up request capacity for actual operations like sending messages. This alone can resolve 429 errors for bots that poll frequently.