Bot API MAX по составу возможностей — обычный современный API мессенджера: бот получает обновления вебхуком или опросом, отвечает сообщениями, показывает кнопки и меню, принимает и отправляет вложения, обрабатывает команды и умеет работать в группах. Если вы делали бота для другого мессенджера, набор покажется знакомым, и в этом главная ловушка: срок проекта уезжает не на том, чего в API нет, а на том, что в нём устроено иначе, чем вы привыкли.
Таких зон три. Первая — правила инициирования диалога: кто, когда и на каком основании может написать клиенту первым. Вторая — лимиты: частота отправки, размеры вложений, поведение под нагрузкой. Третья — версионирование и повторные доставки, то есть всё, что определяет, будет ли бот работать через полгода без вашего участия. Каждая из трёх зон способна добавить к проекту неделю, если вопрос не задан на старте.
Отдельно о честности этого материала. Конкретные числовые лимиты API площадок меняются без объявления, поэтому переписывать их в статью бессмысленно: через квартал они будут врать, а читатель заложит их в ТЗ. Ниже вместо чисел из документации даны методика измерения лимитов на своём стенде, список из десяти вопросов, которые надо задать документации на день старта, и оценки трудоёмкости в человеко-днях — они устаревают гораздо медленнее. Всё описанное — по состоянию на сентябрь 2026 года.
Что Bot API даёт в любом случае
Этот набор есть у любого бота в любом современном мессенджере, и на него можно опираться при проектировании ещё до чтения документации. Бот регистрируется внутри самого мессенджера служебным ботом-регистратором, который выдаёт токен доступа; дальше вся работа идёт через HTTP-запросы с этим токеном.
- Получение обновлений двумя способами: вебхуком на ваш HTTPS-адрес или периодическим опросом. Вебхук быстрее и дешевле по ресурсам, опрос надёжнее при нестабильном внешнем адресе и удобнее на этапе разработки — рабочая практика в том, чтобы поддержать оба и переключаться конфигурацией.
- Отправка текстовых сообщений в личный чат и в группу, ответ на конкретное сообщение, редактирование и удаление своих сообщений.
- Кнопки и клавиатуры: меню под сообщением и набор быстрых ответов. На них строится вся навигация сценария — свободный ввод текста в первой версии бота стоит минимизировать.
- Вложения в обе стороны: изображения, документы, аудио. Каждый тип имеет свой предел размера, и этот предел — первое, что проверяется на реальных файлах, а не на тестовой картинке 40 КБ.
- Команды бота: короткий список действий, который клиент видит в интерфейсе. Больше пяти команд обычный пользователь не читает — это не ограничение API, а наблюдение за живыми диалогами.
- Работа в группах: бот в чате, реакция на упоминание, служебные события о входе и выходе участников. Для клиентского сценария нужно редко, для внутренних оповещений — регулярно.
- Профиль отправителя: доступный минимум сведений о том, кто написал. Номера телефона там по умолчанию нет — его получают отдельным явным действием клиента, и именно это ограничение определяет всю схему склейки с CRM.
Последний пункт важнее остальных вместе взятых. Без номера телефона клиент из мессенджера не склеивается с карточкой в CRM, и вы получаете отдельную вселенную диалогов, не связанную с историей покупок. Поэтому в сценарии первой версии бота должен быть явный, понятный шаг, на котором клиент делится номером, и внятная причина, зачем ему это делать: «покажу статус вашего заказа», а не «для регистрации в системе».
Схема из семи блоков слева направо со стрелками: «Сообщение клиента» → «Вебхук или опрос» → «Журнал: пишем как пришло» → «Дедупликация по идентификатору обновления, окно 72 часа» → «Очередь с повторами» → «Обработчик сценария» → «Ответ через Bot API». Под блоком очереди ответвление вниз в «Мёртвая очередь: разбирает человек». Над блоком ответа подпись «темп отправки — 50 % от измеренного предела». Пунктиром сбоку — стрелка от вебхука обратно с подписью «повторная доставка того же обновления — норма». Чертёжный стиль, подписи по-русски.
Кто может написать первым: вопрос, который меняет сценарий продаж
В любом мессенджере есть разница между «ответить тому, кто написал сам» и «написать первым тому, кто молчит». Правила здесь у каждой площадки свои, они меняются и они же определяют, можно ли вообще строить на канале уведомления о заказах, напоминания о записи и ссылки на оплату. Это первый вопрос к документации на день старта проекта и первый вопрос к подрядчику, который обещает «рассылку по базе».
Проектная рекомендация не зависит от того, какой окажется ответ. Сценарий должен работать в обе стороны: если написать первым можно — уведомление уходит в мессенджер; если нельзя или доставка не подтвердилась за отведённое время — то же самое уведомление автоматически уходит SMS или звонком. Такой запасной контур закладывается сразу, стоит немного и снимает зависимость от правил площадки. Без него любое изменение правил превращается в аварийную переделку сценариев.
Самый дорогой сбой в таких проектах выглядит одинаково: правила площадки изменились, ссылки на оплату и напоминания о записи перестали доходить, а компания узнала об этом не из логов, а из провала выручки за неделю. Уведомление, от которого зависят деньги, обязано иметь второй маршрут доставки и подтверждение факта доставки. Всё остальное в архитектуре бота можно откладывать, это — нет.
Лимиты: их надо измерять, а не переписывать из статей
Частота отправки, предельный размер вложения, поведение при превышении темпа — числа, которые площадки меняют без предупреждения и не всегда документируют полностью. Их измеряют на своём стенде за один человеко-день, и этот день окупается на первой же массовой отправке. Методика простая.
- 1Шаг 1. Отдельный тестовый бот и отдельный чат
Проба проводится не на боевом боте и не на клиентах. Заводится тестовый бот и группа из нескольких служебных учётных записей — этого достаточно, чтобы поймать поведение под нагрузкой.
- 2Шаг 2. Нарастающий темп
Отправляем короткие сообщения с шагом: 1, 2, 5, 10, 20, 30 в секунду, по 60 секунд на ступень. Фиксируем, на какой ступени появляются ошибки или задержки, и что именно возвращает сервер: код ответа, текст, есть ли указание, сколько ждать.
- 3Шаг 3. Проба вложениями
Отдельно проверяются файлы: 1 МБ, 10 МБ, 20 МБ, 50 МБ. Здесь важны и предел размера, и время загрузки: файл, который уходит 40 секунд, ломает сценарий, рассчитанный на мгновенный ответ.
- 4Шаг 4. Запас и повторение
В боевой темп закладывается 50 % от найденного предела. Проба повторяется раз в квартал и обязательно перед любой массовой отправкой: то, что было верно в марте, в сентябре может быть другим.
Зачем это нужно практически, показывает арифметика рассылки. Возьмём типовую задачу: разослать 5 000 уведомлений — например, о смене графика работы или о готовности документов.
Отсюда два правила проектирования. Первое: уведомление, привязанное к точному времени, нельзя ставить в общую очередь рассылки — напоминание «за час до визита» у последнего адресата придёт за полчаса. Такие сообщения идут отдельным потоком с приоритетом. Второе: у любой массовой отправки должно быть окно, а не момент. В интерфейсе для сотрудников это выглядит как «рассылка займёт около 10 минут», и это честнее, чем полоса прогресса, застывшая на 40 %.
Горизонтальная столбиковая диаграмма из трёх полос: «3 сообщения/с — 27,8 минуты», «10 сообщений/с — 8,3 минуты», «30 сообщений/с — 2,8 минуты». Под каждой полосой мелкая подпись «5 000 адресатов». Справа вертикальная пометка «в боевой темп закладываем 50 % от измеренного предела». Отдельная нижняя строка: «200 недоставленных уходят SMS — 840 ₽». Ось — минуты, все числа подписаны, чертёжный стиль.
Десять мест, где привычка из другого мессенджера стоит недели
Ниже — не выписка из документации, а список вопросов к ней. Каждый пункт проверяется за 10–30 минут на тестовом боте, а все десять закрываются за один рабочий день. Тот же день без проверки превращается в неделю переделок в середине проекта, потому что архитектура уже собрана вокруг неверного предположения.
| № | Что проверяем | Как привыкли в Telegram | Почему это ломает сроки |
|---|---|---|---|
| 1 | Режим получения обновлений и переключение между вебхуком и опросом | Есть оба, переключаются вызовом метода | Если поддержан один режим, меняется схема развёртывания и требования к внешнему адресу |
| 2 | Правила инициирования диалога и исключения для сервисных сообщений | Бот не пишет первым тому, кто не начал разговор | Определяет, можно ли строить на канале уведомления и напоминания — то есть половину бизнес-сценариев |
| 3 | Стабильность идентификатора пользователя и его поведение при смене номера | Числовой идентификатор стабилен | Если идентификатор может измениться, ключом склейки обязан быть телефон, а не он |
| 4 | Как бот получает номер телефона клиента | Только явным нажатием кнопки согласия | Без номера нет склейки с CRM — это переписывание сценария, а не мелкая правка |
| 5 | Типы клавиатур и возможность править уже отправленное сообщение с кнопками | Меню под сообщением и быстрые ответы, сообщение редактируется | Если править нельзя, каждое обновление меню — новое сообщение, и диалог засоряется |
| 6 | Предел размера вложения по типам и срок жизни ссылки на файл | Разные пределы для фото и документов | Определяет, нужно ли своё хранилище файлов — а это отдельная строка сметы на 30 000 ₽ |
| 7 | Поддерживаемая разметка текста и поведение при неподдерживаемых символах | Несколько вариантов разметки на выбор | Ошибка разметки может вернуть отказ на всё сообщение, а не просто показать текст как есть |
| 8 | Практический предел частоты отправки, отдельно для личных чатов и групп | Разные пределы, о превышении сообщает код ответа | Без замера рассылка либо идёт втрое дольше плана, либо упирается в блокировку темпа |
| 9 | Что возвращается при превышении темпа и указывается ли время ожидания | Код ответа с явной паузой | Без явной паузы нужна собственная стратегия отступа, иначе повторы усугубляют ситуацию |
| 10 | Версионирование API и порядок объявления изменений | Версия в адресе, изменения объявляются заранее | Определяет, сколько стоит поддержка бота в год и что произойдёт с ним без вашего участия |
Ответы по каждому пункту берутся из действующей документации площадки на день старта проекта и подтверждаются пробой на тестовом боте. Любая статья, включая эту, для таких деталей устаревает за квартал. Если подрядчик приносит готовые числа лимитов и не может показать, когда и как он их проверял, — это те же переписанные из интернета цифры, за которые вы платите как за экспертизу.
Минимальный контур эксплуатации
Бот, который работает на демонстрации, и бот, который живёт в эксплуатации год, различаются шестью вещами. Все шесть стоят вместе около трёх человеко-дней и отвечают за то, что вы узнаёте о проблеме раньше клиента.
- Журнал всех входящих и исходящих сообщений на своей стороне, в исходном виде и до всякой обработки. Это и отладка, и архив переписки, и единственный источник правды при разборе спорной ситуации с клиентом.
- Дедупликация обновлений. Повторная доставка одного и того же события — штатное поведение любого мессенджера при сетевых сбоях, а не авария. Обработчик должен помнить идентификаторы обработанных обновлений с окном 72 часа, иначе клиент получит второй одинаковый ответ, а в CRM появится второй лид.
- Очередь с повторами и нарастающей задержкой, а рядом — «мёртвая» очередь для сообщений, которые не ушли после всех попыток. Разбирает её человек, и именно она показывает реальные проблемы канала раньше любых метрик.
- Темп отправки, ограниченный половиной измеренного предела, с приоритетным потоком для сообщений, привязанных ко времени.
- Мониторинг тишины: если в рабочее время от площадки не пришло ни одного обновления дольше согласованного интервала, приходит уведомление ответственному. Отвалившаяся интеграция чаще всего выглядит именно как тишина, а не как ошибка в логах.
- Отдельный тестовый бот и возможность прогнать сценарий целиком перед выкаткой. Без него любая правка меню проверяется на живых клиентах.
Карта связей. В центре блок «Обработчик бота». Слева входит «Bot API MAX» через блоки «Журнал» и «Дедупликация». Справа выходят три стрелки: «Очередь отправки → Bot API», «CRM: контакт и сделка», «Мёртвая очередь → разбирает человек». Сверху над центром блок «Мониторинг тишины: нет обновлений N минут → алерт». Снизу отдельный контур «Тестовый бот: прогон сценария перед выкаткой», соединённый пунктиром. У каждой связи подпись, что передаётся. В углу пометка «контур эксплуатации ≈ 3 человеко-дня».
Трудоёмкость и цена: человеко-дни и рубли
Оценка ниже — для бота с шестью сценариями, приёмом вложений и передачей диалога оператору. Она устойчивее любых чисел из документации: состав работ меняется гораздо медленнее, чем правила площадок.
В деньгах по нашей ставке это примерно 65 000 ₽ за разработку базового бота и около 245 000 ₽ за полный контур со связкой с CRM. К базовому боту добавляются 2–3 дня проектирования сценариев и написания текстов вместе с заказчиком — отсюда привычная цифра около 95 000 ₽ за сценарного бота под ключ. Полная связка с CRM с учётом проектирования и приёмки укладывается в 240 000–275 000 ₽, что совпадает с нашими сметами для Битрикс24 и amoCRM: 240 000 ₽ и 245 000 ₽ соответственно. Разница между CRM меньше, чем разброс от аккуратности вашей базы контактов.
Ежемесячная эксплуатация — 14 000–16 000 ₽: сервер, правки сценариев, разбор мёртвой очереди, обновления при изменении API. Отдельная строка появляется, если бот отвечает не по сценарию, а языковой моделью: тогда добавляется плата за обращения к модели, и её считают по числу диалогов, а не по абонентской логике. Отдельно закладывайте 20 000–25 000 ₽ на слой абстракции канала: он позволяет переиспользовать всю логику бота при переходе на другой мессенджер и окупается с первой же сменой правил площадки.
Когда своего бота писать не надо
Возможности API — не аргумент за разработку. Есть четыре ситуации, в которых бот на Bot API не окупится, и лучше узнать о них до ТЗ, чем после приёмки.
- Меньше 100 обращений в месяц. Даже базовый бот за 95 000 ₽ здесь даёт цену обращения выше стоимости живого ответа. Заведите бизнес-профиль и отвечайте вручную — вернуться к боту можно ближе к 300 обращениям в месяц.
- Вопросы клиентов не повторяются. Практический порог — тема должна встречаться чаще 30 раз в месяц и иметь ответ, который берётся из системы, а не из головы менеджера. Если под этот критерий не подходит ни одна тема, сценарного бота писать не из чего.
- Нужны только уведомления, а инициировать диалог первым нельзя или ненадёжно. Тогда бот в этой схеме лишний: те же уведомления дешевле и надёжнее отправлять SMS, а мессенджер оставить для входящих обращений.
- Условия и прайс меняются каждые две недели. Сценарий устареет быстрее, чем вы успеете его обновить, и бот начнёт врать клиентам. Здесь сначала нужна база знаний с одним источником правды, и только потом бот, который из неё отвечает.
И последнее. Всё описанное — по состоянию на сентябрь 2026 года, и статус каналов в России за последние полтора года менялся трижды. Единственный устойчивый вывод из технической справки такого рода не в том, что умеет конкретный API, а в том, как построить бота, чтобы смена API не стоила проекта заново: журнал и идентификатор клиента у себя, вся логика выше уровня адаптера, уведомления с запасным маршрутом доставки. Тогда следующая площадка обойдётся в один адаптер и несколько дней работы.
Про API мессенджера важно не что в нём есть сегодня, а сколько будет стоить его замена завтра.
