Перенёс антиспам из Telegram в Макс — через месяц бота удалили. Что я понял про платформу

В декабре 2024 я запустил антиспам-бот для Макс — по той же схеме, что уже годами работает в Telegram. Через месяц платформа удалила бота без объяснений. Поддержка отвечала: «работаем над вашим вопросом, ждите». Досудебная претензия заказным письмом — разблокировка и ответ в духе «вы согласились с правилами при регистрации».

Если вы разработчик ботов и думаете зайти в Макс — ниже не обзор «какие у меня продукты», а разбор того, что реально ломается на платформе и какие архитектурные решения пришлось собрать на ходу. Два кейса: антиспам (перенос TG-логики) и «Почтальон» (мост Макс ↔ Telegram), который родился уже после блокировки.

Кто я и зачем эта статья

Это моя первая публикация на Хабре — прошу не судить строго. Разработкой занимаюсь больше 40 лет; последний год в основном пишу ботов для Макс. Отправил в поддержку несколько сотен тикетов — большинство закрыли с сообщением «Ваш вопрос закрыт» и без видимых изменений в API, часть чинили оперативно.

В арсенале три бота в Макс: антиспам, «Почтальон» (мост Макс ↔ Telegram) и розыгрыши призов. Розыгрыши здесь не разбираю — другая предметная область. Фокус на том, что полезно коллегам-разработчикам.

Стоит ли вообще лезть в Макс в 2026 году

Короткий баланс без маркетинга платформы.

За:

• спрос есть — пользователи просят модерацию, кросс-мессенджер, автоматизацию каналов;

• конкуренции среди ботов мало;

• webhook-модель в целом узнаваема, если вы уже писали под Telegram.

Против:

• API и документация отстают от реальности — поля webhook менялись, краевые случаи не описаны;

• поддержка — лотерея: от быстрого фикса до бесконечного «ждите»;

• блокировка бота без диалога — не теоретический риск, а мой личный опыт.

Вывод, с которым живу: Макс — поле для тех, кто готов к запасным каналам, подробным логам и тому, что платформа может откатить месяц работы одним щелчком. Если вам нужна предсказуемая экосистема уровня Telegram Bot API 9.x — пока рано ставить всё на Макс.

---

Базовая дисциплина: один webhook — один запрос

Прежде чем про ботов — про архитектуру. У меня все боты устроены одинаково:

HTTP-запрос → webhook.php → обработка → exit

Никаких «долгоживущих» PHP-процессов между событиями. Каждый webhook — чистый контекст. Флаги вроде «удалить сообщение при следующем update» живут только внутри текущего запроса.

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

---

Кейс 1: антиспам — когда переносишь проверенную TG-логику

Задача

В Telegram мой user_ban работает по принципу «установил и забыл»: эвристики по имени, ссылкам, языку, флуду, массовым рассылкам — без ручных списков стоп-слов. Порт в Макс выглядел прямолинейно: тот же webhook, бан/мут, уведомления админам в личку.

Где TG и Макс расходятся на практике

Конкретные примеры из продакшена:

1. Права админа — бот добавлен, формально админ, но отдельные операции (удаление, бан) ведут себя иначе, чем в TG. Приходилось проверять не «что написано в UI», а «что вернул API на этом chat_id».

2. Сырой webhook — при аномалиях пишу payload в файл в /log/, в рабочий лог — только ссылка. Иначе буфер логов раздувается, а главное — теряется артефакт для тикета в поддержку.

3. Уведомления нескольким админам — в больших бесплатных чатах (≥10 участников) рассылать всем админам каждый mayBe-спам — убить личку и выйти за лимиты API. Пришлось ввести одного модератора уведомлений (/setNotify): команды модерации доступны всем админам, а авто-уведомления — одному слоту (или в чат админов).

4. Жёсткий бан — /banhard из лички: выгнать пользователя из всех чатов, где админ и где есть этот участник. В TG-привычке «ответил /ban на сообщение» этого недостаточно для сценария «спамер в 15 чатах сразу».

5. Нет частичных и временных ограничений пользователя — приходится всё эмулировать, чтобы пользователя не удалять из чата, а только запретить ему писать.

История с удалением — что запомнить разработчику

Не буду раздувать юридическую часть. Инженерные выводы:

• не держите единственную точку контакта с пользователями внутри платформы;

• логируйте всё, что может понадобиться при разборе;

• имейте план Б на случай удаления бота — у меня он стал вторым продуктом (см. кейс 2).

---

Кейс 2: «Почтальон» — инженерная задача, а не «ещё один бот»

Откуда взялось

