Обработка ограничений скорости API: Wait, Batching, Retry, Pagination

Тот, кто строит собственные workflow против API сторонних сервисов, рано или поздно сталкивается с ответом 429: «Too Many Requests». Особенно при массовой обработке, например при обогащении сотен контактов CRM или синхронизации крупных каталогов товаров, это не исключение, а правило. Для этого в n8n есть несколько встроенных инструментов, которые можно комбинировать: нода Wait, настройка Retry on Fail в ноде HTTP Request, Batching и управление пагинацией. Актуально на июль 2026.

Хитрость не в том, чтобы найти одну функцию, которая «решает» ограничения скорости, а в том, чтобы выбрать правильную комбинацию для конкретного случая использования. Отдельному вызову API с редким сбоем нужно нечто иное, чем циклу по десяти тысячам записей. Далее мы разберём оба сценария, опираясь на официальную документацию n8n.

Как распознать проблему с ограничением скорости

Согласно документации n8n об ограничениях скорости сервис обычно сообщает о слишком большом количестве запросов кодом статуса HTTP 429 и сообщением об ошибке о том, что сервис получает «слишком много запросов от вас». Это сообщение появляется в выводе ноды, когда запрос завершается неудачей, и является первым признаком того, что дело не в неверных учётных данных или URL, а просто в том, что за слишком короткое время уходит слишком много запросов. Важно для диагностики: ошибка 429 может возникнуть даже в середине workflow, который до этого сотни раз отрабатывал без ошибок, например потому что сторонний провайдер временно ужесточил лимит во время кампании или пикового трафика. Тем, кто часто работает с одним и тем же API, стоит знать его документацию по ограничениям скорости ещё до того, как workflow попадёт в продакшн.

Retry on Fail: автоматическое повторение отдельных запросов

Для workflow со случайными, несистематическими ошибками 429 часто достаточно встроенной логики повтора в ноде HTTP Request. В Settings ноды вы включаете Retry On Fail и задаёте два значения:

• Max Tries определяет, сколько раз n8n максимум повторит запрос после сбоя.
• Wait Between Tries (ms) определяет паузу между попытками в миллисекундах.

Согласно документации о частых проблемах ноды HTTP Request если вы используете эту настройку целенаправленно против ограничений скорости, стоит установить Wait Between Tries (ms) на значение выше лимита сервиса. Например, если API разрешает один запрос в секунду, установите 1000 миллисекунд, чтобы вторая попытка не попала снова в тот же лимит. Преимущество этого метода: он настраивается несколькими кликами в той же ноде, без дополнительных нод на холсте. Недостаток: при очень большом количестве элементов в цикле время ожидания быстро умножается, а без дополнительного управления n8n продолжает отправлять как можно больше запросов ещё до того, как вернётся первая ошибка.

Batching в ноде HTTP Request: осознанное дросселирование запросов

Если вы заранее знаете, что у API строгие лимиты, разумнее заранее контролировать частоту запросов, а не только реагировать на ошибки. Для этого нода HTTP Request предлагает под Add Option > Batching две настройки:

• Items per Batch: сколько входных элементов обрабатывается за один раунд запросов.
• Batch Interval (ms): пауза между пакетами в миллисекундах.

Согласно документации, эта опция batching функционально соответствует комбинации Loop Over Items и ноды Wait, только встроенной в одну ноду. Если вы, например, хотите отправлять один запрос в секунду к сервису, установите Batch Interval (ms) на 1000. Для API с лимитами в минуту, а не в секунду, вы пересчитываете соответственно, например 60 запросов в минуту дают интервал в 1000 миллисекунд между отдельными запросами или больший интервал при нескольких элементах на пакет. Для массовой обработки это более надёжная базовая настройка, потому что она решает проблему в корне, а не реагирует только после сбоя.

Loop Over Items и нода Wait: полный контроль над ритмом

Для случаев, когда между пакетами вам нужна собственная логика, например логирование, условное ветвление или динамическая настройка времени ожидания в зависимости от ответа, вы комбинируете Loop Over Items с собственной нодой Wait. Структура: разместите Loop Over Items перед вызовом API, затем вставьте ноду Wait и подключите её выход обратно к Loop Over Items. Так получается цикл, который осознанно делает паузу после каждого пакета или каждого отдельного элемента, прежде чем начнётся следующий раунд.

Сама нода Wait, согласно документации n8n о ноде Wait предназначена для того, чтобы приостановить выполняющийся процесс и затем продолжить его с теми же данными с того места, где он был прерван. Для темы ограничений скорости особенно актуален режим After Time Interval: вы указываете промежуток времени в секундах, минутах, часах или днях, и workflow приостанавливается ровно на это время. Важно знать: при времени ожидания менее 65 секунд n8n не выгружает данные выполнения в базу данных, поэтому пауза выполняется легковесно в оперативной памяти. При более длительном ожидании n8n автоматически берёт на себя кэширование, что делает workflow надёжно возобновляемым даже после перезапуска инстанса. Помимо After Time Interval нода также поддерживает At Specified Time, On Webhook Call и On Form Submitted, которые предназначены для других сценариев, например внешних согласований или запланированных запусков, но редко нужны для чистого rate limiting.

