Handle API Rate Limits with n8n

Build an n8n workflow that batches, retries, and logs rate-limited API calls.

Introduction

30 Second Summary

A task that works once can still collapse when it has to repeat the same job fifty times. One slow-down response can leave the rest of the work unfinished.

In this project, you will build an n8n workflow that sends fifty items to a public API to deliberately trigger a rate limit. You will make the run resilient so each item completes or lands in a failure log.

What You'll Build

You watch a fifty-item workflow recover from rate limits with a green execution plus a failure file that accounts for anything the API still rejects.

By the end of this project, you'll have:

A fifty-item API run that makes a 429 response visible in the execution log.
A paced batch process that turns the same bulk run green again.
A retry and failure-capture path that prevents rejected items from silently disappearing.
Secret Mission: An optional challenge to push your skills further.

Are there any prerequisites?

You need Node installed for a local run or an email address for the hosted trial. You also need access to a public API that publishes a request limit.

Before We Start

A rate-limit test needs somewhere to run before it can send a request to an API. n8n gives you a visual place to build that test.

This step gets n8n running in your browser. You will finish inside a blank workflow editor that is ready for the first API call.

In this step, get ready to:

Choose between a local n8n instance or an n8n Cloud workspace.
Start your n8n instance.
Reach the blank workflow canvas.

Choose how to run n8n

A local instance keeps the project on your computer. The Cloud route removes the local installation work.

Why choose local or Cloud?

Local n8n is free to run through the Community edition. You remain responsible for keeping its terminal process running.

n8n Cloud manages the instance for you. Its free trial gives you a temporary workspace without local setup.

Choose the setup route that fits your computer:

Run n8n locally

Local n8n uses Node.js to launch the editor. n8n supports Node.js versions from 20.19 through 24.x.

Press Cmd+Space on macOS or the Windows key on Windows to open your system search.
Type Terminal on macOS or PowerShell on Windows.
Press Enter to open the terminal.
Check your Node.js version by running this command:

node --version

What does this check show?

The command prints the Node.js version available to your terminal. Match that result to one of the routes below.

✔️ I see a supported version

Your version falls between 20.19 and 24.x. Your Node.js runtime is ready for n8n.

ⓧ I see an older version

Your terminal found Node.js. Its version sits outside the range supported by n8n.

Visit the official Node.js download page.
Download the installer for a supported 24.x release.
Run the downloaded installer with its default options.
Quit your terminal after the installation finishes.
Use the same system search steps to reopen your terminal.
Confirm the updated version by running this command:

node --version

What confirms the update?

The command should now print a version in the supported range. A 24.x result is ready for n8n.

ⓧ Command not found

Your terminal cannot find Node.js yet. Installing a supported release adds the runtime that n8n needs.

Visit the official Node.js download page.
Download the installer for a supported 24.x release.
Run the downloaded installer with its default options.
Quit your terminal after the installation finishes.
Use the same system search steps to reopen your terminal.
Confirm Node.js is available by running this command:

node --version

What confirms the installation?

A printed version number confirms that your terminal can now use Node.js. A 24.x result is supported by n8n.

Node.js check still failing?

Restart your computer if the installer finished but the terminal still cannot find Node.js.
Download the installer that matches your operating system from the official Node.js page.
Ask for help with the version shown in your terminal: Help me get a supported Node.js version working for a local n8n installation.

The first n8n launch may take a little while because npx downloads the required package. Keep the terminal open after the editor starts.

Start n8n by running this command:
Approve the package download if your terminal asks for permission.

npx n8n

What does this command do?

The command downloads everything needed to start n8n. It then keeps the local editor service running in this terminal.

Press Cmd+Space on macOS or the Windows key on Windows to open your system search.
Type the name of your usual web browser.
Press Enter to open the browser.
Enter http://localhost:5678 in the browser address bar.

The owner form protects access to your local n8n instance. Your password should be unique to this account.

