Лимиты MAX Bot API: что известно точно, а где лучше не гадать
Собрали официально подтверждённые ограничения MAX Bot API и отдельно вынесли инженерные рекомендации, чтобы не путать документацию с предположениями.
Почему вообще важно знать лимиты
Лимиты нужны не ради красивой таблицы в блоге. Они определяют, как быстро вы можете отправлять сообщения, как строить очередь, что считать аномалией и где заканчивается “ошибка интеграции”, а начинается обычная защита платформы от перегрузки.
Вокруг MAX уже много пересказов, где официальные цифры смешаны с чужими догадками. Поэтому полезнее разделить материал на две части: что прямо подтверждено документацией и что уже относится к инженерной стратегии команды.
Что подтверждено официально
Ниже то, на что можно ссылаться без оговорок, потому что это зафиксировано в документации MAX для разработчиков.
| Параметр | Подтверждённое значение | Что это значит на практике |
|---|---|---|
| Максимальная частота запросов | До 30 rps на platform-api.max.ru | Это верхняя граница, а не рекомендованный рабочий темп для старта |
| Длина текста | До 4000 символов | Длинные сообщения лучше дробить по смыслу, а не упираться в максимум |
| Inline-кнопки | До 210 кнопок, до 30 рядов, обычно до 7 в ряду | Технически можно много, но человеку обычно хватает 2-4 кнопок |
| Загрузка файлов | До 4 ГБ через POST /uploads | Сначала загружаете файл, потом используете токен или ссылку в сообщении |
| Webhook timeout | Ответ сервера до 30 секунд | Тяжёлую обработку лучше выносить из HTTP handler в очередь |
| Long polling | timeout от 0 до 90, limit до 1000 | Хватает для отладки и простых сценариев, но не заменяет продовый webhook |
| Удаление сообщений | Сообщение должно быть младше 24 часов | Не откладывайте cleanup и модерацию “на потом” |
Этого набора достаточно, чтобы без фантазий спроектировать первую рабочую интеграцию. Всё остальное лучше считать гипотезой, которую вы подтверждаете уже собственными нагрузочными тестами.
Где лучше не выдумывать цифры
Есть вещи, про которые статьи часто пишут слишком уверенно: “вот точный предел на одного бота”, “вот жёсткий размер конкретного типа вложений”, “вот стандартный интервал повторов webhook”. Если документация не формулирует это явно, лучше не превращать инженерную догадку в “официальный лимит”.
- Не подменяйте потолок API рекомендацией по боевому RPS.
- Не опирайтесь на старые примеры с неофициальными доменами или query-токеном.
- Не стройте критичную логику на предположении, что повторов webhook “будет мало”.
Если команда не уверена, зафиксируйте это прямо в документации проекта: “официально подтверждено” и “наш рабочий консервативный режим” должны быть разными таблицами.
Безопасный старт без лишнего риска
На старте бизнесу редко нужен максимум возможностей. Ему нужен предсказуемый канал. Поэтому разумная стратегия чаще выглядит так:
- Начните с темпа ниже официального верхнего лимита и поднимайте его постепенно.
- Ставьте все отправки через очередь, как только сообщение становится важным для денег или SLA.
- Фиксируйте идемпотентность по собственному ключу сообщения, а не надейтесь на “авось не задублируется”.
- На 429 не спорьте с каналом, а сбрасывайте темп и повторяйте позже.
const queuePolicy = {
channel: "maxbot",
startRps: 10,
maxRpsAfterLoadTests: 30,
retry: {
maxAttempts: 5,
strategy: "exponential-jitter",
},
};Здесь startRps: 10 не означает “официальный лимит 10”. Это просто консервативный старт, который помогает новой интеграции не умереть от первой же вспышки трафика.
Что мониторить
Если у вас нет наблюдаемости, лимиты быстро превращаются в мистику. Достаточно нескольких метрик, чтобы перестать гадать.
| Метрика | Зачем нужна |
|---|---|
| RPS по каналу и боту | Понимать, насколько вы близко к верхней границе |
| Доля ответов 429 | Видеть, когда продукт уже спорит с лимитом |
| Время жизни сообщения в очереди | Понимать, превращается ли “быстрая отправка” в фактическую задержку |
| Успешные и неуспешные webhook | Вовремя ловить проблемы в серверной обработке |
Следующий шаг после лимитов обычно один из двух: либо вам нужно научиться спокойно переживать ошибку 429, либо встроить это всё в более крупный сценарий вроде массовой отправки.
Полезная статья про лимиты не обещает “точную карту мира”, а отделяет документированную правду от инженерных допущений. Для MAX это особенно важно, потому что платформа ещё развивается и старые пересказы быстро устаревают.
Создайте бесплатный MAX-профиль
Если хочется не просто читать, а сразу проверить сценарий руками: подключите MAX, отправьте себе тестовое сообщение и уже потом решайте, нужны ли другие каналы.