n8n: multiple branches produce too many API calls?

The reported starting point

A public case describes several branches feeding a Code node and excessive downstream API requests. Q1 Some replies mix execution order with concurrency. This guide therefore focuses on observable request counts rather than making a blanket claim about every n8n execution mode.

The Merge node can combine inputs. Append collects their items, but does not automatically produce one business-level result. n8n separately documents approaches for handling API limits. Q2 Q3

Make the quantities visible first

1. Mark one event. Use a controlled test with a stable test ID. Disconnect the writing or chargeable destination request, or replace it with an output-only step during investigation.
2. Count invocations and items separately. Record how often each node runs and how many items each invocation receives and returns. Add the intended number of HTTP requests. A Code node can execute once and still output several items.
3. Define the business expectation. Should nine partial results become one summary, or should nine legitimate records be processed? The first requires deliberate aggregation; the second requires appropriate pacing.
4. Inspect the combination. Compare the Merge mode and actual inputs in your installed version. Where records are joined by a key, check its uniqueness. Combining every possible pair can multiply the data volume unexpectedly.
5. Identify the provider's limit. Distinguish requests per time period, simultaneously running jobs and an exhausted usage allowance. Choose a response based on the specific limit described in the API response.

Apply and verify the appropriate change

For one final action after all results arrive, the aggregation should return exactly one intended output object. For several valid actions, controlled batches or delays may be appropriate. Include other workflows using the same provider account in the investigation: spacing requests in one workflow does not necessarily enforce an account-wide limit.

After the change, one test event should generate the predetermined number of destination requests. Preserve the relationship between the test ID, n8n executions and destination request IDs. The disappearance of a 429 alone does not prove that unintended duplicate requests have been removed.

Frequently asked questions

Does Merge automatically turn many items into one?

No. Its mode and the subsequent processing determine the output. Inspect the actual items rather than counting the visible nodes in the editor.

Is a longer retry interval enough?

Only when the limit is understood and repeating the operation is safe. Remove unintended duplicate actions from the data flow before relying on retries.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0128 with KAN KAI WORKS.