Complete the owner account form if n8n displays it.
Submit the form to continue to your local workspace.

Local n8n did not open?

Check that the terminal running n8n remains open.
Confirm your browser address uses http://localhost:5678.
Check your internet connection if the initial package download stops.
Ask for help with the output visible in your terminal: Help me diagnose why my local n8n editor is not opening.

Use n8n Cloud

This route creates a hosted account for your workflows. The free trial expires automatically without a charge unless you manually subscribe to a paid plan.

Creating an account involves a password. Use a unique password that you do not reuse elsewhere.

Open the official n8n Cloud free trial guide.
Select Start free trial.
Create your account with an email address you can access.
Create a unique password for your account.
Complete the workspace setup prompts.

Your hosted n8n workspace is ready when the browser reaches its welcome screen or Overview page.

Cloud workspace not loading?

Check the inbox for the email address used during registration.
Complete any account confirmation requested by n8n.
Reload the workspace after confirming your account.
Ask for help with the screen you can see: Help me finish opening my n8n Cloud workspace.

Open a blank workflow

The workflow canvas is the main editor where you add nodes. Reaching an empty canvas proves that your n8n instance can create workflows.

Before you check, what controls do you expect an empty workflow canvas to offer?

Select Start from Scratch if you see the welcome screen.
Select Create in the upper-right corner if you see the Overview page.
Select Workflow from the creation menu.

You should now see a blank canvas with Add first step... in the editor. You should also see the Execute Workflow control.

Cannot reach the blank canvas?

Return to the Overview page if a different n8n screen is open.
Select Create in the upper-right corner.
Select Workflow from the menu.
Ask for guidance based on your current screen: Help me navigate from my current n8n screen to a blank workflow canvas.

✔️ The workflow editor is open

Your n8n instance is running in a browser with the workflow editor open. That is the complete setup needed for the next step.

ⓧ I'd like to double check the setup

Confirm the terminal running n8n remains open if you chose the local route.
Confirm your n8n Cloud workspace remains signed in if you chose the hosted route.
Confirm the browser shows the blank workflow canvas with Add first step....

Your n8n editor is ready to build workflows. Next up, you will make the first public API call and watch it complete successfully.

Verify a Single API Call

A rate-resilient workflow still depends on one valid API response. This step establishes a known-good connection before later runs add pressure.

Your n8n editor is ready. In this step, you'll build the two-node baseline that proves one request can finish successfully.

In this step, get ready to:

Build a named workflow that starts from Manual Trigger.
Configure HTTP Request with one public endpoint.
Execute the workflow to confirm one successful response.

Create the workflow starting point

Every n8n workflow starts from a trigger. The Manual Trigger gives you control over exactly when this first test runs.

Select the current workflow name at the top of the canvas.
Enter Rate Limit Resilient API Workflow.

You'll see Rate Limit Resilient API Workflow at the top of the editor.

Select Add first step... on the canvas.
Search for Manual Trigger in the node picker.

You'll see the Manual Trigger result in the filtered list.

Select Manual Trigger from the results.

Your canvas now has a single starting node. The workflow runs only when you manually execute it.

Configure one HTTP request

An HTTP request sends a message to an API endpoint. The HTTP Request node turns the response into workflow data.

Choose a credential-free GET endpoint that returns one item from a public API with a published request limit.
Record the endpoint here: your public API endpoint.

Your endpoint is ready for the first controlled request.

Select the output connector on the right side of Manual Trigger.
Search for HTTP Request in the node picker.

You'll see the HTTP Request result in the filtered list.

Select HTTP Request from the results.

You'll see HTTP Request attached to Manual Trigger by one connection.

Set Method to GET.
Paste your public API endpoint into the URL field.

The two-node workflow is now configured for one request. Its first run gives you the baseline for every resilience change that follows.

Run the baseline call

Before you run the workflow, do you expect both nodes to complete from a single manual start?

Select Execute Workflow.

