Ошибка 429 в MAX Bot API: что делать, когда канал просит сбавить темп

Почему появляется 429

Ошибка 429 Too Many Requests в MAX Bot API обычно означает очень простую вещь: вы посылаете запросы быстрее, чем канал сейчас готов переварить. Это не “MAX сломан”, не “бот умер” и не повод сразу менять платформу.

В официальной документации MAX есть верхняя граница до 30 запросов в секунду дляplatform-api.max.ru. Но верхняя граница и безопасный рабочий режим это разные вещи. Молодой продукт чаще всего ловит 429 не на огромной нагрузке, а на кривом ретрае, импорте контактов или наивной массовой отправке без очереди.

Где продукт обычно ломается

Сам код 429 редко убивает продукт сам по себе. Проблема начинается дальше, когда команда обрабатывает его эмоционально, а не инженерно.

• Фронт или worker тут же повторяет запрос и ещё сильнее разгоняет нагрузку.
• Один и тот же message job уходит дважды, потому что у него нет своего idempotency key.
• Оператор видит хаос в статусах и не понимает, ушло сообщение или нет.
• Воронка “подключил канал → отправил первое сообщение” ломается на самом важном месте.

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

Очередь и ограничение темпа

Самое полезное, что можно сделать против 429, это убрать отправку из прямой синхронной логики и пустить её через очередь. Тогда MAX перестаёт быть местом, где вы спорите с платформой в реальном времени.

const deliveryPolicy = {
  channel: "maxbot",
  initialRps: 10,
  officialCeilingRps: 30,
  maxParallelPerBot: 1,
  retry: {
    maxAttempts: 5,
    strategy: "exponential-jitter",
  },
};

Здесь важно понимать логику. initialRps: 10 это не “официальный лимит”. Это спокойный стартовый режим для новой интеграции. Дальше вы поднимаете темп уже по данным, а не по форумным советам.

Как повторять без дублей

На 429 обычно нужен retry, но не мгновенный и не бесконечный. Хороший контур выглядит скучно: собственный идентификатор сообщения, очередь, отложенный повтор и понятный предел попыток.

1. Назначайте сообщению свой clientId или delivery key ещё до первой отправки.
2. Повторяйте только после задержки, а не сразу после ответа 429.
3. После нескольких неудач отправляйте задачу в DLQ или переключайте канал.

async function handle429(job) {
  const nextAttempt = job.attempt + 1;
  const delayMs = Math.min(1000 * 2 ** job.attempt, 30000);

  await queue.retry({
    ...job,
    attempt: nextAttempt,
  }, delayMs);
}

async function sendJob(job) {
  try {
    return await maxClient.send(job.payload);
  } catch (error) {
    if (error.status === 429) {
      await handle429(job);
      return { queued: true };
    }
    throw error;
  }
}

Если MAX возвращает дополнительную информацию о времени ожидания, уважайте её. Если нет, используйте обычный exponential backoff с jitter и не пытайтесь “продавить” канал силой.

Какие сигналы смотреть

Чтобы 429 не превращался в шаманство, заведите хотя бы минимальный набор наблюдаемости:

Если после этого вопрос не в 429, а в общей архитектуре канала, обычно следующим логичным чтением становится либо массовая отправка через MAX, либо встраивание MAX в CRM или SaaS.

429 это не приговор каналу. Это просто момент, в котором ваша интеграция получает честную обратную связь: темп нужно контролировать, а не надеяться, что “как-нибудь проскочит”.