Ошибка 429 в n8n: как обработать лимит API и не остановить обмен

Ночная выгрузка конкурирует с заявками сайта за один лимит CRM. Разбираем общий бюджет запросов, Retry-After, размер пакета и восстановление очереди после паузы.

Дмитрий Максимов24.09.20265 мин чтения

Светлая керамическая арка пропускает по одному терракотовые шары из очереди: ограничение частоты запросов API.

Содержание

Днём заявки с сайта доходят до CRM без задержек. Ночью запускается обновление каталога: несколько тысяч товаров, для каждого поиск карточки и запись. Утром часть заявок всё ещё ждёт отправки, а журнал заполнен ответами 429. Повторить весь запуск — значит снова занять тот же канал массовой выгрузкой.

Здесь важно управлять общей пропускной способностью интеграции. Рассмотрим учебный контур: n8n принимает заявки и обновляет каталог через один внешний API. Конкретные квоты берут из документации подключённой системы; числа ниже нужны для расчёта, а не описывают тариф какого-либо сервиса.

Найдите, кто расходует один и тот же лимит #

Сначала установите область ограничения: приложение, учётная запись, токен, метод или IP. Два сценария с разными названиями могут обращаться от одного приложения и конкурировать за общий бюджет. Пауза внутри одного workflow не замедлит соседний workflow и внешний скрипт.

Зафиксируйте операции и число обращений на одну запись. Если поиск, чтение и обновление требуют трёх запросов, пакет из ста товаров расходует триста обращений. Пакетная обработка в n8n сама по себе не превращает их в один запрос API: для этого у принимающей системы должен существовать соответствующий пакетный метод.

Нагрузка	Требование к очереди	Что можно сократить
Новая заявка	Обработать в пределах согласованного срока	Повторные чтения справочников
Обновление каталога	Возобновлять с принятой позиции	Запись неизменившихся товаров
Сверка обмена	Не вытеснять рабочие заявки	Проверки без изменившихся данных
Повтор после ошибки	Учитывать в том же бюджете	Немедленные одинаковые попытки

При общей квоте нужен общий диспетчер или согласованное разделение бюджета между отправителями. Не храните независимый счётчик в каждом параллельном запуске, считая его общим ограничителем. Для нескольких процессов потребуется хранилище с атомарным изменением состояния либо другой механизм координации.

Отличите короткую паузу от исчерпания дневной квоты #

Ответ 429 означает ограничение частоты, но его тело может уточнять причину. В одном случае достаточно переждать небольшой интервал, в другом исчерпан дневной бюджет. HTTP 401, неправильный формат данных и закрытый доступ требуют иной реакции. Бесконечное повторение не исправит реквизиты запроса.

Если сервер прислал Retry-After, учитывайте его. По стандарту HTTP значение может быть числом секунд или HTTP-датой. Нельзя разбирать любое значение как целое число и при ошибке считать задержку нулевой. Нужны корректный разбор, учёт времени и ограничение общей длительности обработки.

Сохраните причину паузы и время следующей допустимой попытки. Для дневного ограничения задача остаётся отложенной до разрешённого момента; новые заявки не должны каждые несколько секунд повторять заведомо отклоняемый запрос. Оператору полезнее видеть возраст очереди и причину задержки, чем сотни одинаковых сообщений.

Как собрать управляемую отправку в n8n #

Для простых случаев n8n предлагает Retry On Fail либо Loop Over Items вместе с Wait . Первый вариант задаёт паузу между попытками. Второй помогает разбить обработку на порции и управлять ожиданием. Динамический Retry-After и общие квоты нескольких workflow потребуют отдельной логики — включение переключателя не решает их автоматически.

Ниже внутренняя схема состояния задания, а не экспорт workflow и не параметры готового узла. Время ожидания рассчитывает диспетчер по ответу сервера и согласованной политике.

example.jsonJSON

{
  "job_id": "CATALOG-DEMO-42",
  "quota_scope": "crm-app-main",
  "priority": "background",
  "cursor": "accepted-item-170",
  "state": "waiting_for_quota",
  "attempt": 2,
  "retry_not_before": "2026-09-24T02:15:00+03:00"
}

Курсор продвигают после подтверждённого результата, а не после выдачи задания исполнителю. Для записи с неизвестным результатом сначала проверяют, применилось ли изменение. Иначе повтор после сетевого сбоя может создать дубль; этот случай подробно разобран в статье о повторных действиях агента .

Посчитайте, успеет ли очередь освободиться #

Предположим, проект отвёл обмену 60 запросов в минуту, из которых 15 оставляет заявкам. На один товар нужны три обращения. Каталог получает бюджет 45 запросов, то есть максимум 15 товаров в минуту без учёта сбоев. Для 900 товаров потребуется минимум 60 минут. Если допустимое окно короче, настройка повтора не устранит нехватку пропускной способности.

Варианты решения: получать справочники одним чтением, передавать только изменения, использовать предусмотренный API пакетный метод или пересмотреть доступный лимит. Добавление workers увеличит конкуренцию, если узкое место — внешняя квота. Queue mode управляет исполнением n8n, а не разрешённой частотой стороннего сервиса.

Что проверить при испытании обмена #

Каталог и заявки стартуют одновременно: приоритетные обращения укладываются в принятый срок.
Сервер возвращает Retry-After в обоих форматах: отправка не возобновляется раньше времени.
Процесс перезапущен во время ожидания: курсор и отложенные задания сохранились.
Одна запись некорректна: её ошибка не запускает повтор всего каталога.
Дневная квота закончилась: система показывает причину и ожидаемое возобновление.

Достаточно ли поставить Wait на одну секунду? #

Только если такой интервал соответствует реальному контракту API и остальные отправители не расходуют тот же бюджет. При параллельных запусках каждый может соблюдать свою паузу и вместе с остальными превышать общий лимит.

Когда очередь нужно остановить и разбирать вручную? #

Когда истёк срок обработки, причина отказа не допускает повтора либо нельзя определить результат предыдущей записи. Сохранённое задание с диагностикой позволяет продолжить после исправления; молчаливый пропуск записи создаёт расхождение систем.

Поможем восстановить обмен с учётом реальных ограничений #

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