You'll see both nodes turn green. This shows that the workflow completed successfully.

Select the HTTP Request node on the canvas.

You'll see one response item in the output. The returned data confirms that your endpoint works from n8n.

That's your clean baseline. One manual run now reaches the API successfully.

Did the HTTP Request Turn Red?

Check that the URL field contains the complete endpoint from the API documentation.
Confirm that the selected endpoint supports GET without credentials.
Use the response details shown by the node to identify the failed request. Help me debug my failed n8n HTTP Request.

✔️ My execution is green

Great. Your workflow has a working single-call baseline that you can compare with every later run.

ⓧ I'd like to double check the workflow

Compare your canvas with this finished state:

The workflow name is Rate Limit Resilient API Workflow.
Manual Trigger is connected to HTTP Request.
The Method field is set to GET.
The URL field contains your public API endpoint.
The latest manual execution is green.
The HTTP Request output contains one successful response item.

Your single call is reliable. Next, you'll feed the same request a larger list to reveal what happens under pressure.

Trigger and Inspect a Rate Limit

Your first green HTTP request proved that n8n can reach the selected API endpoint. A single successful call leaves the workflow's behavior under pressure unknown.

A rate limit caps request frequency. In this step, you'll turn one trigger into 50 rapid calls so you can capture the service's response when the limit is reached.

In this step, get ready to:

Insert a Code node that creates 50 input items.
Send all 50 items rapidly through the HTTP Request node.
Inspect the failed execution for an HTTP 429 response.

Create the fifty-item input

n8n passes data between nodes as separate items. A downstream node processes every incoming item, so 50 outputs from one node become 50 calls in the next node.

Click the connection between Manual Trigger and HTTP Request on the workflow canvas.
Click the plus button on the selected connection.
Type Code in the node search field.
Select the Code node.
Keep Mode set to Run Once for All Items.
Replace the sample code with this 50-item generator:

// Create 50 separate items for one rapid downstream burst
return Array.from({ length: 50 }, (_, index) => ({
  json: {
    requestNumber: index + 1,
  },
}))

What does this code do?

The Array.from() call creates exactly 50 entries.
The index + 1 expression numbers the entries from 1 through 50.
The json wrapper gives each entry the item structure that n8n expects.
The returned array sends 50 separate items to the next node.

Test the item generator by clicking Execute step inside the Code node.

You should see 50 output items. Each item contains a different requestNumber value.

Good work. Your workflow now produces the full 50-item test load from one manual trigger.

Return to the workflow canvas by closing the node panel.

You should see Manual Trigger, Code, and HTTP Request connected in that order.

Seeing fewer than 50 items?

Confirm that Mode is set to Run Once for All Items.
Check that the array length in the first line is 50.
Compare every bracket in the node with the reference code below.
Help me fix my Code node so it returns exactly 50 n8n items.

✔️ Awesome, I've got everything!

Your Code node returns 50 items between Manual Trigger and HTTP Request.

ⓧ I'd like to double check the full code

Compare the complete contents of your Code node with this reference.

// Create 50 separate items for one rapid downstream burst
return Array.from({ length: 50 }, (_, index) => ({
  json: {
    requestNumber: index + 1,
  },
}))

Confirm that Manual Trigger connects to Code.
Confirm that Code connects to HTTP Request.

Run the fifty-request burst

The HTTP Request node now receives 50 items. It performs the configured request for every item without a pause between calls.

Before you run it, do you think the 50 calls will finish like the single-call test?

Start the burst by clicking Execute Workflow.

You'll see the execution stop at the HTTP Request node. The node turns red because the service rejects part of the burst.

This Failure Is the Lesson

One request stayed within the service's request limit. Fifty rapid requests expose the limit that a real bulk workflow must handle.

The workflow currently sends every item without pacing. The red execution gives you a controlled example to diagnose.

Did all fifty requests succeed?

