Telegram API ліміти — що це означає для вашого бота і як Leadmlyn з ними справляється

Уявіть: ви відкриваєте реєстрацію на популярний захід — і за 5 хвилин 40 людей пишуть боту одночасно. Що відбудеться? Чи витримає Telegram? Чи впаде бот? Чи втратяться повідомлення?

Це не гіпотетика. Такий сценарій — відкриття бронювань у квест-кімнаті або анонс нового тренінгу у фітнес-клубі — трапляється регулярно. І те, як бот його обробляє, залежить від того, наскільки добре інфраструктура враховує реальні ліміти Telegram API.

Які ліміти є у Telegram Bot API

Telegram публікує ліміти у офіційній документації. Основні, важливі для бізнес-бота:

Rate limits на відправку:

• 30 повідомлень на секунду до різних чатів — глобальний ліміт на бота
• 1 повідомлення на секунду в один конкретний чат
• При перевищенні Telegram повертає помилку 429 Too Many Requests з полем retry_after — через скільки секунд можна повторити

Розмір контенту:

• 4096 символів — максимальна довжина одного текстового повідомлення
• 1024 символи — для підписів до медіа (caption)
• 50 МБ — максимальний розмір файлу для завантаження через Bot API

Flood control:

• Якщо бот систематично перевищує ліміти, Telegram може тимчасово заблокувати його. Термін і умови не публікуються точно — це захисний механізм від spam-ботів.

Webhook і polling:

• 40 одночасних підключень до getUpdates (polling) — рідко актуально для webhook-архітектури
• Timeout webhook-запиту: 60 секунд

Для більшості leisure-ботів, які ведуть 1-20 розмов одночасно, жоден з цих лімітів у звичайний день не досягається. Проблема виникає в специфічних сценаріях.

Чи впливають ліміти на типовий SMB-бот

Для 90% day-to-day роботи — ні. Клієнти пишуть рівномірно протягом дня. Бот відповідає на одне повідомлення, потім наступне. Навіть у «гарячий» вечір п'ятниці, коли 5-7 людей пишуть одночасно, загальне навантаження далеко від ліміту 30 msg/sec.

Де ліміти стають реальними:

Масові розсилки. Якщо ви хочете надіслати нагадування 500 клієнтам про акцію — 500 повідомлень підряд. Навіть якщо відправляти по одному в секунду (нижче глобального ліміту 30/сек), Telegram може розцінити це як спам-активність. Правильно — розбивати на партії по 30-50 і розтягувати на кілька хвилин.

Burst при відкритті бронювань. Оголошення в соцмережах «записуємось з 10:00» — і в 10:00:05 приходить 40 запитів. Це вже близько до ліміту. Без черги повідомлень частина запитів отримає 429 і або зависне, або буде відхилена.

Довгі відповіді. Якщо бот намагається відправити відповідь на 5000 символів — Telegram поверне помилку. Текст треба розбивати на частини до 4096 символів.

Telegram Business API vs звичайний Bot API

Тут є суттєва різниця, яку важливо розуміти.

Стандартний Bot API — ваш бот має власний акаунт (@YourBotName). Клієнти пишуть напряму боту. Це найпоширеніший варіант і те, що використовує більшість leisure-ботів у Leadmlyn.

Telegram Business API — інший механізм. Дозволяє підключити бота до вашого особистого або бізнес-акаунту Telegram, щоб бот читав і відповідав від вашого імені у звичайних чатах. Клієнт пише вам особисто — бот відповідає замість вас.

Для leisure-бізнесу Business API дає конкретну перевагу: клієнт пише туди, куди вже звик писати — у ваш особистий акаунт або на номер телефону бізнесу, а не шукає окремого бота. Це знижує тертя при першому контакті.

Обмеження Business API: доступний тільки для Telegram Premium (бізнес-підписка) і технічно складніший у налаштуванні. Leadmlyn підтримує обидва варіанти. Новим ботам за замовчуванням рекомендується стандартний Bot API — простіше запускатись. Business API — для випадків, де власник вже активно веде Telegram як канал комунікації і хоче автоматизувати відповіді у своєму акаунті.

Як Leadmlyn обробляє rate limits і помилки API

Три рівні захисту:

Черга повідомлень. Вхідні повідомлення від клієнтів ставляться у чергу і обробляються послідовно. Якщо в момент отримання повідомлення API повертає 429 — повідомлення залишається в черзі і відправляється після retry_after секунд. Клієнт не бачить помилки, просто відповідь приходить з невеликою затримкою.

Retry-логіка на LLM-виклики. Окрім Telegram API, є ще виклики до OpenAI/Anthropic. Вони теж можуть повертати 429 або 503. Leadmlyn реалізує exponential backoff — після першої помилки чекає 1 сек, після другої 2 сек, після третьої 4 сек і так далі. Максимум 3-4 спроби перед тим як відповісти клієнту повідомленням про технічну проблему.

Довгі тексти. Якщо відповідь бота перевищує 4096 символів (рідко, але буває у випадку списків або детальних описів), Leadmlyn автоматично розбиває на кілька повідомлень.

Чесно про SLA: Leadmlyn не гарантує 99.9% uptime у SLA-документі, тому що такий документ було б нечесно давати на поточному масштабі solo-продукту. Реальна доступність за останні 3 місяці — вище 99%, але downtime трапляється — переважно через апстрім OpenAI або Telegram. Про серйозні інциденти власники отримують повідомлення в Telegram-канал.

Практичні рекомендації для власника

Якщо плануєте масову розсилку. Не намагайтесь відправити 500 повідомлень за хвилину через будь-який інструмент. Ліміт Telegram — 30/сек до різних чатів, але flood control може спрацювати раніше. Оптимально: не більше 20-25 повідомлень на секунду з паузою кожні 100 повідомлень. У Leadmlyn broadcast-функціонал реалізовано з вбудованою throttling-логікою саме для цього.

Якщо бот «завис» і не відповідає. Перший крок — перевірте статус Telegram через https://downdetector.com або @telegramstatus. Друге — перевірте в Leadmlyn dashboard чи є активні помилки. Третє — напишіть в підтримку: більшість зависань — це або коротка проблема апстріму, або щось у налаштуваннях KB що спричиняє нескінченний цикл. Про останнє детальніше в статті про помилки бота.

Якщо розмови раптово обрізаються на великому тексті. Майже завжди — бот намагається відправити текст довше 4096 символів. Рішення: попросіть бота у системному промпті тримати відповіді лаконічними. Або перегляньте KB — можливо там є надто довгі чанки тексту що безпосередньо вставляються у відповідь.

Якщо отримуєте скарги від клієнтів що «написав, але відповіді нема». Це може бути 429 який черга ще не обробила, або клієнт написав з акаунту що заблокував бота. Обидва випадки видно в логах розмов у dashboard. Якщо бачите запис з incoming без outgoing — це воно.

Telegram — стабільна і надійна платформа, але не без обмежень. Знати їх і проектувати під них — частина нормальної інженерної роботи. Більшість з цього невидима для кінцевого власника бізнесу, поки інфраструктура з ними враховує. Що вона має враховувати з першого дня — а не коли перший burst вже поклав бота.