Telegram API в России лёг. Вот что мы делаем с клиентскими ботами - и почему MAX уже не шутка

TL;DR. После ограничений Telegram Bot API в РФ стратегия «подождём, починят» перестала работать у наших клиентов первой же.

За последний месяц мы мигрировали несколько клиентских ботов на MAX и VK и собрали честную карту: где MAX уже тянет как замена, где VK сильнее, и что физически невозможно перенести один в один.

Дальше — план миграции по типам ботов, таблица совместимости фич Telegram / MAX / VK, подводные камни с вебхуками, файлами и инлайн-режимом, и наш практический опыт с первыми проектами на MAX Bot API.

Отдельный раздел — про то, как вообще устроены боты в max мессенджере и чего от них пока не стоит ждать.

Откуда вообще этот разговор

Полгода назад фраза «переедем на MAX» в обсуждении с клиентом звучала как шутка. Сейчас это пункт в дорожной карте, который мы согласовываем всерьёз. Причина прозаичная: с 10 февраля 2026 Роскомнадзор начал замедление Telegram, а api.telegram.org у ряда провайдеров блокируется через ТСПУ — оборудование глубокой фильтрации трафика. Боты, которые годами тихо работали на вебхуках с серверов в российских дата-центрах, внезапно перестали получать ответы от Telegram. Последствия зависят от типа бизнеса, но ни одно из них не безобидное:

• B2C-продажи — просадка конверсии, потерянные лиды.
• Поддержка — очередь из тикетов, которые никто не видит.
• Внутренние процессы — остановка рутины, на которой держалась операционка.

Мы не комментируем политическую сторону и не гадаем, что будет дальше. Но как студия, у которой в эксплуатации живут боты нескольких клиентов, мы обязаны дать им рабочий ответ здесь и сейчас. И этот ответ, как выяснилось, не сводится к простому «перенесём код и поехали».

MAX и VK — это не клоны Telegram, это другие платформы со своей логикой, своим API и своей аудиторией. Миграция — не копипаст, а небольшой редизайн продукта.

Ниже — то, что мы поняли на практике, без маркетинговых обёрток и без «MAX — это будущее». Будущее покажет, а сегодня у нас есть конкретные клиенты, которым нужно, чтобы бот снова принимал заявки.

Что такое MAX мессенджер и при чём здесь боты в max мессенджере

Если коротко и без пафоса: MAX — это российский мессенджер от VK, который в июле 2025 получил статус национального мессенджера и с тех пор активно наращивает функциональность.

С точки зрения разработчика нас интересует одна конкретная вещь — MAX Bot API, то есть набор методов, через которые можно программно читать сообщения, отвечать на них, слать медиа и строить интерактивные сценарии.

Боты в max мессенджере концептуально похожи на телеграмовские: есть команды, есть клавиатуры, есть вебхуки и long polling, есть возможность отправлять кнопки и обрабатывать нажатия. Разница начинается в деталях — и именно эти детали определяют, насколько болезненной окажется миграция.

MAX Bot API активно развивается, и кое-где даже обгоняет Telegram:

• файлы до 4 ГБ с resumable upload (против 50 МБ в Telegram Bot API);
• inline-клавиатуры до 210 кнопок и 30 строк.

Но при этом целые пласты привычной функциональности отсутствуют:

• inline-режим (@bot query);
• нативные платежи, стикеры, реакции, опросы;
• редактировать сообщения можно только в первые 24 часа;
• лимит текста — 4 000 символов вместо 4 096.

Отдельный момент — с августа 2025 публиковать ботов и мини-приложения в MAX можно только через верифицированные юрлица РФ или ИП.

Физлица и нерезиденты пока пройти верификацию не могут, и это стоит учитывать на старте. Для разработки max бота всё это означает, что мы проектируем не «замену Telegram», а канал, в который аудитория будет подтягиваться в течение ближайших месяцев. Соответственно, решения по UX должны быть рассчитаны не на сегодняшнюю знакомую привычку, а на то, как человек впервые откроет бота в новом для себя интерфейсе.

Еще одна важная вещь — интеграция max мессенджера в существующую инфраструктуру клиента. В большинстве наших проектов бот — это не самостоятельная сущность, а тонкий слой поверх CRM, платёжной системы, Payload CMS/Wordpress/Mobx/Strapi или внутренней базы. Когда мы мигрируем бота, мы переносим не диалоги, а именно эту связку:

1. Вебхук принимает событие от платформы.
2. n8n или собственный бэкенд его обрабатывает.
3. Дальше идёт поход в CRM за данными клиента.
4. Формируется и возвращается ответ пользователю.
5. Всё логируется для отладки и аналитики.

Поэтому «перенести на MAX» в нашей практике почти всегда означает «аккуратно поменять адаптер в уже живой архитектуре», а не переписать всё с нуля.

Сравнение фич: Telegram Bot API, MAX Bot API и VK Bot API

