Every Telegram Bot API limit, in one table

Telegram's limits are scattered across the Bot API reference, the Bot FAQ, the features page and the stickers page. This table collects them with the exact wording and a link to the line that documents each one. Values were verified on 2026-08-20; Telegram changes them occasionally (poll option counts widened recently, and the Paid Broadcasts threshold is stated differently on two official pages), so treat the linked source as authoritative and this page as the index.

Start with the three separate sending throttles, because they are enforced independently and a bot can be inside two while violating the third. The per-chat throttle is roughly 1 message per second to any single chat, with short bursts tolerated. The per-group throttle caps a bot at 20 messages per minute in any one group, regardless of how slowly it sends elsewhere. The global throttle limits bulk notifications to about 30 messages per second across all chats combined, unless Paid Broadcasts is enabled. Exceeding any of them returns HTTP 429 with a retry_after value in seconds; the correct back-off is to sleep exactly retry_after for that request while a single global limiter (one token bucket shared by every worker, with per-chat and per-group budgets layered on top) slows the pipeline, since retrying early typically extends the penalty and per-worker limiters multiply your real rate. Spread large campaigns over 8-12 hours, as the FAQ suggests, rather than sprinting into the ceiling.

Size and length limits (4,096-character text, 1,024-character captions, 50 MB uploads, 20 MB downloads, 64-byte callback_data) are enforced with specific 400 descriptions, and delivery limits (HTTPS-only webhooks on four ports, 24-hour update retention, 1-100 webhook connections) decide whether updates reach you at all. Running your own local Bot API server lifts the file and webhook restrictions but not the rate limits. For the error strings these limits produce, see Telegram Bot API errors; for diagnosing a bot that has gone quiet, see Telegram bot not responding.

Telegram publishes its sending limits in the Bot FAQ rather than in the API reference, and phrases them as guidance with a hard consequence: go over and you start receiving HTTP 429 with a retry_after value in seconds — the exact handling contract is on the 429 retry after page. The three figures below are enforced independently: a broadcast that stays under 30 messages per second can still be throttled for hitting one group 21 times in a minute. The bulk figure is the one most likely to bite a notification bot at launch, and every failed send to a blocked or deactivated user still spends budget. Paid Broadcasts, enabled in @BotFather, is the only documented way above the bulk ceiling.

All character limits are counted after entities are parsed, so markup characters in MarkdownV2 or HTML do not count but visible text does. Emoji and non-Latin scripts count as one character each. Exceeding the text limit returns Bad Request: message is too long; nothing is sent or truncated, so chunking has to happen on your side, and chunking mid-entity then triggers can't parse entities on the retry. An empty or markup-only text fails the other bound with message text is empty. Captions are a quarter of the text budget, which catches bots that attach long descriptions to images.

The hosted Bot API enforces different ceilings depending on how a file reaches Telegram. Passing a URL is the most restrictive; uploading with multipart/form-data allows more; reusing a file_id of a file already on Telegram's servers has no size limit at all. Crossing a byte ceiling returns file is too big on both the sending and the getFile side, while image geometry is checked separately and fails with PHOTO_INVALID_DIMENSIONS even for small files. A URL Telegram cannot fetch fails with failed to get HTTP URL content. Running a local Bot API server removes most of these limits (2,000 MB uploads, unlimited downloads) but none of the rate limits.

Button and query limits are small and strict. The most commonly hit is callback_data, which is limited in bytes rather than characters: exceed 64 and the whole message is rejected with BUTTON_DATA_INVALID; an unparseable button URL fails the same way with BUTTON_URL_INVALID. Callback queries must also be answered promptly — wait too long and answerCallbackQuery returns query is too old while the user's spinner hangs. Telegram does not document a maximum number of buttons or rows in an inline keyboard; keep keyboards small for usability rather than relying on a specific cap.

Bot profile metadata is set through BotFather or the setMy* methods. Each field has a fixed character budget, and commands have a strict character set enforced at registration: anything outside lowercase letters, digits and underscores is rejected by setMyCommands. The username is the one value you cannot change afterwards, so check the length and the required bot suffix before creating the bot; the ID half of the token also encodes the bot, which the token checker can confirm against getMe. Clients cache the command list, so changes can take a while to appear. Command discovery and menu design for support bots is covered on the Telegram chatbot page.

Chat-level metadata has fixed budgets like bot-profile metadata, but changing it requires rights in the chat: setChatTitle and setChatDescription fail without the appropriate admin permission, and a bot restricted from writing hits have no rights to send a message for posts long before metadata calls matter. Pinning follows the same pattern: allowed everywhere in private chats, admin-right-gated in groups and channels. Forum topic names share the 128-character budget with chat titles. Addressing a chat whose ID changed after a group-to-supergroup upgrade does not fail here but with group chat was upgraded to a supergroup chat, which carries the replacement ID.

Updates are delivered either by long polling (getUpdates) or by webhook, never both: polling while a webhook is set returns 409 Conflict, and a second concurrent poller triggers terminated by other getUpdates request. The hosted API restricts webhook URLs to HTTPS on four ports — violations fail at registration with bad webhook: HTTPS url must be provided or the port-list rejection — and holds undelivered updates for 24 hours. A local Bot API server relaxes the URL, port and connection rules. Delivery-side failures are diagnosed in the webhook debugging guide.

Interactive content types have their own element counts and lengths. Poll option counts were widened in a recent Bot API update; older guides and library docstrings still say 2-10, and the API now accepts 1-12. Note that a poll, once sent, cannot be edited — only stopped with stopPoll — so an attempt to change one returns message can't be edited. Sticker geometry is published on the separate Stickers page rather than in the API reference, and it differs by format: static, animated (.TGS) and video (.WEBM) each have their own size, duration and frame-rate ceilings. Oversized sticker files fail with file is too big like any other upload.

Deletion is time-boxed for every bot: after 48 hours a message cannot be deleted by any bot regardless of rights, and the API returns message can't be deleted; deleting something already gone returns message to delete not found instead, which a delete wrapper should treat as success. Editing the bot's own messages has no documented time limit, but editing anything the bot did not send fails with message can't be edited, and re-submitting identical content fails with message is not modified. Beyond those rules, chat permissions decide what is possible, which is why the same call can succeed in one group and fail in another.