Как создать бота в MAX: пошаговый гайд для бизнеса

MAX — национальный мессенджер от VK Tech, который в 2025–2026 годах стал отдельной площадкой для бизнес-ботов наряду с Telegram. С точки зрения разработчика логика похожа на Telegram Bot API, но есть свои нюансы: российская юрисдикция оператора, локализация по умолчанию, интеграция с экосистемой VK Tech и собственный набор методов API. Ниже — практический маршрут от пустого репозитория до бота, которым уже пользуются клиенты, с примерами кода на Python и Node.js.

Что такое бот в MAX и чем он отличается от Telegram-бота

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

Принципиальные отличия от Telegram, которые важно учесть на старте:

• Юрисдикция оператора. MAX принадлежит российской компании, серверы и обработка данных — в РФ. Это снимает часть вопросов по 152-ФЗ и трансграничной передаче, которые висят над Telegram-ботами.
• Локализация. Аудитория — преимущественно русскоязычная, поэтому UX, тексты, валюты и форматы дат можно сразу делать без английского fallback.
• Интеграция с VK Tech. Учётные записи, OAuth и часть инфраструктурных сервисов (хранилища, аналитика) удобно стыкуются с экосистемой VK ID и VK Cloud.
• Зрелость API. Bot API в MAX моложе Telegram, поэтому отдельные продвинутые фичи (некоторые типы клавиатур, расширенные платежи, отдельные виды апдейтов) появляются позже. Перед стартом проверяйте актуальную страницу dev.max.ru/docs.
• Лимиты и rate-limit. Точные цифры могут отличаться от Telegram; стандартно для MAX Bot API закладывают консервативные лимиты на исходящие сообщения и проектируют рассылки с очередью.

С архитектурной точки зрения бот в MAX делается теми же подходами, что и Telegram-бот: HTTPS-обработчик апдейтов, FSM, БД, очередь, мониторинг. Большая часть наработок Telegram-команды переезжает с минимальными правками на уровне SDK.

Шаг 1. Регистрация бота и получение токена

Регистрация бота в MAX выполняется через официальный родительский бот мессенджера (на момент написания статьи — аналог BotFather в Telegram, иногда его называют MasterBot). Сценарий стандартно для MAX Bot API такой:

1. Открыть чат с родительским ботом.
2. Команда /newbot (или эквивалент в актуальной версии).
3. Указать имя бота (отображается пользователям).
4. Указать username — должен быть уникальным.
5. Получить токен формата BOT_ID:SECRET — длинная строка, которая авторизует все запросы к API.

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

Сразу после регистрации полезно настроить:

• описание бота (то, что видит пользователь на пустом экране чата);
• короткий текст «о боте» для профиля;
• аватар (квадратное изображение, обычно 640×640);
• список команд через setBotCommands — подсказывается при вводе /.

Пример настройки списка команд через REST-вызов (стандартно для MAX Bot API метод выглядит так — точные имена сверьте по dev.max.ru/docs):

curl -X POST "https://botapi.max.ru/bot${BOT_TOKEN}/setBotCommands" \
  -H "Content-Type: application/json" \
  -d '{
    "commands": [
      { "command": "start",   "description": "Запустить бота" },
      { "command": "help",    "description": "Справка" },
      { "command": "order",   "description": "Сделать заказ" },
      { "command": "support", "description": "Связаться с оператором" }
    ]
  }'

Меню команд — это первое, что видит пользователь, и оно влияет на конверсию: формулируйте кратко, в инфинитиве, без жаргона.

Шаг 2. Базовые сущности MAX Bot API

Чтобы не утонуть в документации, держите в голове минимальный набор сущностей, с которыми вы будете работать каждый день:

