Run Tasks in Parallel with HTTP Request Fan-Out and Webhooks

Built with n8n
1

Fan out any number of tasks concurrently from one HTTP Request node, with timestamps, execution IDs, and an automated report to verify how they ran.

Who’s it for

Builders who need several independent tasks, such as API calls, model queries, scraping jobs, or other workloads, to run at the same time instead of one after another.

This template is also useful if you want to inspect and verify the actual execution behavior rather than simply assuming that a workflow is running in parallel.

What it does

n8n’s engine runs one node at a time, so parallel-looking branches do not execute concurrently. The concurrency in this template comes from inside a single node: the HTTP Request node starts a request for every input item without waiting for the previous response, so all requests can be in flight at the same time. Most other nodes process items one by one, so this is a behavior of the HTTP Request node, not of items in general.

The Batching option controls how many requests are started at once. Setting Items per Batch to -1 sends all items without batching, allowing all requests to be started concurrently. (Note that 0 is treated as 1, so -1 is the only value that fully disables batching.)

Each input item contains the URL of a webhook on the same n8n instance, and every incoming webhook call starts its own independent execution. The parent workflow keeps the HTTP connections open while those executions run. When they finish, their responses are re-paired with the original items by index, so the results remain in a predictable order regardless of which task finishes first.

Compared with the callback pattern using Execute Workflow with “Wait for Sub-workflow” disabled, $execution.resumeUrl, and resumable Wait nodes, this approach requires no resume URLs, retry loops, or routing logic. Request and response pairing is handled natively by the HTTP Request node.

The trade-off is that the parent workflow holds the HTTP connections open for the duration of the tasks, so this approach is best suited to workloads that complete in seconds or a few minutes. For very long-running jobs, a callback-based pattern is generally more appropriate.

How it works

  1. Three Set nodes define the “services”. Each contains a webhook URL and a payload.
  2. A Merge node with 3 inputs in Append mode combines them into a single stream of three items.
  3. A single HTTP Request node with batching disabled (Items per Batch: -1) sends all three POST requests concurrently.
  4. Each webhook branch records startedAt, simulates work with a Wait node (7s / 2s / 13s), and returns a minimal response containing {service, startedAt, endAt, executionId}.
  5. A Prove Parallel node, a Set node with Execute Once enabled that reads $('HTTP Request').all(), analyzes the results and generates the concurrency report without using a Code node.

Setup

  1. Replace YOUR-N8N-URL in the three service nodes with your instance’s base URL.
  2. Activate the workflow. Production /webhook/ paths only exist while the workflow is active.
  3. Click Execute. You’ll see four executions: the manual parent execution plus three webhook executions. Their execution IDs appear in the report.
1 Like
Parllel Executions in n8n
2

This is a useful distinction that trips people up: parallel-looking branches are not always parallel work.

I like that you included execution IDs and timing proof instead of just saying “this runs in parallel.” For anything using this pattern in production, I’d probably add one more field to the report: whether each child execution created a side effect or only returned data.

That makes retries a lot safer if one branch finishes and another branch fails.

1 Like