Run the same 50-item workflow again immediately so the calls land in the same rate-limit window.
Confirm that the selected endpoint publishes a burst limit below 50 requests.
Return to the endpoint choice from the previous step if repeated bursts remain green.
Help me choose a public API endpoint that can demonstrate a 429 response with this 50-item n8n workflow.

Inspect the 429 response

The execution view packs several panels together, so the useful detail can be easy to miss. The failed node's output panel contains the service response that explains the red status.

Before you inspect the node, what evidence would show that the service rejected the request frequency?

Open the workflow's Executions list.
Select the latest failed execution.
Select the HTTP Request node in the execution view.
Read the error details in the node output panel.

You should see 429 Too Many Requests in the error details. n8n may also display The service is receiving too many requests from you.

What Does 429 Mean?

An HTTP 429 response means the service received too many requests from your client. Your earlier green execution proves the endpoint works for a single call.

The failed burst isolates request frequency as the problem. That distinction keeps you focused on controlling the request flow.

You've reproduced the failure that breaks many bulk automations. Next, you'll pace the same 50 items in batches so the workflow can finish cleanly.

Batch and Pace API Requests

You have proved that the workflow reaches the selected public API. The failed n8n run exposed the service's rate limit through an HTTP 429 Too Many Requests response.

Batching controls how many items enter the request path at once. Pacing adds a timed gap before the next batch starts.

In this step, get ready to:

Insert Loop Over Items between the 50-item source and HTTP Request.
Add a Wait node to pace each batch.
Verify a green execution that processes all 50 items.

Insert the batching loop

Loop Over Items stores the incoming items. It releases a controlled batch during each loop iteration.

Switch back to the workflow canvas from the failed execution.
Select the connection that sends the 50 input items directly to HTTP Request.
Use the connection's delete control to remove it from the canvas.

You should now see the 50-item source and HTTP Request as separate nodes with no connection between them.

Use the add-node control on the canvas to open the node picker.
Search for Loop Over Items.
Select Loop Over Items from the search results.

You should see Loop Over Items appear as a new node on the canvas.

Connect the node that creates 50 input items to the input of Loop Over Items.
Set Batch Size to 1.

The batching node now releases one item during each loop iteration.

Connect the loop output of Loop Over Items to HTTP Request.

Your workflow should now send the 50-item list into Loop Over Items before any API request runs.

What happens inside the loop?

A Batch Size of 1 sends one input item through each iteration.
The loop output carries the current batch toward HTTP Request.
The done output becomes available after every incoming item has been processed.

Cannot connect the batching loop?

Confirm that the original direct connection to HTTP Request has been removed.
Use the output labeled loop when connecting Loop Over Items to HTTP Request.
Make sure the 50-item source connects to the input side of Loop Over Items.
Help me wire Loop Over Items into my n8n workflow.

Add a pause between batches

The Wait node creates a gap after each API call. Reconnecting it to Loop Over Items repeats that gap before the next batch begins.

Check the selected API's published rate-limit documentation to find its allowed request count and time window.
Divide the time window in seconds by the allowed request count.
Round the result up to a whole second that is strictly greater than the calculation.
Record the rounded result here: your pacing interval in seconds.

Use the output connector on HTTP Request to add a Wait node.
Choose After Time Interval as the resume condition.

You should now see Wait connected directly after HTTP Request.

Enter your pacing interval in seconds in Wait Amount.
Select Seconds for Wait Unit.

The Wait node now holds each completed request for the interval calculated from your API's published limit.

Connect the output of Wait back to the input of Loop Over Items.

Your main path should run from the 50-item source to Loop Over Items, then to HTTP Request, then to Wait. A return connection should run from Wait back to Loop Over Items.

How does pacing protect the API?

Loop Over Items releases one item to HTTP Request. Wait pauses the workflow after that request completes.

The return connection asks for the next item only after the pause. This keeps the workflow's request frequency below the published limit.

Run the paced workflow

This run takes roughly 50 times your pacing interval because each item waits for its turn. With a one-second interval, expect about a minute.

