Skip to main content
RapidDev - Software Development Agency
n8n-tutorial

How to Resolve 429 Rate Limit Errors When Sending Prompts to Claude from n8n

Claude 429 rate limit errors in n8n occur when your workflow exceeds Anthropic's requests-per-minute or tokens-per-minute limits. Fix this by adding a Wait node with exponential backoff after failed calls, using the SplitInBatches node to throttle concurrent requests, and configuring an Error Trigger workflow for automatic retries. These three layers keep your workflow running smoothly under load.

What you'll learn

  • How to identify which Claude rate limit you are hitting (RPM, TPM, or TPD)
  • How to implement exponential backoff retry logic in n8n
  • How to use SplitInBatches to stay under rate limits proactively
  • How to build an Error Trigger workflow for automatic recovery
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Advanced8 min read30-40 minutesn8n 1.30+, Anthropic Claude node or HTTP Request nodeMarch 2026RapidDev Engineering Team
TL;DR

Claude 429 rate limit errors in n8n occur when your workflow exceeds Anthropic's requests-per-minute or tokens-per-minute limits. Fix this by adding a Wait node with exponential backoff after failed calls, using the SplitInBatches node to throttle concurrent requests, and configuring an Error Trigger workflow for automatic retries. These three layers keep your workflow running smoothly under load.

Understanding Claude Rate Limits in n8n Workflows

Anthropic enforces rate limits on Claude API calls at three levels: requests per minute (RPM), tokens per minute (TPM), and tokens per day (TPD). When your n8n workflow triggers multiple Claude calls in quick succession — from webhooks, scheduled tasks, or SplitInBatches loops — you can exceed these limits and receive HTTP 429 responses. The Claude node in n8n does not automatically retry on 429 errors, so you need to build retry logic manually using Wait nodes, error workflows, and batching strategies.

Prerequisites

  • A running n8n instance (v1.30 or later)
  • An Anthropic API credential configured in n8n
  • Knowledge of your Anthropic API tier and rate limits (check console.anthropic.com)
  • Basic understanding of n8n error handling and workflow settings

Step-by-step guide

1

Identify which rate limit you are hitting

Open your n8n execution history and find a failed execution with the 429 error. Click into the failed Claude node and check the response headers. Anthropic returns headers like x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests, and equivalent headers for tokens. These tell you exactly which limit you hit and when it resets. If the requests remaining is 0, you are hitting RPM. If tokens remaining is 0, you are hitting TPM.

typescript
1// Key Anthropic rate limit headers to look for:
2// x-ratelimit-limit-requests: 60 (your RPM limit)
3// x-ratelimit-remaining-requests: 0 (none left = RPM exceeded)
4// x-ratelimit-reset-requests: 2025-01-01T00:01:00Z (when it resets)
5// x-ratelimit-limit-tokens: 100000 (your TPM limit)
6// x-ratelimit-remaining-tokens: 0 (none left = TPM exceeded)

Expected result: You can determine whether RPM or TPM is the bottleneck for your workflow

2

Add a Wait node with exponential backoff for retries

Create a retry loop in your workflow. After the Claude node, add an IF node that checks if the HTTP status is 429 (use expression {{ $json.error?.status === 429 }} or check the error message). On the true branch, add a Code node that calculates the backoff delay, followed by a Wait node, then loop back to the Claude node. The Code node should track retry count and calculate delay as 2^retryCount seconds.

typescript
1// Code node: Calculate exponential backoff
2const prevRetries = $input.first().json.retryCount || 0;
3const retryCount = prevRetries + 1;
4
5if (retryCount > 5) {
6 throw new Error('Max retries (5) exceeded for Claude API call');
7}
8
9// Exponential backoff: 2s, 4s, 8s, 16s, 32s
10const waitSeconds = Math.pow(2, retryCount);
11
12return [{
13 json: {
14 ...($input.first().json),
15 retryCount,
16 waitSeconds,
17 retryAt: new Date(Date.now() + waitSeconds * 1000).toISOString()
18 }
19}];

Expected result: Failed Claude calls wait progressively longer before retrying, with a maximum of 5 attempts

3

Throttle outgoing requests with SplitInBatches

If your workflow processes multiple items (from a database query, spreadsheet, or batch endpoint), add a SplitInBatches node before the Claude node. Set the Batch Size to 1 and add a Wait node (1-2 seconds) in the loop path. This ensures Claude calls are spaced out evenly. For Claude's typical Tier 1 limit of 60 RPM, a 1-second delay between calls keeps you safely under the limit.