После блокировки Телеграм в России я оказался в ситуации, знакомой многим: Telegram недоступен или режется, Макс — работает. Все контакты в Телеграм. Нужно читать личку Telegram и отвечать так, чтобы собеседник видел ответ в том же диалоге TG.

Так появился «Почтальон»: пересылка Макс ↔ Telegram с ответами из Макс обратно в исходный диалог.

Модель данных (суть)

В БД — таблица пересылок. Каждая строка — направление потока, не «настройка бота» абстрактно:

Режим 0 (⇢): Макс → Telegram   — посты из канала Макс в группу TGРежим 1 (⇠): Telegram → Макс   — входящие из TG-группы в личку МаксРежим 2 (⇄): обе стороны      — чат Макс ⟷ чат TG

Отдельный сценарий — автоматизация профиля Telegram (Настройки → Аккаунт → Автоматизация чатов): вся входящая переписка профиля уходит в личку Макс; «Ответить» в Макс возвращает текст клиенту в TG.

Главный источник багов у новичков: путаница, кто такой tg в строке связки — это не id клиента, а id группы/канала или владельца профиля.

Проблема одного слота автоматизации в Telegram

В профиле TG можно подключить только одного бота автоматизации. У корпоративных пользователей уже стоял свой автоответчик. Заменить его на «Почтальона» — потерять ответы на типовые вопросы.

Решение: встроить автоответчик в «Почтальона». Один бот:

1. пересылает входящее в Макс;

2. сразу отвечает клиенту в TG по правилам (фразы, кнопки, медиа);

3. опционально дописывает в пересылку: 🤖 Автоответил: … — коллеги в Макс видят, что клиенту уже ответили.

Одна интеграция закрыла две боли — именно корпоративный сегмент это и оценил.

Общий чат вместо лички

Следующий запрос пришёл от пользователей, не от ТЗ: пересылать не в личку Макс, а в групповой чат, чтобы несколько менеджеров смотрели потоки в одном месте. Ответ из Макс уходит автору в TG — по сути лёгкая мини-CRM на webhook’ах.

Проблема с большими файлами

У Tg для пересылки больших файлов существует локальный сервер Telegram Bot API, его нужно установить на своем сервере и все запросы переадресовывать на свой сервер. У Макс такого сервера нет, но есть проблема с частыми ошибками при загрузке файлов на сервер Макс, что создает неудобства, когда пост опубликован в канале TG, а в Макс бот почтальон «пропихивает» его через 10 минут.

Белые списки

Отдельный практический сценарий: периоды, когда из мессенджеров нормально работает только Макс. «Почтальон» не «ломает блокировку» — он дублирует канал коммуникации. Основной недоступен — запасной продолжает работать.

---

Чеклист: что заложить до первого коммита под Макс

1. Лог сырого webhook — файл на диск при превышении порога или при error от API; в оперативный лог — ссылка, не полный JSON.

2. Изоляция вторичных подсистем — у меня есть каталог чатов и синки; ошибка каталога не роняет webhook основного бота. Сначала бизнес-логика, потом всё остальное — в try/catch или на shutdown.

3. Не дублировать webHookBegin() в боте с урезанным набором полей — потеряете кнопки, payload и отладку. Один вход через базовый класс.

4. Тикеты в поддержку — не тестовая среда — писать полезно, но релизный цикл на ответы саппорта не вешать.

5. Связь с пользователями вне платформы — канал, сайт, email; платформа может отключить бота без объяснений.

6. Сценарий «бот удалили» — что видит пользователь, как переустановить, как не потерять данные.

7. Один webhook = один запрос — не проектировать сброс static-state между запросами; следующий webhook — новый процесс.

---

Где обсуждать разработку под Макс

Если после прочтения остались вопросы по API, webhook, модерации или странным ответам поддержки — завёл чат для разработчиков, которые уже ковыряют Макс или только собираются. Там нет официальной поддержки платформы — зато есть люди, которые уже получили по зубам и могут сказать «у нас тоже так было».

---

Заключение

Макс сегодня — не готовая экосистема, а поле с высоким спросом и высоким риском. Мой путь за этот год: антиспам как перенос TG-логики → удаление без объяснений → «Почтальон» как инженерный ответ на недоступность Telegram и ограничение «один бот автоматизации» и успешный бот розыгрыша призов.

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

P.S. Подробные инструкции к описанным кейсам (документация, не реклама):

• Антиспам: https://htmlweb.ru/max/anti_spam_bot.php

• Почтальон: https://htmlweb.ru/max/postman.php

Боты в Макс: @id616301431999_bot (антиспам), @id616301431999_2_bot (почтальон). В Telegram: @postman_max_bot.

Буду рад конструктивной критике в комментариях, особенно от тех, кто тоже пилит под Макс.