Before you run it, do you expect the 50 requests to finish in one burst or spread across repeated node runs?

Click Execute workflow to process the 50 items through the loop.

You should see Loop Over Items, HTTP Request, and Wait activate repeatedly while n8n works through the batches. The execution finishes green instead of stopping on a 429 response.

Select Loop Over Items after the execution finishes.
Open the done output in the node data.

You should see 50 processed items in the completed output.

That is the turnaround: your failed burst is now a paced run that processes all 50 items.

Still receiving a 429 response?

Confirm that HTTP Request connects to Wait before the workflow returns to Loop Over Items.
Increase your pacing interval to the next whole second above the current value.
Run the workflow again to confirm the execution finishes green.
Help me tune my n8n pacing interval.

Your workflow now handles bulk requests without overwhelming the API. Next, you'll add retries for requests that still fail occasionally.

Retry Failed Requests

The last run proved your n8n workflow can pace all 50 requests. That protects the API during normal bulk processing.

A brief rate-limit response can still happen when traffic changes. Retry On Fail gives the HTTP Request node another attempt after a pause.

You'll force another limit in this step. This makes the retry attempts visible in the execution log.

In this step, get ready to:

Configure delayed retries for the HTTP Request node.
Recreate burst pressure with the Wait node temporarily deactivated.
Inspect the forced execution for retry attempts.

Configure retries on HTTP Request

Retries cover temporary failures that slip through pacing. The retry delay gives the service time to accept another request.

Select the Wait node on the workflow canvas.
Record its current delay here: your current Wait delay in milliseconds.

This value is the pacing interval that already produced a green execution.

Select the HTTP Request node on the workflow canvas.
Select the Settings tab in the node panel.

The Settings tab controls how the node behaves when a request fails.

Enable Retry On Fail.

You'll see fields for the maximum number of attempts and the pause between them.

Enter 3 in Max Tries.
Enter your current Wait delay in milliseconds in Wait Between Tries (ms).

Good progress. The HTTP Request node now has a bounded recovery window for temporary failures.

How do retries fit with pacing?

The Wait node reduces the chance of reaching the request limit during normal processing.
Retry On Fail reacts when an individual request still fails.
Max Tries prevents the node from retrying forever.
Wait Between Tries gives the service time to recover before the next attempt.

Force a rate-limit retry

A retry only leaves evidence after an attempt fails. Temporarily deactivating Wait recreates burst pressure while preserving its configuration.

Return to the workflow canvas.
Hover over the Wait node.
Select Deactivate from the node controls.

The Wait node now appears deactivated. Your 50 items can reach the HTTP Request node without the normal pause.

Before you run this, do you expect the first HTTP Request attempt to pass or hit the same limit as the earlier burst?

Start the forced test by selecting Execute workflow.

You'll see an HTTP 429 response on an early attempt. The HTTP Request node waits before trying again.

The execution finishes green if a later attempt succeeds. It finishes red if all three tries encounter the limit.

No retry attempts in the log?

Confirm the Wait node appears deactivated during the forced run.
Confirm Retry On Fail remains enabled on the HTTP Request node.
Run the same 50-item workflow again if the selected API accepted the first burst.
Ask for help with your specific execution: Help me find why my n8n HTTP Request node did not record retry attempts during a forced rate-limit test.

Restore pacing and inspect retry history

The forced run has done its job. Restore the normal pacing before leaving the workflow in its resilient state.

Return to the workflow canvas.
Hover over the Wait node.
Select Activate from the node controls.

The Wait node is active again. Its original delay remains configured.

Confirm the batching node still feeds the Wait node.
Confirm the Wait node still feeds the HTTP Request node.

Before you inspect the forced run, how many attempts do you expect for a request that failed once before succeeding?

Open Executions from the workflow navigation.
Select the execution created during the forced rate-limit test.
Select the HTTP Request node in the execution view.
Review its execution log for the listed retry attempts.