typescript
1// SplitInBatches settings:
2// Batch Size: 1
3//
4// Wait node settings (in the loop path):
5// Resume: After Time Interval
6// Wait Amount: 1
7// Wait Unit: Seconds
8//
9// Flow: SplitInBatches → Claude → Wait → SplitInBatches (loop input)

Expected result: Claude calls are spaced at least 1 second apart, preventing RPM limit violations

4

Build an Error Trigger workflow for unhandled 429 errors

Create a new workflow with an Error Trigger node as the start. This workflow fires whenever the main workflow fails. Add a Code node that checks if the error is a 429. If yes, extract the original input data from the execution context, wait 60 seconds using a Wait node, then use an HTTP Request node to re-trigger the main workflow's webhook with the original payload plus an incremented retryCount.

typescript
1// Error Trigger workflow — Code node
2const errorExecution = $input.first().json;
3const errorMsg = errorExecution.execution?.error?.message || '';
4
5const is429 = errorMsg.includes('429') || errorMsg.includes('rate_limit');
6
7if (!is429) {
8 return [{ json: { retry: false, reason: 'Not a rate limit error' } }];
9}
10
11const workflowData = errorExecution.execution?.data || {};
12const retryCount = (workflowData.retryCount || 0) + 1;
13
14if (retryCount > 3) {
15 return [{ json: { retry: false, reason: 'Max retries exceeded' } }];
16}
17
18return [{
19 json: {
20 retry: true,
21 retryCount,
22 originalPayload: workflowData.originalPayload
23 }
24}];

Expected result: Rate-limited executions automatically retry after a cooldown period without manual intervention

5

Configure the main workflow to use the error workflow

Open your main Claude workflow, click Settings (gear icon), and set the Error Workflow to the retry workflow you created in the previous step. This links the two workflows so any unhandled error in the main workflow triggers the retry logic. Also enable 'Retry On Fail' in the Claude node settings with 2 retries and a 5-second wait as a first-pass safety net before the error workflow handles persistent failures.

Expected result: The Claude node retries twice on its own, then the error workflow handles persistent 429 errors with longer delays

6

Add monitoring with a Code node to log rate limit usage

After a successful Claude call, add a Code node that extracts the rate limit headers from the response and logs them. This gives you visibility into how close you are to limits. If remaining requests drops below 10% of your limit, the Code node can set a flag to increase delays dynamically.

typescript
1const response = $input.first().json;
2const headers = response.$response?.headers || {};
3
4const usage = {
5 rpmLimit: headers['x-ratelimit-limit-requests'] || 'unknown',
6 rpmRemaining: headers['x-ratelimit-remaining-requests'] || 'unknown',
7 tpmLimit: headers['x-ratelimit-limit-tokens'] || 'unknown',
8 tpmRemaining: headers['x-ratelimit-remaining-tokens'] || 'unknown',
9 shouldSlowDown: false
10};
11
12const remaining = parseInt(usage.rpmRemaining);
13const limit = parseInt(usage.rpmLimit);
14if (!isNaN(remaining) && !isNaN(limit) && remaining < limit * 0.1) {
15 usage.shouldSlowDown = true;
16}
17
18return [{ json: { ...response, rateLimitUsage: usage } }];

Expected result: Each execution includes rate limit usage data, and the workflow can dynamically adjust pacing when limits are nearly exhausted

Complete working example

claude-rate-limit-handler.js
1// ====== Retry Logic Code Node ======
2// Place after an IF node that checks for 429 status
3
4const input = $input.first().json;
5const retryCount = (input.retryCount || 0) + 1;
6const MAX_RETRIES = 5;
7
8if (retryCount > MAX_RETRIES) {
9 throw new Error(
10 `Claude API rate limit: max retries (${MAX_RETRIES}) exceeded. ` +
11 `Last error at ${new Date().toISOString()}`
12 );
13}
14
15// Exponential backoff with jitter
16const baseDelay = Math.pow(2, retryCount); // 2, 4, 8, 16, 32
17const jitter = Math.random() * 1000; // 0-1000ms random jitter
18const waitMs = (baseDelay * 1000) + jitter;
19const waitSeconds = Math.ceil(waitMs / 1000);
20
21return [{
22 json: {
23 prompt: input.prompt || input.message,
24 systemMessage: input.systemMessage,
25 retryCount,
26 waitSeconds,
27 retryAt: new Date(Date.now() + waitMs).toISOString(),
28 metadata: {
29 originalTimestamp: input.metadata?.originalTimestamp || new Date().toISOString(),
30 userId: input.userId || 'system'
31 }
32 }
33}];
34
35// ====== Rate Limit Monitor Code Node ======
36// Place after successful Claude call
37
38// const response = $input.first().json;
39// const rpm = parseInt(response.$response?.headers?.['x-ratelimit-remaining-requests'] || '999');
40// const tpm = parseInt(response.$response?.headers?.['x-ratelimit-remaining-tokens'] || '999999');
41//
42// const warning = rpm < 5 ? 'CRITICAL: RPM nearly exhausted' :
43// rpm < 15 ? 'WARNING: RPM running low' : 'OK';
44//
45// return [{ json: { ...response, rateStatus: warning, rpmRemaining: rpm, tpmRemaining: tpm } }];