• update — событие, которое Bot API присылает боту. Содержит один из типов: новое сообщение, нажатие кнопки, изменение участника чата, callback и т. д.
• chat — диалог. Может быть приватным (1-на-1 с пользователем), групповым или каналом. У каждого чата есть числовой id.
• user — пользователь. Идентифицируется числовым id (стабильный) и опциональным username (может меняться — не используйте как ключ).
• message — сообщение. Содержит text, опциональные вложения (photo, document, audio), reply_to_message, метаданные.
• callback (или callback_query — стандартно для MAX Bot API) — событие нажатия inline-кнопки. У него есть data (что прислала кнопка) и ссылка на исходное сообщение.
• file — вложение. Загружается отдельным методом, на выходе — file_id, который можно переиспользовать без повторной загрузки.

Все методы API, как правило, возвращают объект вида { "ok": true, "result": ... } либо { "ok": false, "description": "..." }. На уровне SDK это уже разворачивается в типизированные структуры, но при отладке через curl полезно помнить о такой обёртке.

Шаг 3. Long polling vs webhook

Стандартно для MAX Bot API доступны два режима получения апдейтов:

• Long polling — бот сам периодически опрашивает API на новые события. Не требует HTTPS и публичного адреса, удобно для прототипа и локальной разработки.
• Webhook — MAX сам присылает апдейты на указанный HTTPS-эндпоинт. Меньше задержка, лучше масштабируется, дешевле по ресурсам, используется в продакшене.

Краткое сравнение:

Подробный разбор настройки webhook в MAX — тема отдельной статьи: там же про IP allowlist, secret-token, ретраи и идемпотентность. В этом гайде для краткости все примеры — на long polling, чтобы можно было запустить локально без публичного адреса.

Шаг 4. Выбор стека

Для бота в MAX, как и для Telegram, рабочих стеков три:

• Python — aiogram-style фреймворки (на момент написания SDK для MAX появляются как форки aiogram/community-библиотек). Удобно за счёт async, валидации апдейтов и встроенного FSM.
• Node.js / TypeScript — node-fetch/undici поверх REST API или тонкие SDK. TS-first дизайн помогает в больших проектах.
• Go — прямые HTTPS-запросы или community-SDK. Подходит для нагрузочных сценариев.

Сводная таблица под выбор:

Если SDK для MAX в выбранном языке ещё незрелый — рабочая стратегия — взять тонкий HTTP-клиент и написать обёртки только над теми методами, которые реально используются (обычно это 5–10 методов).

Шаг 5. Минимальный handler /start на Python

Пример демонстрирует структуру, которую вы будете повторять для каждого нового хендлера. Имена методов SDK условны — стандартно для MAX Bot API подменяйте на актуальные из dev.max.ru/docs.

import asyncio
import logging
import os

import httpx

logging.basicConfig(level=logging.INFO)
log = logging.getLogger("max-bot")

BOT_TOKEN = os.getenv("MAX_BOT_TOKEN")
if not BOT_TOKEN:
    raise RuntimeError("MAX_BOT_TOKEN env var is required")

API_BASE = f"https://botapi.max.ru/bot{BOT_TOKEN}"


async def send_message(client: httpx.AsyncClient, chat_id: int, text: str) -> None:
    resp = await client.post(
        f"{API_BASE}/sendMessage",
        json={"chat_id": chat_id, "text": text},
        timeout=10.0,
    )
    resp.raise_for_status()


async def handle_update(client: httpx.AsyncClient, update: dict) -> None:
    message = update.get("message")
    if not message:
        return
    text = (message.get("text") or "").strip()
    chat_id = message["chat"]["id"]
    user = message.get("from", {})
    name = user.get("first_name") or "друг"

    if text == "/start":
        await send_message(client, chat_id, f"Привет, {name}! Я бот студии. Напиши /help.")
    elif text == "/help":
        await send_message(client, chat_id, "Команды: /start, /help, /order")
    else:
        await send_message(client, chat_id, f"Вы написали: {text}")


