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

- Tool: n8n
- Difficulty: Advanced
- Time required: 30-40 minutes
- Compatibility: n8n 1.30+, Anthropic Claude node or HTTP Request node
- Last updated: March 2026

## 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.

## Before you start

- 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.

```
// Key Anthropic rate limit headers to look for:
// x-ratelimit-limit-requests: 60        (your RPM limit)
// x-ratelimit-remaining-requests: 0     (none left = RPM exceeded)
// x-ratelimit-reset-requests: 2025-01-01T00:01:00Z (when it resets)
// x-ratelimit-limit-tokens: 100000      (your TPM limit)
// 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.

```
// Code node: Calculate exponential backoff
const prevRetries = $input.first().json.retryCount || 0;
const retryCount = prevRetries + 1;

if (retryCount > 5) {
  throw new Error('Max retries (5) exceeded for Claude API call');
}

// Exponential backoff: 2s, 4s, 8s, 16s, 32s
const waitSeconds = Math.pow(2, retryCount);

return [{
  json: {
    ...($input.first().json),
    retryCount,
    waitSeconds,
    retryAt: new Date(Date.now() + waitSeconds * 1000).toISOString()
  }
}];
```

**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.

```
// SplitInBatches settings:
// Batch Size: 1
//
// Wait node settings (in the loop path):
// Resume: After Time Interval
// Wait Amount: 1
// Wait Unit: Seconds
//
// 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.

```
// Error Trigger workflow — Code node
const errorExecution = $input.first().json;
const errorMsg = errorExecution.execution?.error?.message || '';

const is429 = errorMsg.includes('429') || errorMsg.includes('rate_limit');

if (!is429) {
  return [{ json: { retry: false, reason: 'Not a rate limit error' } }];
}

const workflowData = errorExecution.execution?.data || {};
const retryCount = (workflowData.retryCount || 0) + 1;

if (retryCount > 3) {
  return [{ json: { retry: false, reason: 'Max retries exceeded' } }];
}

return [{
  json: {
    retry: true,
    retryCount,
    originalPayload: workflowData.originalPayload
  }
}];
```

**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.

```
const response = $input.first().json;
const headers = response.$response?.headers || {};

const usage = {
  rpmLimit: headers['x-ratelimit-limit-requests'] || 'unknown',
  rpmRemaining: headers['x-ratelimit-remaining-requests'] || 'unknown',
  tpmLimit: headers['x-ratelimit-limit-tokens'] || 'unknown',
  tpmRemaining: headers['x-ratelimit-remaining-tokens'] || 'unknown',
  shouldSlowDown: false
};

const remaining = parseInt(usage.rpmRemaining);
const limit = parseInt(usage.rpmLimit);
if (!isNaN(remaining) && !isNaN(limit) && remaining < limit * 0.1) {
  usage.shouldSlowDown = true;
}

return [{ 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 code example

File: `claude-rate-limit-handler.js`

```javascript
// ====== Retry Logic Code Node ======
// Place after an IF node that checks for 429 status

const input = $input.first().json;
const retryCount = (input.retryCount || 0) + 1;
const MAX_RETRIES = 5;

if (retryCount > MAX_RETRIES) {
  throw new Error(
    `Claude API rate limit: max retries (${MAX_RETRIES}) exceeded. ` +
    `Last error at ${new Date().toISOString()}`
  );
}

// Exponential backoff with jitter
const baseDelay = Math.pow(2, retryCount); // 2, 4, 8, 16, 32
const jitter = Math.random() * 1000; // 0-1000ms random jitter
const waitMs = (baseDelay * 1000) + jitter;
const waitSeconds = Math.ceil(waitMs / 1000);

return [{
  json: {
    prompt: input.prompt || input.message,
    systemMessage: input.systemMessage,
    retryCount,
    waitSeconds,
    retryAt: new Date(Date.now() + waitMs).toISOString(),
    metadata: {
      originalTimestamp: input.metadata?.originalTimestamp || new Date().toISOString(),
      userId: input.userId || 'system'
    }
  }
}];

// ====== Rate Limit Monitor Code Node ======
// Place after successful Claude call

// const response = $input.first().json;
// const rpm = parseInt(response.$response?.headers?.['x-ratelimit-remaining-requests'] || '999');
// const tpm = parseInt(response.$response?.headers?.['x-ratelimit-remaining-tokens'] || '999999');
//
// const warning = rpm < 5 ? 'CRITICAL: RPM nearly exhausted' :
//                 rpm < 15 ? 'WARNING: RPM running low' : 'OK';
//
// return [{ json: { ...response, rateStatus: warning, rpmRemaining: rpm, tpmRemaining: tpm } }];
```

## Common mistakes

- **Retrying immediately after a 429 error without any delay** — undefined Fix: 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
- **Using fixed delays (e.g., always 5 seconds) instead of exponential backoff** — undefined Fix: Use Math.pow(2, retryCount) to double the wait time on each retry: 2s, 4s, 8s, 16s, 32s
- **Not distinguishing between RPM and TPM rate limits, applying the same fix for both** — undefined Fix: Check the rate limit headers. RPM issues need request spacing; TPM issues need shorter prompts or fewer max_tokens
- **Forgetting to pass the original prompt data through the retry loop, losing the user's message** — undefined Fix: 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

## 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.

---

Source: https://www.rapidevelopers.com/n8n-tutorial/how-to-resolve-429-rate-limit-errors-when-sending-prompts-to-claude-from-n8n
© RapidDev — https://www.rapidevelopers.com/n8n-tutorial/how-to-resolve-429-rate-limit-errors-when-sending-prompts-to-claude-from-n8n