Чтобы разговор был предметным, ниже — сводная таблица по тем возможностям, которые чаще всего оказываются критичными при миграции. Это не исчерпывающий справочник, а наш рабочий чек-лист: по нему мы на старте каждого проекта прикидываем, сколько функциональности переносится «как есть», сколько придётся переизобретать и от чего предстоит отказаться.

Главный вывод из этой таблицы такой: ни MAX, ни VK не покрывают Telegram Bot API на сто процентов, и обещать клиенту «полную совместимость» — это врать.

Но в большинстве практических сценариев, которые мы встречаем в работе, мигрируемая функциональность укладывается в пересечение всех трёх платформ: текст, медиа, клавиатуры, callback, вебхуки.

Проблемы возникают на краях — там, где проект опирался на inline-режим, на нативные платежи или на редактирование сообщений без ограничения по времени.

Как мы мигрируем по типам ботов

Универсальной стратегии миграции не существует, и любой подрядчик, который предлагает «один план для всех», упрощает задачу до того, чтобы её стало легко продать. На практике мы смотрим на тип бота и приоритет, который он имеет для бизнеса, и из этого выстраиваем порядок действий. Три самых частых случая у нас выглядят так.

Боты продаж и заявок. 

Это самая чувствительная категория: каждый час простоя — это упущенные лиды и прямой убыток. Здесь мы не ждём, пока MAX дозреет, а идём по пути параллельной эксплуатации:

1. Сохраняем живой Telegram-бот там, где он ещё достучится до пользователя.
2. Одновременно поднимаем MAX-версию с тем же набором сценариев.
3. Если у клиента есть сообщество в VK — добавляем VK-бот как третий канал.
4. Все три ведут в одну и ту же очередь заявок в CRM через тонкий адаптер, который нормализует входящие события в единый формат.

Для клиента это значит одно окно обработки, для пользователя — возможность написать туда, где ему удобно. Как правило, для такой архитектуры мы используем n8n в роли шины событий: он отлично ложится на сценарий «несколько источников → одна воронка» и не требует писать весь оркестратор руками.

Боты поддержки. 

Здесь приоритет другой. Не скорость реакции на лида, а непрерывность обслуживания существующих клиентов. Простой болезненный, но не катастрофический, тикеты можно догнать почтой или звонком. Поэтому мы обычно идём последовательно:

1. сначала поднимаем MAX-версию
2. переносим туда FAQ-сценарий и базовые команды
3. тестируем на части аудитории
4. постепенно переводим остальных

Параллельно даём в Telegram-боте (пока он работает) сообщение вида «мы теперь и в MAX» со ссылкой, чтобы пользователи переходили по собственной воле, а не по принуждению.

Контентные боты. 

Рассылки, дайджесты, уведомления, контентные подписки. Категория, которая на первый взгляд простая, а на деле имеет собственные подводные камни.

Главный — это лимиты на рассылку и отношение платформы к массовым сообщениям. Telegram исторически был щедрым, MAX и VK в этом смысле строже, и если мы просто возьмём логику «шлём всем по расписанию» и перенесём её буквально, то быстро упрёмся в ограничения.

Поэтому для контентных ботов мы переделываем не транспорт, а механику:

• Pull-модель — пользователь сам запрашивает свежий контент командой или кнопкой.
• Push только для срочного — сохраняем рассылку для действительно важных уведомлений, а не для каждого дайджеста.

В результате миграция оказывается не переносом, а небольшим редизайном продукта — но это честнее, чем сломаться на второй рассылке.

Общее правило, которое мы вынесли из всех трёх типов: не пытайтесь перенести бота до последней пиксельной детали. Часть фич Telegram — это решения, принятые десять лет назад под конкретный UX, и в новом мессенджере они могут быть не лучшим выбором, даже если их технически можно повторить.

Что ломается чаще всего

Есть три места, в которых миграция стабильно упирается в неожиданности. Мы уже знаем их в лицо и закладываем дополнительное время на каждом проекте, но если вы мигрируете бота самостоятельно, стоит держать их в голове с самого начала.

Первое — это вебхуки. В Telegram Bot API мы привыкли к тому, что вебхук настраивается одним вызовом, требует HTTPS и в общем-то прощает многое. MAX Bot API и VK Bot API строже относятся к инфраструктуре.

Вот что отличается на практике:

• Нужен HTTPS-сертификат — MAX принимает и self-signed, но VK требует валидный.
• Стабильный публичный адрес, без перебоев — платформы не прощают даунтайм.
• Корректные ответы на проверочные запросы при регистрации (у VK это отдельная механика подтверждения через Callback API).
• Адекватная обработка повторных доставок — платформы ретраят события чуть иначе, чем Telegram.