Common mistakes when resolving 429 Rate Limit Errors When Sending Prompts to Claude from

Why it's a problem: Retrying immediately after a 429 error without any delay

How to avoid: Always add a Wait node with at least the duration specified in the x-ratelimit-reset header, or use exponential backoff starting at 2 seconds

Why it's a problem: Using fixed delays (e.g., always 5 seconds) instead of exponential backoff

How to avoid: Use Math.pow(2, retryCount) to double the wait time on each retry: 2s, 4s, 8s, 16s, 32s

Why it's a problem: Not distinguishing between RPM and TPM rate limits, applying the same fix for both

How to avoid: Check the rate limit headers. RPM issues need request spacing; TPM issues need shorter prompts or fewer max_tokens

Why it's a problem: Forgetting to pass the original prompt data through the retry loop, losing the user's message

How to avoid: Include the original prompt, system message, and user metadata in every retry payload

Best practices

  • Always add jitter to exponential backoff to prevent thundering herd when multiple workflows retry simultaneously
  • Check Anthropic's rate limit headers after every successful call to monitor remaining capacity
  • Use SplitInBatches with a batch size of 1 and a Wait node in the loop for predictable request pacing
  • Set N8N_CONCURRENCY_PRODUCTION_LIMIT to prevent too many concurrent workflow executions
  • Consider using Claude Haiku for high-volume, low-complexity tasks since it has higher rate limits
  • Store the original prompt in the retry payload so you can replay it exactly after rate limit recovery
  • Set a maximum retry count (3-5) to prevent infinite retry loops that waste execution time
  • Monitor your Anthropic console usage dashboard alongside n8n logs for a complete picture

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

My n8n workflow calling Anthropic Claude keeps getting 429 rate limit errors. How do I add exponential backoff retry logic and request throttling using SplitInBatches and Wait nodes?

n8n Prompt

After the Claude node, add an IF node checking for 429 errors. On the true path, add a Code node to calculate exponential backoff (Math.pow(2, retryCount) seconds), then a Wait node using that delay, then loop back to the Claude node. Add SplitInBatches before Claude with batch size 1 and a 1-second Wait in the loop.

Frequently asked questions

What are Anthropic Claude's default rate limits?

Rate limits vary by tier. Tier 1 (new accounts) typically allows 60 RPM and 100,000 TPM. Tier 4 allows 4,000 RPM and 400,000 TPM. Check your current tier at console.anthropic.com under Settings > Limits.

Should I use the n8n Claude node or an HTTP Request node for better error handling?

The HTTP Request node gives you more control because you can access response headers (including rate limit headers) directly. The Claude node is easier to set up but abstracts away header information. For production workflows with rate limit concerns, the HTTP Request node is recommended.

How do I know if I am hitting RPM or TPM limits?

Check the x-ratelimit-remaining-requests header (RPM) and x-ratelimit-remaining-tokens header (TPM) from your Claude API responses. Whichever shows 0 remaining is the one you are hitting. RPM issues are solved with request spacing; TPM issues require shorter prompts or lower max_tokens.

Can I increase my Anthropic rate limits?

Yes. Anthropic automatically increases your tier as you spend more on the API. You can also request a manual tier increase through the Anthropic console by contacting their sales team for enterprise use cases.

Does the Wait node consume n8n execution time or credits?

The Wait node pauses the execution without consuming CPU. However, the execution remains open and counts toward your concurrent execution limit. On n8n Cloud, long waits may count toward execution time quotas depending on your plan.

Can RapidDev help optimize my n8n workflow for high-volume Claude API usage?

Yes. RapidDev builds production-grade n8n workflows with intelligent rate limiting, request queuing, and monitoring dashboards tailored to your specific API tier and throughput requirements.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.