n8nの429を止める：再試行より先にAPIへの送信間隔を決める
429が返るなら、PCを速くするよりAPIへの要求を減らすか間隔を空けます。失敗した後の再試行と、平常時の送信ペースは別です。同じ認証を使う他の処理も含めて上限を見ます。
公式資料確認日：。
一秒・一日・データ量のどの上限かを読む
n8nのエラーに含まれる接続先の応答と、接続先APIの公式制限を突き合わせます。429だけから具体的な回数や解除時刻を決めません。アカウント単位か、認証単位か、他のワークフローと共有するかも必要です。
平常時の間隔と、失敗後の待機を分ける
公式にはRetry On Failの待機、Loop Over ItemsとWait、HTTP RequestのBatchingがあります。Batchingは要求を送るペースの調整で、相手APIが複数の書込みを一要求で受け付ける保証ではありません。
| 観測するもの | 分かること | 次の行動 |
|---|---|---|
| 通常の連続要求で429 | 送信ペースが候補 | Batching等で平常時の間隔を調整 |
| 少数でも429 | 共有枠や別の上限も候補 | 他の実行と接続先の制限を照合 |
| 待って再開できる | 期限内の再試行が候補 | 回数・待機・総期限を置く |
| 外部書込みの結果が不明 | 単純な失敗とは別 | 相手の結果を照合してから再送 |
一秒一要求でも、二本同時なら足す
一秒一要求の契約で二本の処理を同時に一秒間隔で走らせる想定では、同じ枠へ二要求を送る計画です。この算数は性能測定ではありません。各ノードを別々に遅くするだけで、共有枠全体を守れるとは決めません。
一律の長い待機では、成果期限を越える
待機を増やす前に入力件数、許容完了時刻、打切り条件を記録します。期限までに処理できないなら、対象の絞込みや周期を見直します。認証を量産して枠を回避する方法や、書込みの無限再試行は選びません。
復旧の受入は、エラーが消えた後に行う
許可された少数の非機密入力で、要求数と成果を照合します。429がなくなっても欠落や二重処理があれば未完了です。CPU増設やVPS契約で外部APIの枠が増えるとは扱いません。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- n8n：API制限への対応
Retry On Failの待機、Loop Over ItemsとWait、HTTP RequestのBatchingを区別。上限は接続先APIの仕様で決まります。