В наших миграциях мы несколько раз натыкались на ситуацию, когда бот вроде бы работал, но терял часть событий из-за того, что бэкенд отвечал не тем статус-кодом или не укладывался в таймаут. Проблема решается, но её надо увидеть — а увидеть её без нормального логирования вебхуков невозможно. Поэтому первое, что мы делаем на миграции, — ставим детальное логирование всех входящих апдейтов с сырым телом и заголовками, хотя бы на первые недели эксплуатации.

Второе — файлы и медиа. Здесь ситуация неоднородная. MAX Bot API в части файлов объективно сильнее Telegram: лимит до 4 ГБ с resumable upload против 50 МБ в стандартном Telegram Bot API. Но сюрпризы кроются в другом:

• Механика загрузки медиа в VK устроена через отдельный upload-сервер — это другая последовательность запросов, а не один вызов sendDocument.
• Форматы поддерживаются не все — часть привычных MIME-типов может не пройти.
• Логика работы с вложениями в MAX (attachments) отличается от телеграмовской, и код, завязанный на file_id, придётся адаптировать.

Если у клиентского бота была логика «принимаем от пользователя файл, обрабатываем, возвращаем обратно». Эту часть нужно переписывать с учётом новых механик, даже если лимиты по размеру стали щедрее.

В ряде случаев мы выносим файловую работу на внешний URL: бот отдаёт пользователю ссылку на скачивание с нашего бэкенда, а не пытается послать файл через API платформы. Это и надёжнее, и работает одинаково на всех трёх каналах.

Третье — инлайн-режим. Это, пожалуй, самая болезненная потеря. В Telegram многие интерфейсы построены на @bot query — пользователь вызывает бота прямо из любого чата, получает подсказки и отправляет результат кому угодно. На момент наших миграций MAX Bot API такую модель в привычном виде не предоставляет, VK — тоже. Если клиентский продукт опирался на инлайн как на ключевой сценарий, честный ответ звучит неприятно: в текущей версии MAX Bot API перенести его один в один нельзя, и мы либо меняем UX на клавиатуры и команды внутри диалога с ботом, либо выносим функциональность в мини-приложение.

Мы не обещаем клиенту «эквивалент», потому что его нет; вместо этого мы открыто обсуждаем, какой из альтернативных сценариев закрывает реальную задачу пользователя, а не форму привычного интерфейса.

Есть и четвёртое, менее очевидное место — хранилище состояний диалога. В Telegram многие боты полагаются на то, что chat_id и user_id стабильны и уникальны, и строят на этом всю свою машину состояний. При переезде на другую платформу идентификаторы меняются, и варианта два:

• Мигрировать таблицу под абстрактный external_user_id с полем платформы — чище и сразу закладывает мультиплатформенность.
• Заводить отдельные таблицы под каждый канал — проще на старте, но хуже масштабируется.

Мы предпочитаем первый вариант. После этой истории с API мультиплатформенность выглядит уже не «приятным бонусом», а обязательной страховкой.

Что мы делаем по-другому после первых миграций

После нескольких проектов на MAX Bot API у нас сложилось четыре практических принципа, которые мы теперь применяем по умолчанию.

1. Мультиплатформенность с первого дня. Даже если клиент сегодня хочет только MAX, мы закладываем архитектуру, в которой добавить VK или вернуть Telegram — это подключить ещё один адаптер, а не переписать ядро. Транспортный слой (работа с API платформы) живёт отдельно от бизнес-логики (сценарии, состояния, CRM), и между ними — нормализованный формат событий. Такой подход не добавляет много работы на старте, но окупается на первом же изменении правил игры на любой из платформ.
2. Осторожность с обещаниями по UX. Когда клиент показывает скриншот телеграмовского бота и говорит «сделайте так же в MAX», мы честно проходимся по таблице фич и отмечаем: что переносится буквально, что переносится с оговорками, и что не переносится вовсе. Это неприятный разговор, но он экономит месяц споров после запуска.
3. Нормальная инфраструктура. Боты, которые раньше жили одним контейнером на небольшом VPS, теперь у нас стандартно разворачиваются в Docker-окружении с нормальным менеджером процессов, отдельным логированием вебхуков и мониторингом здоровья адаптеров. Когда падает не ваш код, а вышестоящая платформа, вы обязаны это увидеть первым и сообщить клиенту раньше, чем он заметит сам.
4. MAX — не временная заплатка. Мы не верим, что MAX заменит всё. Но мы увидели: сам факт наличия работающего канала в нескольких мессенджерах одновременно — это другой уровень устойчивости бизнеса, и возвращаться к моноплатформенной архитектуре после этого не хочется, даже если Telegram завтра снова заработает как раньше.

Если вы понимаете, что клиентский бот стал болевой точкой, и хотите спокойно разобраться, как перенести его на MAX и VK без потери функциональности, мы делаем это в рамках услуги разработка бота для MAX. Приходите обсудить — посмотрим ваш текущий бот, пройдёмся по таблице фич применительно к вашему сценарию и покажем, как миграция будет выглядеть именно в вашем случае.