Аккуратное управление пагинацией вместо загрузки всего сразу

Частая причина ошибок ограничения скорости на самом деле не в частоте запросов, а в их количестве: тот, кто пытается пагинировать десять тысяч записей за один неограниченный проход, за короткое время создаёт очень много запросов подряд. Согласно документации n8n о пагинации нода HTTP Request поддерживает для этого разные режимы:

• Response Contains Next URL: API возвращает в своём ответе прямо URL следующей страницы, который вы считываете через выражение, например `{{ $response.body["next-page"] }}`.
• Update a Parameter in Each Request: вы сами увеличиваете параметр query или body между запросами, например с помощью `{{ $pageCount + 1 }}` для счёта, начинающегося с нуля, который нужно согласовать с пагинацией API, начинающейся с единицы.

Документация прямо указывает, что каждый API реализует пагинацию по-своему. Поэтому вам стоит заранее проверить, работает ли сервис с next-URL, номерами страниц или offset-параметрами, и сколько результатов на странице разрешено максимум. Размер страницы вы обычно задаёте через собственный query-параметр, например `limit`, в настройках ноды. Комбинируя пагинацию с batching или нодой Wait между запросами страниц, вы предотвращаете ситуацию, когда объёмный экспорт данных упирается в лимит просто из-за своей скорости, ещё до того, как начнётся собственно обработка.

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

На практике полезна грубая классификация того, какой инструмент когда применяется:

• Редкие ошибки 429 при низком объёме: обычно достаточно Retry On Fail с подходящим Wait Between Tries.
• Известный, фиксированный лимит скорости при высоком объёме: Batching в ноде HTTP Request с интервалом, соответствующим лимиту сервиса.
• Более сложная логика между вызовами, например динамические паузы в зависимости от заголовка ответа или дополнительные ветвления: Loop Over Items в сочетании с собственной нодой Wait.
• Большие объёмы данных на нескольких страницах: выбрать режим пагинации, соответствующий API, и дополнительно смягчить его с помощью batching или Wait.

На практике для полноценного workflow редко хватает одного инструмента. Типичный паттерн: пагинация для получения данных, умеренный интервал батчей во время обработки и дополнительно Retry On Fail как страховочная сетка на случай, если даже сниженная скорость всё же приведёт к отдельной ошибке 429. Так вы сохраняете контроль над темпом и надёжностью своего workflow, вместо того чтобы полагаться на удачу, что сторонний провайдер никогда не окажется под нагрузкой.

Часто задаваемые вопросы

В чём разница между Retry On Fail и Batching?

Retry On Fail реагирует только после того, как запрос уже завершился неудачей, и повторяет его после заданного времени ожидания. Batching действует заранее и с самого начала ограничивает, сколько запросов и с каким интервалом вообще отправляется. Для известных, фиксированных лимитов Batching является более чистым решением, а для редких непредсказуемых сбоев Retry On Fail дополняет его как подстраховку.

Начиная с какого времени ожидания нода Wait сохраняет выполнение в базе данных?

Согласно документации n8n, нода Wait выгружает данные выполнения в базу данных только при времени ожидания от 65 секунд. Более короткие паузы выполняются легковесно без этого дополнительного шага, чего достаточно для большинства сценариев ограничения скорости с паузами от долей секунды до нескольких секунд.

Можно ли использовать Batch Interval и ноду Wait одновременно в одном workflow?

Да, это даже распространённый паттерн. Batching в ноде HTTP Request покрывает постоянное дросселирование во время собственно обработки, а дополнительная нода Wait может добавить в другом месте workflow целенаправленную, более длительную паузу, например между отдельными запросами страниц при пагинации или перед особенно ограниченным последующим шагом.

Что делать, если я не знаю точный лимит скорости API?

Начните консервативно с большего интервала, например от 1000 до 2000 миллисекунд между запросами, и наблюдайте, продолжают ли появляться ошибки 429. Многие API также указывают лимит в заголовках ответа, которые можно проанализировать в ноде HTTP Request и использовать для динамической настройки времени ожидания. Кроме того, включённый Retry On Fail помогает как страховочная сетка, если первоначальная оценка была слишком приблизительной.

Достаточно ли одного Retry On Fail, чтобы избежать ограничений скорости при больших объёмах данных?

Не надёжно. Retry On Fail повторяет отдельные неудачные запросы, но не мешает n8n отправлять много запросов подряд в большом цикле без batching. При высоком объёме более надёжным выбором является комбинация batching или Loop Over Items с нодой Wait, а Retry On Fail остаётся полезным как дополнительная подстраховка.