Чек-лист запуска MAX-бота: от верификации до первого прод-сообщения

Платформенный контур

Прежде чем писать код, проверьте скучные вещи, которые чаще всего и тормозят запуск:

• Организация или ИП верифицированы на платформе MAX для партнёров.
• Вы понимаете, кто владелец бота и кто отвечает за токен.
• У команды есть доступ к карточке бота, описанию, аватару и разделу интеграции.
• Вы не вышли за лимит по количеству ботов на организацию.

Большая часть “API не взлетел” на этом этапе связана не с API, а с тем, что у проекта нет владельца платформенного контура.

Токен и доступы

До продового запуска ответьте на три вопроса:

1. Где хранится токен: в секретном хранилище, а не в фронтенде и не в README?
2. Кто умеет отозвать токен, если он утечёт?
3. Есть ли у вас тестовый контур, где вы не трогаете боевой токен?

У MAX больше не поддерживается передача токена через query-параметр, поэтому все актуальные примеры должны использовать заголовок Authorization. Если у вас в кодовой базе остались старые примеры, лучше убрать их до запуска.

События и webhook

Даже если бот на старте делает только одну вещь, лучше сразу решить, как вы будете получать события:

• Для локальной отладки подойдёт GET /updates.
• Для продакшена нужен webhook через POST /subscriptions.
• У webhook должен быть секрет и быстрый ответ сервера.
• Повторная доставка должна быть безопасной для бизнес-логики.

Если этого контура нет, бот остаётся только “отправлялкой сообщений”, а не частью продукта.

Первый боевой тест

Перед запуском сделайте один короткий тест, который проходит человек, не писавший интеграцию:

1. Пользователь запускает бота.
2. Бот отправляет короткое сообщение.
3. Пользователь нажимает кнопку или пишет ответ.
4. Сервер получает событие и логирует результат.

Если этот путь не проходит гладко, не нужно пока думать о сложных кампаниях. Сначала доведите до ума один живой цикл. Дальше уже можно переходить к отправке сообщений и webhook-сценарию.