error fix
n8n Rate Limit Error Fix for 429 and API Quotas
Identify the service limit, slow the workflow with retry settings or Wait nodes, batch large HTTP Request calls, and verify that retries are idempotent.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Identify the service limit, slow the workflow with retry settings or Wait nodes, batch large HTTP Request calls, and verify that retries are idempotent.
Problem Pattern
Rate limit errors happen when a workflow sends too many requests too quickly or pulls too much data per request. Retrying instantly usually makes the problem worse.
Key Facts
- Common signal
- HTTP 429 means the service is receiving too many requests.
- Built-in path
- n8n documents Retry On Fail and Loop Over Items plus Wait for integration rate limits.
- HTTP Request option
- The HTTP Request node includes batching and pagination options for larger calls.
- Side-effect risk
- Retries can duplicate writes if the target API operation is not idempotent.
Recommended Steps
- Read the exact node error and confirm whether it is a 429 or service quota message.
- Check the API provider's documented request limits.
- Enable Retry On Fail with a delay that respects the provider's limit.
- For many input items, use Loop Over Items and Wait or HTTP Request batching.
- For write operations, add idempotency keys or duplicate checks before retrying at scale.
Verification
- The workflow no longer returns 429 errors during a representative batch.
- Request timing respects the API's documented limit.
- Retries do not create duplicate records.
- Large reads paginate or batch predictably.
Warnings
- Do not reduce the wait interval below the API's actual rate limit just to finish faster.
- Retrying failed writes can create duplicate records if the API already accepted a previous attempt.
- Pagination and batching solve different problems and may need to be combined.
Common Mistakes
- Retrying immediately with no delay.
- Processing hundreds of items in parallel against a small API quota.
- Ignoring provider-specific daily or per-minute limits.
- Adding waits after the wrong node.
Examples
Input: 500 contacts
Loop Over Items: batch size 10
HTTP Request: one API call per item
Wait: 1000 ms between batches
Retry On Fail: enabled with provider-safe delayFAQ
Is a 429 an n8n outage?
Usually no. It is normally the external service enforcing its request quota.
Should I use batching or Loop Over Items?
Use HTTP Request batching for HTTP-node-specific flows. Use Loop Over Items and Wait when several nodes need controlled pacing.