You'll see the failed request attempt followed by later retry attempts from the HTTP Request node. The configured pause appears between those attempts.

That's your fallback working. The workflow can now recover when pacing alone does not prevent a temporary limit.

Your workflow now combines prevention with recovery. Next, you'll capture any items that still fail after every retry so none disappear silently.

Log Undelivered Items

Your HTTP Request node now retries rate-limited requests. A request can still remain undelivered after every configured attempt.

This step adds an error-handling branch in n8n. The branch saves undelivered item data in a JSON file named failed-items.json.

In this step, get ready to:

Route requests that remain undelivered after retries into an error output.
Create a file-writing branch for failed item data.
Verify failed-item logging with a forced rate-limit run.

Route exhausted retries

The Retry On Fail setting controls the attempts that happen first. The On Error setting decides where an item goes when those attempts run out.

Return to the HTTP Request node on the workflow canvas.
Select the Settings tab.
Keep Retry On Fail enabled.
Leave the configured retry count unchanged.
Leave the configured retry delay unchanged.
Set On Error to Continue (using error output).
Return to the workflow canvas.

You should see a second output connector on HTTP Request. That connector carries items that still fail after the retries finish.

How Do the Two Outputs Work?

The normal output carries successful responses into the existing workflow path.
The error output carries undelivered item data into a separate handling path.
The separate path keeps one failed request from silently disappearing.

Write failed items to JSON

The error output only holds data during an execution. A file gives those failed items a record you can inspect after the run finishes.

Select the error output connector on HTTP Request.
Add Convert to File from the nodes panel.

The error output now has a destination. Failed items can move into the new branch instead of ending at an unused connector.

Select Convert to JSON as the operation.
Set Mode to All Items to One File.

This mode groups the failed items arriving together into one file. The result stays easier to inspect than a separate file for every item.

Add File Name from Options.
Enter failed-items.json in File Name.
Return to the workflow canvas.

The conversion node creates the file data in memory. The next node writes that data to a location you can open.

Select the output connector on Convert to File.
Add Read/Write Files from Disk from the nodes panel.

The disk node needs a full destination that the running n8n process can access. Choose a location you can find again after the verification run.

Choose an absolute destination that ends in failed-items.json.
Record the full destination here: absolute path ending in failed-items.json.

Select Write File to Disk as the operation.
Set Input Binary Field to data.

The data field carries the binary file created by Convert to File.

Enter absolute path ending in failed-items.json in File Path and Name.
Connect the output of Read/Write Files from Disk to the same loop-back node used by the successful request path.

Your canvas should now show an error branch from HTTP Request through Convert to File and Read/Write Files from Disk.

How Does the File Branch Work?

The error output passes the original failed item data into the branch.
Convert to File packages that data into failed-items.json.
Read/Write Files from Disk stores the file at your chosen destination.
The loop-back connection allows the remaining input items to continue processing.

Having Trouble Writing the File?

Confirm that File Path and Name contains an absolute path ending in failed-items.json.
Choose a destination that the running n8n process can access.
Confirm that Input Binary Field contains data.
Ask for help with my n8n file-writing branch.

✔️ My error branch is wired

Your workflow now has a complete path for requests that remain undelivered after retries.

ⓧ I'd like to double check the workflow

Compare the new branch with these checkpoints before running it.

Confirm that Retry On Fail remains enabled on HTTP Request.
Confirm that On Error uses Continue (using error output).
Confirm that the error connector leads to Convert to File.
Confirm that Convert to File uses Convert to JSON with All Items to One File.
Confirm that File Name contains failed-items.json.
Confirm that Read/Write Files from Disk uses Write File to Disk.
Confirm that Input Binary Field contains data.
Confirm that the file-writing node reconnects to the existing loop-back path.

Run the failure-logging check

This verification includes the existing batch waits plus every configured retry. A slower run here means the workflow is giving each request its planned recovery attempts.

