Перевищено ліміт запитів API в n8n: як виправити 429 без дублювання записів
Виправте помилки ліміту запитів API в n8n: прочитайте 429, групуйте запити, повторюйте після вікна ліміту й додайте ключі ідемпотентності проти дублів.
Перевірено за наведеними джерелами .
Що потрібно і яка мета
Помилка «API rate limit exceeded» означає, що сервіс, до якого ви звертаєтеся, просить надсилати менше запитів. В n8n вона може з’явитися як відповідь HTTP 429 від вузла HTTP Request. У цьому посібнику ви створите workflow, який обробляє такі 429 і не надсилає той самий запис двічі під час повторних спроб.
Перш ніж почати, підготуйте:
Sources: Handle rate limits | Nodes | n8n Docs, 429 Too Many Requests - HTTP | MDN
Крок за кроком: обробка помилок перевищення ліміту запитів API
Виконуйте кроки по черзі. Після кожного знову запускайте workflow і перевіряйте результат, перш ніж додавати наступну зміну. Так ви знатимете, яка саме зміна допомогла.
Виправляйте 429 крок за кроком
- Відтворіть: Викличте 429 і прочитайте помилку в панелі виводу вузла.
- Перевірте: Поверніть код статусу й заголовки та пошукайте Retry-After.
- Групуйте: Налаштуйте Items per Batch і Batch Interval під ліміти API.
- Повторюйте: Увімкніть Retry On Fail з паузою, довшою за вікно ліміту.
- Захистіть записи: Додайте ключ ідемпотентності до POST-запитів, якщо API його підтримує.
Спершу відтворіть помилку перевищення ліміту запитів API. Згідно з документацією n8n, коли сервіс повертає помилку 429, вузол завершується з повідомленням, що сервіс отримує забагато запитів. Це повідомлення можна прочитати в панелі виводу вузла.
Далі увімкніть у вузлі HTTP Request опцію відповіді Include Response Headers and Status. За документацією n8n, вона повертає код статусу й заголовки разом із тілом. MDN зазначає, що відповідь 429 може містити заголовок Retry-After, який підказує клієнту, скільки чекати. Проте цей заголовок необов’язковий, і кожен сервер встановлює власні правила. Документація n8n не пояснює, як автоматично реагувати на Retry-After, тож поки що сприймайте його як інформацію, яку ви читаєте самі.
Потім рознесіть запити в часі. В опції Batching вузла HTTP Request параметр Items per Batch задає, скільки елементів надсилається разом, а Batch Interval — паузу між пакетами в мілісекундах. Оберіть значення, що вкладаються в задокументовані ліміти API.
Після цього відкрийте Settings вузла й увімкніть Retry On Fail. Документація n8n радить встановити Wait Between Tries довшим за вікно ліміту запитів. У цій документації не описано ні максимальної кількості спроб, ні експоненційних пауз.
Sources: Handle rate limits | Nodes | n8n Docs, HTTP Request | Nodes | n8n Docs, 429 Too Many Requests - HTTP | MDN
Захистіть повторні записи ключами ідемпотентності
Насамкінець захистіть операції запису. В API Stripe усі POST-запити приймають ключі ідемпотентності. Повторний запит із тим самим ключем повертає збережений перший результат замість повторного виконання операції. Така поведінка властива саме Stripe. Наша редакційна порада: надсилайте ключ у спосіб, описаний у документації вашого API, і лише тоді, коли там задокументовано підтримку ключів ідемпотентності. Формуйте його зі стабільного бізнес-ідентифікатора, наприклад номера замовлення, а не з випадкового значення, що змінюється з кожною спробою.
Sources: Idempotent requests | Stripe API Reference
Очікувані результати та усунення проблем
Коли пакетування й повторні спроби налаштовано, помилок 429 має стати менше. Якщо помилка перевищення ліміту запитів API все ж з’являється, повтори з паузою, довшою за вікно ліміту, дають пізнішій спробі шанс на успіх, але 429 усе ще може зупинити вузол, якщо ліміт не знімається. Якщо щось досі не працює, знайдіть свій симптом нижче.
| Симптом | Ймовірна причина | Що перевірити |
|---|---|---|
| 429 не зникають | Пакети завеликі або йдуть надто часто | Зменште Items per Batch або збільште Batch Interval |
| 429 не зникають після повторів | Wait Between Tries коротший за вікно ліміту | Встановіть паузу, довшу за вікно ліміту запитів |
| Дублікати записів | Повторні POST-запити не мають ключа ідемпотентності | Перевірте, чи підтримує API ключі ідемпотентності |
| Дублікати навіть із ключем | Ключ змінюється з кожною спробою | Формуйте ключ зі стабільного бізнес-ідентифікатора |
Якщо повторні спроби спрацьовують в один і той самий момент, зверніться до давнішої загальної поради. У дописі 2017 року в інженерному блозі Stripe рекомендував експоненційну затримку (exponential backoff), коли пауза подвоюється після кожної невдачі, а також випадковий jitter, щоб багато клієнтів не повторювали запити одночасно. Тому допису вже кілька років, і нічого з цього не є вбудованою функцією n8n. Будь-яка реалізація цього в n8n — це патерн, який ви проєктуєте самі.
Sources: Handle rate limits | Nodes | n8n Docs, HTTP Request | Nodes | n8n Docs, Idempotent requests | Stripe API Reference, Designing robust and predictable APIs with idempotency
