Introduction

In real automation workflows, data rarely flows in a single straight line. You might fetch customer records from a CRM in one branch, pull their recent orders from an API in another branch, and then need to bring those two streams together into unified objects before passing them downstream. That is exactly what the Merge node handles.

The Merge node accepts two separate input branches — referred to as Input 1 and Input 2 — and combines their items according to a strategy you choose. Getting the merge mode wrong is one of the most common sources of silent data bugs in n8n, where items seem to combine but the output is not what you expected. Understanding the difference between the modes upfront saves a lot of debugging later.

The Four Merge Modes

N8n's Merge node offers four modes: Append, Combine by Position, Combine by Key, and Multiplex. Each answers a different question about how items from the two branches should relate to each other.

Append simply concatenates both lists. Every item from Input 1 comes first, then every item from Input 2. No pairing happens. Use this when you want a single flat list and the two branches are independent — for example, merging two separate lists of email addresses to send one campaign.

Combine by Position (previously called Merge by Index) pairs items by their order in the list. Item 0 from Input 1 merges with Item 0 from Input 2, Item 1 with Item 1, and so on. The fields from both items are merged into one object. If the lists are unequal in length, the shorter list determines the output count by default.

Combine by Key matches items from the two branches using a shared field value — similar to a SQL JOIN on a column. You specify a key field in each input (they can have different field names), and n8n finds pairs where the values match.

Multiplex produces every possible combination of items from Input 1 and Input 2 — a cartesian product. If Input 1 has 3 items and Input 2 has 4 items, Multiplex outputs 12 items. This is rarely what you want, but useful for generating combinations such as pairing every product with every discount tier.

Practical Example: Combine by Key

Suppose your HTTP Request node returns customer profiles in one branch:

[
  { "customerId": "C001", "name": "Alice" },
  { "customerId": "C002", "name": "Bob" }
]

And a second HTTP Request returns order totals in another branch:

[
  { "id": "C002", "totalSpent": 340 },
  { "id": "C001", "totalSpent": 120 }
]

The items are in different orders and use different field names for the same customer identifier. In the Merge node set to Combine by Key, you configure Input 1 Key Field as customerId and Input 2 Key Field as id. N8n will match C001 to C001 and C002 to C002 regardless of order, producing:

[
  { "customerId": "C001", "name": "Alice", "id": "C001", "totalSpent": 120 },
  { "customerId": "C002", "name": "Bob", "id": "C002", "totalSpent": 340 }
]

Items from Input 1 that have no match in Input 2 are dropped by default. You can change this behavior in the Output Type option, choosing to keep unmatched items from Input 1, Input 2, or both — equivalent to LEFT, RIGHT, or FULL OUTER joins in SQL.

Combine by Position Example

Combine by Position is the right choice when you know both branches will always produce the same number of items in the same order. A typical case is splitting a list, enriching each item through two different APIs in parallel, and then rejoining the enriched results.

[
  { "userId": 1, "email": "alice@example.com" }
]

If Input 1 holds the base user record and Input 2 holds a score from a scoring service:

[
  { "score": 87 }
]

Combine by Position merges these by index into:

[
  { "userId": 1, "email": "alice@example.com", "score": 87 }
]

If you ran this against a list of 50 users split across both branches, all 50 items merge cleanly as long as the order is preserved — which it typically is when both branches start from the same Split in Batches or SplitOut node.

Common Mistakes

The most frequent mistake is using Combine by Position when the two branches process items at different speeds or apply filtering, causing the lists to get out of sync. The merge will silently pair the wrong items. If there is any chance the order could differ, use Combine by Key instead.

Another issue is triggering the Merge node before both branches have finished executing. In n8n, the Merge node automatically waits for both inputs to arrive before processing, but this only works correctly when both branches originate from the same upstream node. If you connect unrelated trigger paths into a Merge node expecting synchronization, the behavior is undefined and often produces duplicate runs.

Finally, watch out for field name collisions. When two items share a field name and you combine them, the value from Input 2 overwrites the value from Input 1 by default. Rename conflicting fields upstream with a Set node before merging if you need to preserve both values.

Summary

The Merge node is the backbone of multi-branch workflows in n8n. Append stacks lists, Combine by Position pairs items by order, Combine by Key joins items by a shared field value, and Multiplex generates every combination. The key decision is always whether your two data streams have a structural relationship — if they do, use Combine by Key for reliability; if they are guaranteed to be ordered and equal in length, Combine by Position is simpler. Getting this choice right prevents an entire class of subtle data integrity bugs.