Reapply the temporary rate-limit condition from the previous step so at least one request remains unsuccessful after all retries.

Before you run it, make a quick prediction about which path the failed request takes.

Click Execute workflow in the Manual Trigger node.

You should see retry attempts on the HTTP Request node. The error branch should run after the final unsuccessful attempt.

The Read/Write Files from Disk node should finish successfully. The execution can now complete because the failed item has a handled destination.

Restore the paced API settings from the earlier green execution.
Use Finder on macOS or File Explorer on Windows to open the folder portion of absolute path ending in failed-items.json.
Open failed-items.json.

You should see the item data for the request that remained undelivered. Its failure details show why the request entered the error branch.

File Missing or Empty?

Open the verification execution in n8n to confirm that the error output handled at least one item.
Check that the Convert to File node ran before the disk node.
Check the destination recorded in File Path and Name for a missing folder or filename.
Ask for help with my missing failed-items.json file.

That closes the reliability gap. Your workflow now batches requests, pauses between batches, retries temporary failures, and records anything still undelivered in failed-items.json.

The workflow is ready to export as a reusable template for future bulk API jobs.

Secret mission

Audit the Workflow's Recovery Path

Your workflow can recover from a rate limit, but reliable automation also needs evidence that every protection worked. Audit the saved executions to prove where the burst failed, how delivery recovered, and where any remaining items were preserved.

Clean Up Your Resources

Your rate-limit workflow creates no paid cloud resources. Choose whether to keep the n8n setup available, pause its running process, or remove the saved workflow and files.

A workflow export keeps the batching, wait, retry, and error-handling configuration together as a reusable template.

Use the export option in the open workflow editor to download Rate Limit Resilient API Workflow as a JSON file.
Check your browser's downloads to confirm that the workflow export was downloaded.

Resources you used:

The saved Rate Limit Resilient API Workflow in your n8n instance.
The running local n8n process, if your setup uses one.
The failed-items.json file containing requests that remained undelivered after every retry.
The downloaded workflow export containing your reusable template.

Keep everything running

No action needed. Choose this if you are still testing rate limits or adapting the workflow for another API.

Keep n8n running while you continue testing the workflow.
Keep the downloaded workflow export as a reusable template.
Keep failed-items.json as a record of the items captured by the error-handling branch.

Pause - I'll come back to this later

Stop a local n8n process to free your machine's resources. Your saved workflow and files remain available for the next session.

Press Ctrl+C in the terminal that started n8n if you are using a local instance.
Close the workflow editor browser tab.
Keep the downloaded workflow export for importing the template later.
Keep failed-items.json if you want to review the undelivered item data later.

Delete - I don't want to use this again

Remove the saved workflow, failure log, and downloaded export if you do not plan to reuse this project. The exported file remains a backup until you delete it in the final cleanup actions.

Open the menu for Rate Limit Resilient API Workflow in the workflow editor.
Choose the action that removes the workflow from your n8n instance.
Return to the workflow list to confirm that Rate Limit Resilient API Workflow no longer appears.
Delete failed-items.json from the same location where you opened it earlier.
Check that location to confirm that failed-items.json no longer appears.
Delete the downloaded workflow export from your browser's download location.
Check the download location to confirm that the workflow export no longer appears.
Press Ctrl+C in the terminal that started n8n if the local process is still running.

Nice Work!

You did it! Your n8n workflow now processes 50 API requests without collapsing under rate limits. Its error branch records every item that remains undelivered in failed-items.json.

You've learned how to:

Trigger a rate-limit failure by sending 50 items quickly. Diagnose the 429 response through the failed execution.
Turn a burst of requests into a paced batch run that completes without an unhandled failure. Confirm automatic retry attempts through the execution log.
Protect undelivered items with an error branch that writes their data to failed-items.json. Confirm the file contains every remaining failure.
Complete an optional Secret Mission to push your workflow reliability skills further.

Ready to quiz yourself?