async def main() -> None:
    offset = 0
    async with httpx.AsyncClient() as client:
        while True:
            try:
                resp = await client.get(
                    f"{API_BASE}/getUpdates",
                    params={"timeout": 30, "offset": offset},
                    timeout=40.0,
                )
                data = resp.json()
                for upd in data.get("result", []):
                    offset = upd["update_id"] + 1
                    await handle_update(client, upd)
            except Exception:
                log.exception("update loop error")
                await asyncio.sleep(2)


if __name__ == "__main__":
    asyncio.run(main())

Запуск: MAX_BOT_TOKEN=... python bot.py. Зависимость одна — httpx. Этого достаточно, чтобы получить рабочий echo-бот за 5 минут и убедиться, что токен валиден.

Шаг 6. Минимальный handler на Node.js

Тот же echo-сценарий на Node.js без специфичного SDK — только fetch (доступен нативно в Node 18+):

const BOT_TOKEN = process.env.MAX_BOT_TOKEN;
if (!BOT_TOKEN) throw new Error("MAX_BOT_TOKEN env var is required");

const API_BASE = `https://botapi.max.ru/bot${BOT_TOKEN}`;

async function call(method, body) {
  const resp = await fetch(`${API_BASE}/${method}`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  if (!resp.ok) throw new Error(`${method} failed: ${resp.status}`);
  return resp.json();
}

async function handleUpdate(update) {
  const message = update.message;
  if (!message) return;
  const text = (message.text || "").trim();
  const chatId = message.chat.id;
  const name = message.from?.first_name || "друг";

  if (text === "/start") {
    await call("sendMessage", { chat_id: chatId, text: `Привет, ${name}!` });
  } else if (text === "/help") {
    await call("sendMessage", { chat_id: chatId, text: "Команды: /start, /help" });
  } else {
    await call("sendMessage", { chat_id: chatId, text: `Вы написали: ${text}` });
  }
}

async function main() {
  let offset = 0;
  while (true) {
    try {
      const url = `${API_BASE}/getUpdates?timeout=30&offset=${offset}`;
      const resp = await fetch(url);
      const data = await resp.json();
      for (const upd of data.result || []) {
        offset = upd.update_id + 1;
        await handleUpdate(upd);
      }
    } catch (err) {
      console.error("update loop error", err);
      await new Promise((r) => setTimeout(r, 2000));
    }
  }
}

main();

Запуск: MAX_BOT_TOKEN=... node bot.js. Это рабочий каркас, на котором можно постепенно наращивать функциональность.

Шаг 7. Inline-кнопки и callback

Inline-кнопки — главный инструмент UX в боте: они компактны, не загромождают чат и позволяют строить полноценные интерфейсы. Стандартно для MAX Bot API кнопки задаются в поле reply_markup сообщения, а нажатие приходит как callback-апдейт с полем data.

Пример отправки сообщения с двумя кнопками и обработки нажатия (Python):

async def show_menu(client: httpx.AsyncClient, chat_id: int) -> None:
    await client.post(
        f"{API_BASE}/sendMessage",
        json={
            "chat_id": chat_id,
            "text": "Выберите действие:",
            "reply_markup": {
                "inline_keyboard": [
                    [
                        {"text": "Сделать заказ",     "callback_data": "act:order"},
                        {"text": "Связаться с нами",  "callback_data": "act:contact"},
                    ],
                    [{"text": "О компании", "callback_data": "act:about"}],
                ]
            },
        },
        timeout=10.0,
    )


async def handle_callback(client: httpx.AsyncClient, cb: dict) -> None:
    data = cb.get("data", "")
    chat_id = cb["message"]["chat"]["id"]
    cb_id = cb["id"]

    # обязательно подтверждаем callback, иначе у пользователя крутится индикатор
    await client.post(
        f"{API_BASE}/answerCallbackQuery",
        json={"callback_query_id": cb_id},
        timeout=10.0,
    )

    if data == "act:order":
        await send_message(client, chat_id, "Окей, оформляем заказ. Пришлите название товара.")
    elif data == "act:contact":
        await send_message(client, chat_id, "Менеджер ответит в течение 15 минут.")
    elif data == "act:about":
        await send_message(client, chat_id, "Мы делаем ботов в MAX и Telegram с 2022 года.")

И добавьте в handle_update ветку:

if "callback_query" in update:
    await handle_callback(client, update["callback_query"])
    return

Главные правила работы с callback:

• Всегда отвечайте на callback (answerCallbackQuery) — иначе у пользователя крутится спиннер.
• callback_data ограничен по длине (стандартно для MAX Bot API — десятки байт). Не пихайте JSON с длинными ID; используйте короткие префиксы и хранилище соответствий в Redis.
• Не доверяйте callback_data — это пользовательский ввод. Проверяйте права на действие на сервере.

Шаг 8. Состояния диалога (FSM)

Как только бот выходит за пределы echo, появляется потребность помнить «на каком шаге пользователь». Это решается через FSM (finite state machine): каждому пользователю в каждом чате соответствует текущее состояние и набор данных.

Минимальная схема таблицы состояний в PostgreSQL:

CREATE TABLE fsm_states (
  user_id     BIGINT      NOT NULL,
  chat_id     BIGINT      NOT NULL,
  state       TEXT        NOT NULL,
  data        JSONB       NOT NULL DEFAULT '{}'::jsonb,
  updated_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  PRIMARY KEY (user_id, chat_id)
);

В проде состояния обычно держат в Redis для скорости и снимают слепки в Postgres для аналитики. Подробный разбор FSM с примерами на aiogram-style коде, экранами, переходами и обработкой «уходов» пользователя — тема отдельной статьи.

Главное правило: не храните FSM в памяти процесса. При рестарте контейнера всё пропадёт, а в нескольких репликах за балансером пользователь будет каждый раз попадать в разное состояние.

Шаг 9. Хранение данных

Минимальный набор таблиц для бизнес-бота:

• users — user_id, username, first_name, created_at, согласие на обработку ПДн.
• chats — chat_id, type, метаданные.
• fsm_states — текущее состояние диалога (см. выше).
• events — лента событий (типы апдейтов, нажатия, конверсии) для аналитики.
• leads / orders — бизнес-сущности конкретного бота.

Под прототип хватает SQLite — один файл, ноль администрирования, можно положить в data/bot.db рядом с кодом. Под прод — PostgreSQL: транзакции, JSONB, нормальный бэкап, репликация. Redis — для FSM, кэшей и очередей.

# простой пример с SQLite для прототипа
import sqlite3

conn = sqlite3.connect("data/bot.db")
conn.execute("""
  CREATE TABLE IF NOT EXISTS users (
    user_id    INTEGER PRIMARY KEY,
    username   TEXT,
    first_name TEXT,
    created_at TEXT NOT NULL
  )
""")
conn.commit()

Когда счёт пользователей пойдёт на тысячи — мигрируйте в Postgres. Раньше — не надо: SQLite держит десятки тысяч пользователей без проблем, если запись не идёт из десятка процессов одновременно.

Шаг 10. Локальная разработка с туннелем

Для long polling туннель не нужен — бот сам ходит к API. Но как только вы переходите на webhook (а на него вы перейдёте перед релизом), нужен публичный HTTPS-адрес.

Два рабочих инструмента:

• ngrok — ngrok http 8000 поднимает туннель к локальному порту, выдаёт https://<id>.ngrok.io. Бесплатный план достаточен для разработки.
• cloudflared — cloudflared tunnel --url http://localhost:8000. Бесплатный, стабильнее ngrok на больших объёмах.

Полученный URL прописываете в webhook через setWebhook — и с этого момента MAX начинает слать апдейты на ваш ноут. Не забудьте перед коммитом и деплоем поменять URL на боевой домен.

Шаг 11. Безопасность токена и секретов

Базовое правило: ни один секрет не лежит в коде и в git.

• Локально — файл .env с переменными, добавлен в .gitignore. Загружается через python-dotenv / dotenv при старте.
• CI/CD — GitHub Actions Secrets, GitLab CI Variables. Не печатаются в логах сборки.
• Прод — Yandex Lockbox, HashiCorp Vault или системный /etc/bot.env с правами 600.

Минимальный .env для бота в MAX:

# .env (никогда не коммитить!)
MAX_BOT_TOKEN=123456789:AAEhBPNotARealTokenJustExample
DATABASE_URL=postgres://bot:password@localhost:5432/botdb
REDIS_URL=redis://localhost:6379/0
WEBHOOK_SECRET=please-generate-a-long-random-string
LOG_LEVEL=INFO

И .gitignore:

.env
.env.*
!.env.example
*.key
*.pem
data/*.db
__pycache__/
node_modules/

Что делать при утечке токена — действовать быстро: отозвать токен через родительский бот MAX, получить новый, обновить переменную окружения, перезапустить сервис, найти и закрыть источник утечки. Если токен попал в git — переписать историю (git filter-repo) и сделать force push.

Шаг 12. Минимальный Dockerfile и деплой

Для прода удобнее всего упаковать бота в Docker-образ. Минимальный Dockerfile под Python-бота:

FROM python:3.12-slim AS base

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1 \
    PIP_NO_CACHE_DIR=1

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

# не запускайтесь от root в проде
RUN useradd -u 1000 -m bot && chown -R bot /app
USER bot

CMD ["python", "bot.py"]

И docker-compose.yml с PostgreSQL и Redis:

services:
  bot:
    build: .
    env_file: .env
    restart: unless-stopped
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: bot
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: botdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes"]
    volumes:
      - redisdata:/data

volumes:
  pgdata:
  redisdata:

Сценарий деплоя на VPS: git pull && docker compose up -d --build. Для нулевого даунтайма добавьте healthcheck и rolling update через docker-compose или Nomad/Kubernetes — но это уже за рамками первой версии.

Шаг 13. Тестирование

Перед публикацией прогоните минимум четыре сценария руками:

1. /start от нового пользователя — корректное приветствие, запись в БД.
2. Полный путь по основной воронке — от первой команды до целевого действия.
3. Нажатия на каждую inline-кнопку — нет «висящих» спиннеров и неотвеченных callback.
4. Поведение при ошибке — что произойдёт, если CRM вернёт 500 или БД временно недоступна.

Автотесты на бот делятся на два слоя:

• Юнит-тесты бизнес-логики — обычные тесты функций, которые принимают входной апдейт и возвращают список действий. Не зависят от сети.
• Интеграционные с моком API — поднимаете локальный HTTP-сервер, который притворяется MAX Bot API, и прогоняете сценарий целиком.

Минимальный пример мока на Python (pytest + pytest-httpx):

import pytest
from httpx import Response

@pytest.mark.asyncio
async def test_start_command(httpx_mock):
    httpx_mock.add_response(
        url="https://botapi.max.ru/bot123/sendMessage",
        json={"ok": True, "result": {"message_id": 1}},
    )
    # ... вызов handle_update с фейковым апдейтом ...
    # assert по содержимому отправленного запроса

Этого достаточно, чтобы поймать большинство регрессий до деплоя.

Шаг 14. Чек-лист «MVP за неделю»

Реалистичный план запуска первого бота в MAX за 5–7 рабочих дней:

• День 1 — регистрация бота, получение токена, описание/аватар, минимальный /start на long polling.
• День 2 — основной сценарий диалога на бумаге, схема экранов и кнопок, согласование текстов.
• День 3 — реализация сценария: inline-кнопки, callback, переходы между состояниями.
• День 4 — БД (SQLite или Postgres), сохранение пользователей и заявок, FSM для диалога.
• День 5 — интеграция с CRM или хотя бы дублирование заявок в чат поддержки, базовый логинг.
• День 6 — деплой на VPS в Docker, переход на webhook, настройка домена и TLS, секреты в env.
• День 7 — ручное тестирование основных сценариев, мониторинг (Sentry или хотя бы алерты в чат), публикация.

Чего в этом плане сознательно нет: оплата, AI, мульти-языковая поддержка, мини-приложение. Всё это — следующие итерации, а не MVP.

Шаг 15. Типичные ошибки новичков

• Хардкод токена в bot.py — через неделю код уезжает в репозиторий, токен в публичном доступе. Сразу os.environ или .env.
• FSM в памяти процесса — бот рестартует, состояния всех пользователей пропадают. Используйте Redis или БД.
• Игнорирование лимитов — массовая рассылка из основного процесса кладёт бота. Выносите в очередь и шлите со скоростью, которую держит API (стандартно для MAX Bot API — десятки сообщений в секунду на бот, точные цифры — в dev.max.ru/docs).
• Не отвечать на callback — у пользователя бесконечно крутится спиннер. Всегда answerCallbackQuery, даже если делать ничего не нужно.
• username как идентификатор — пользователь сменил username, бот потерял привязку. Идентификатор всегда user.id (число).
• Webhook без проверки секрета — кто угодно может слать поддельные апдейты, зная URL. Всегда сверяйте заголовок secret_token.
• Webhook без ack 200 — обработчик упал, MAX повторяет апдейт, в логах буря. Возвращайте 200 даже при ошибке (а ошибку — в Sentry).
• Длинный callback_data — не помещается в лимит, ошибка 400. Используйте короткие префиксы, длинные данные — в Redis по ключу.
• Зависимость от внешнего API без таймаута — CRM лежит, бот зависает. Таймауты, ретраи, circuit breaker.
• Отсутствие согласия на ПДн — нарушение 152-ФЗ с самого старта. На первом экране — ссылка на политику и явное согласие.

Шаг 16. Дальнейшие шаги

Когда MVP запущен и пользователи пошли — расширять стоит постепенно, а не сразу всё:

• Платежи — встроенные платежи MAX (стандартно для MAX Bot API через специальный метод; точная схема — в dev.max.ru/docs) или внешний эквайринг через ссылку (ЮKassa, СБП).
• AI-консультант — RAG поверх базы знаний с YandexGPT или GigaChat для соответствия 152-ФЗ.
• CRM-интеграция — двусторонняя: заявки уходят в amoCRM/Битрикс24/RetailCRM, статусы возвращаются обратно в чат с пользователем.
• Мини-приложение — фронт на Next.js/React с верификацией initData от MAX, бэкенд — REST/GraphQL.
• Аналитика — своя таблица событий + дашборд в Metabase/Superset.
• Рассылки — отдельный воркер с очередью, сегментацией, A/B-тестами и метриками доставляемости.
• Поддержка живого оператора — переключение из бота в чат с менеджером с сохранением истории.

Каждое из этих направлений — это отдельный проект на 2–6 недель. Не пытайтесь сделать всё в первой версии: лучше иметь работающий бот с базовой функциональностью и обратной связью от пользователей, чем «идеальный» прототип, который не доехал до релиза.

Итого

Создание бота в MAX в 2026 году — это не «написать код», а связать в одну систему диалог, БД, интеграции и инфраструктуру. Технический фундамент похож на Telegram Bot API, но с поправками на российскую юрисдикцию, экосистему VK Tech и зрелость отдельных методов API. Самостоятельный путь до MVP — 5–7 рабочих дней на простой бот и 1–3 месяца на полноценный продакшн с интеграциями. Под ключ — от 14 дней. Ключевые принципы: не хардкодить токены, держать состояние вне памяти процесса, всегда отвечать на callback, оборачивать внешние вызовы в очередь и закладывать мониторинг с первого дня.

Частые вопросы

Как создать бота в MAX с нуля?+

Маршрут такой: 1) зарегистрировать бота через официальный родительский бот MAX и получить токен; 2) выбрать стек (Python/aiogram-style, Node.js или прямые HTTPS-запросы); 3) написать минимальный handler на /start через long polling; 4) добавить inline-кнопки и callback для основного сценария; 5) подключить БД (SQLite для прототипа, PostgreSQL для прода) и FSM в Redis; 6) перейти на webhook и развернуть в Docker на VPS; 7) подключить мониторинг и алерты. MVP реалистично собрать за 5–7 рабочих дней, полноценный прод — 1–3 месяца.

Чем бот в MAX отличается от Telegram-бота?+

Принципиально похож, отличия в нюансах: российская юрисдикция оператора (упрощает 152-ФЗ и трансграничную передачу), русскоязычная аудитория по умолчанию, интеграция с экосистемой VK Tech (VK ID, VK Cloud), более молодой Bot API (часть продвинутых фич появляется позже), возможные отличия в лимитах и rate-limit. Архитектурные подходы (HTTPS-обработчик, FSM, БД, очередь, мониторинг) переносятся между платформами почти без изменений.

Какой стек выбрать для бота в MAX?+

Для MVP и типовых бизнес-ботов — Python с aiogram-style фреймворком или httpx-обёртками: быстрая разработка, FSM из коробки, большое сообщество. Для команд с фронтенд-уклоном или с планом делать Mini App — Node.js/TypeScript. Для нагрузочных сценариев с большими рассылками — Go. Если SDK для MAX в выбранном языке ещё незрелый, рабочая стратегия — тонкий HTTP-клиент и обёртки над 5–10 нужными методами API. Сводная таблица плюсов и минусов есть в основном тексте статьи.

Что такое webhook и polling в MAX Bot API?+

Два режима получения апдейтов. Long polling — бот сам периодически опрашивает API; не требует HTTPS, удобно для прототипа и локальной разработки. Webhook — MAX сам шлёт апдейты на указанный HTTPS-эндпоинт; меньше задержка (<300мс), лучше масштабируется, используется в продакшене. На webhook переходят перед релизом — это требует публичного домена с валидным TLS, проверки секретного заголовка и идемпотентной обработки. Подробный разбор настройки — в отдельной статье.

Как защитить токен бота в MAX?+

Базовое правило: токен никогда не лежит в коде и в git. Локально — .env в .gitignore, загружается через python-dotenv или dotenv. В CI/CD — через GitHub Actions Secrets или GitLab Variables. В проде — Yandex Lockbox, HashiCorp Vault или системный /etc/bot.env с правами 600. При утечке немедленно отзовите токен через родительский бот MAX, выпустите новый, обновите переменную окружения и перезапустите сервис. Если токен попал в историю git — переписать через git filter-repo и сделать force push.

Какая БД нужна боту в MAX?+

Под прототип хватает SQLite — один файл, ноль администрирования. Под прод — PostgreSQL для бизнес-данных (пользователи, заявки, заказы, события) и Redis для FSM-состояний и кэшей. Хранение FSM в Redis позволяет разворачивать бота в нескольких репликах за балансировщиком и переживать рестарты без потери контекста пользователя. Не храните состояния в памяти процесса — при рестарте всё пропадёт, в нескольких репликах пользователь будет каждый раз попадать в разное состояние.

Сколько занимает разработка бота в MAX под ключ?+

Простой бот для приёма заявок с базовыми экранами и интеграцией с одной CRM — 14–21 день. Бот среднего уровня с воронкой, FSM, оплатой и интеграциями с двумя-тремя внешними системами — 4–6 недель. Сложный бот с AI-консультантом, мини-приложением, мульти-интеграциями и админкой — 8–12 недель. Платформа уровня корпоративного портала или ERP-надстройки — от 3 месяцев. Самостоятельная разработка обычно занимает в 1,5–2 раза больше из-за времени на освоение API и архитектурных переделок.