MAX и автопостинг
Права ботов в MAX: как сохранить автопостинг при изменениях
Если у MAX-бота изменились права, расписание может продолжать работать, а публикации — перестать выходить. В октябрьском журнале изменений API появилось событие bot_admin_permissions_changed. Разбираем, как получать его, проверять доступ и возвращать публикации в работу без повторных постов.
Опубликовано
Что изменилось в API MAX
Событие bot_admin_permissions_changed сообщает об изменении прав бота. Его нужно включить в update_types подписки через POST /subscriptions. Оно доступно только через Webhook: приложение на Long Polling не получит это обновление. Перед изменением подписки проверьте действующие настройки через GET /subscriptions и сохраните необходимые типы событий.
Какие права нужны для публикации в канале
Назначайте права под согласованные действия. Для публикации постов и комментариев в канале используется write. Его назначение требует read_all_messages: это право должно быть выдано ранее или вместе с write. Для редактирования постов и комментариев в канале применяется edit, для удаления — delete, для закрепления — pin_message; у этих действий также есть зависимость от read_all_messages. Право добавлять администраторов не требуется только ради автопостинга.
- Канал: write относится к публикации постов и комментариев.
- Группа: write относится к редактированию и удалению сообщений; не переносите модель канала на группу.
- Права edit и delete для групповых чатов недоступны.
- Повторное назначение через POST /chats/{chatId}/members/admins полностью заменяет набор прав. Передавайте полный согласованный набор, а не только добавленное право.
Как проверить фактические права бота
После уведомления запросите GET /chats/{chatId}/members/me. Метод возвращает членство бота и, для администратора, список permissions. Сравните его с действиями конкретного сценария: публикацией, изменением поста или закреплением. Если бот больше не администратор, поле прав может отсутствовать. Сохранённая при первом подключении отметка о доступе не заменяет текущую проверку.
- Проверьте нужный chatId и токен именно этого бота.
- Не трактуйте ошибку запроса как пустой список прав: отдельно разберите авторизацию, доступ и доступность API.
- Для текущих запросов документация указывает platform-api2.max.ru и токен в заголовке Authorization; передача токена в query-параметрах не поддерживается.
- Для подключения к API документация требует добавить сертификат Минцифры в список доверенных. Настройте доверие сертификату, сохранив проверку TLS.
Как принять событие через webhook
Проверьте HTTPS-адрес обработчика, сертификат и доступность сервера. MAX требует порт 443 и ответ 200 в течение 30 секунд. При создании подписки задайте secret и проверяйте заголовок X-Max-Bot-Api-Secret на стороне обработчика. Тяжёлую обработку лучше вынести в очередь после сохранения события. При длительной недоступности обработчика подписка может быть отключена, поэтому контролируйте не только расписание, но и доставку обновлений.
Что делать с расписанием при потере доступа
Рекомендуем помечать публикации затронутого канала как ожидающие восстановления доступа и уведомлять администратора с конкретной причиной. Сохраняйте материал, плановое время и результат последнего запроса. Не запускайте бесконечные повторы при запрете публикации. При ошибке с неизвестным результатом отправки сначала выясните, появился ли пост: повторный запрос без проверки может создать дубликат.
- Останавливайте отправку только в затронутый канал.
- Показывайте, какое действие недоступно и кто должен проверить настройки.
- После возврата прав сначала проверяйте доступ и контрольную публикацию.
- Пропущенное расписание разбирайте по согласованному правилу: перенести, отправить после подтверждения или отменить. Не выгружайте всю очередь автоматически.
Чек-лист проверки перед запуском
Проверяйте не только успешный выход поста. На тестовом канале измените права, убедитесь в доставке события и проверьте реакцию очереди. Затем восстановите согласованный доступ. Удаление бота из канала и изменение его прав — разные ситуации: отдельно предусмотрите проверку членства и обработку ошибок отправки.
- Событие изменения прав включено в подписку и сохраняется обработчиком.
- Права проверяются отдельно для каждого канала.
- При отказе администратор видит причину, а материал остаётся в очереди.
- После восстановления выходит контрольный пост без дубликатов.
- Недоступность webhook и API видна ответственному за сопровождение.
Как это связано с кейсом CRUX
В опубликованном кейсе MAX-бота мы описали управление публикациями, расписанием, периодичностью, рекламными постами, кнопками и комментариями. Материалы и время выбирает администратор. Новое событие изменения прав — повод проверить такой сценарий на актуальном API. В статье не утверждаем, что октябрьское обновление уже внедрено в исторический проект: это отдельная проверка и, при необходимости, доработка.
Источники
Проверено по официальной документации MAX 13 октября 2026 года. Журнал API относит новое событие к октябрю 2026 года без указания дня. Действия с очередью и уведомления ниже — рекомендации CRUX по реализации, а не автоматические функции платформы.