Merge

Combines data from two inputs into a single output. The Merge node accepts data on two input handles (data1 and data2) and joins them according to the selected merge mode.

When to use Merge

Any time two or more upstream nodes need to feed a single downstream node, put a Merge node in between. Wiring both upstream edges directly to the same input of the downstream node is not allowed — the workflow editor flags this on save and the publish action is blocked with the message "Two upstream nodes target the same input." (See Workflows → Fan-in for the underlying rule.)

What you want	Wrong	Right
Combine two API result sets before processing	HTTP A → Filter and HTTP B → Filter into the same input	HTTP A → Merge.data1, HTTP B → Merge.data2, Merge → Filter
Join records from two database tables	Two SQL nodes both wired into a single Transform input	Two SQL nodes into Merge (mode: Merge by Key) → Transform
Run two pipelines in parallel then resume one downstream node	Two branches with edges into the same downstream node handle	Two branches → Merge (mode: Append) → downstream node

If you only need a downstream node to wait for two upstreams (no data join), still route them through Merge with mode Append — the four-mode picker covers every legitimate fan-in shape.

Configuration

Field	Description	Notes
Merge Mode	How to combine the two inputs	Append, Merge by Key, Zip by Position, or Combine (First Non-Empty). Defaults to Append.

Mode: Append

Concatenates all items from Input 1 followed by all items from Input 2 into a single list. No additional settings required.

Example: Input 1 has items [A, B] and Input 2 has items [C, D] -- output is [A, B, C, D].

Mode: Merge by Key

Performs a database-style join, matching items from both inputs on a shared field value.

Field	Description	Notes
Match Field (Input 1)	The field to match on in Input 1	Required. Supports nested paths (e.g., user.id).
Match Field (Input 2)	The field to match on in Input 2	Required. Supports nested paths.
Join Type	How to handle unmatched items	See table below. Defaults to Inner Join.
When fields conflict	How to resolve fields that exist in both items	See collision strategies below. Defaults to Prefer Input 2.

Join Types

Join Type	Behavior
Inner Join	Only include items where a match is found in both inputs
Left Join	Include all items from Input 1; matched items are merged, unmatched items from Input 1 are kept as-is
Outer Join	Include all items from both inputs; matched items are merged, unmatched items from either side are kept as-is

Mode: Zip by Position

Pairs items from Input 1 and Input 2 by their position (index 0 with index 0, index 1 with index 1, etc.) and merges each pair into a single item.

Field	Description	Notes
When inputs have different lengths	How to handle length mismatches	Stop at shortest (default) or Include all (pad missing).
When fields conflict	How to resolve fields that exist in both items	See collision strategies below. Defaults to Prefer Input 2.

Mode: Combine (First Non-Empty)

Returns the first input that contains data. If Input 1 has items, those are returned. If Input 1 is empty, Input 2 is returned instead. Similar to SQL COALESCE.

No additional settings required.

Collision Strategies

When merging two items that share the same field name, you can choose how to resolve the conflict:

Strategy	Behavior
Prefer Input 2 (default)	The value from Input 2 overwrites Input 1
Prefer Input 1	The value from Input 1 is kept
Keep both	Both values are kept with _1 and _2 suffixes added to the field name

INFO

Collision strategies apply to Merge by Key and Zip by Position modes. The Append mode does not merge individual items together, so collisions do not occur.

Output

The Merge node outputs the combined data on a single output handle.

TIP

Use Merge by Key to enrich data from one source with data from another -- for example, joining customer orders with customer profiles on a shared customer_id field.