Mastering the n8n Merge Node: 10 Practical Examples for Seamless Data Integration

G: Welcome, n8n enthusiasts! 👋 Are you tired of juggling data from multiple sources? Do you wish there was a magic wand to combine disparate pieces of information into one cohesive stream? Enter the n8n Merge node! 🪄

Often underestimated, the Merge node is a powerhouse for data integration. It’s the glue that binds different branches of your workflow, allowing you to enrich, consolidate, and structure your data exactly how you need it. But mastering its various modes and use cases can feel a bit like learning a new language.

Fear not! In this comprehensive guide, we’ll demystify the n8n Merge node. We’ll explore its core functionalities and dive deep into 10 practical, real-world examples that will transform you from a Merge novice to a true integration wizard. Get ready to streamline your workflows and unlock new possibilities! ✨

Understanding the n8n Merge Node: Your Data’s Best Friend 🤝

Before we jump into examples, let’s quickly recap what the Merge node does and its primary modes. Think of it as a data junction where two or more paths converge.

n8n primarily offers two types of Merge nodes, each serving a distinct purpose:

1. Merge (Key-based Merging):

   • This is like an SQL JOIN operation. It combines items from different branches based on a common key (e.g., user ID, product SKU, email address).
   • Modes:
     • Inner Join: Only outputs items where the key exists in both input branches. 🤝 (Intersection)
     • Left Join: Outputs all items from the “main” (left) input, and matching items from the “secondary” (right) input. If no match, the right-side data will be null or empty. ⬅️ (All left + matches)
     • Right Join: Outputs all items from the “secondary” (right) input, and matching items from the “main” (left) input. If no match, the left-side data will be null or empty. ➡️ (All right + matches)
     • Full Join: Outputs all items from both inputs. If a key doesn’t match, the corresponding data from the other input will be null or empty. 🌐 (Union)

2. Merge By Index (Positional Merging):

   • This node combines items based on their position (index) in the input lists. It doesn’t rely on a shared key.
   • Modes:
     • Combine: Merges items at the same index from different inputs into a single item. For example, item 0 from input 1 combines with item 0 from input 2. 🧩
     • Append: Simply concatenates all items from all input branches into one long list. It’s like stacking lists on top of each other. ➕

Got it? Great! Let’s get our hands dirty with some practical examples. 👇

10 Practical Examples of the n8n Merge Node in Action! 🚀

Each example will include a scenario, how it works, and what the expected output looks like.

Example 1: Basic Inner Join – Connecting Users to Their Orders 🛒

Scenario: You have a list of user profiles from your CRM and a list of recent orders from your e-commerce platform. You want to see only the orders that are associated with existing users in your CRM.

How it Works:

1. Input 1 (CRM Users): [{id: "u1", name: "Alice"}, {id: "u2", name: "Bob"}, {id: "u3", name: "Charlie"}]
2. Input 2 (E-commerce Orders): [{orderId: "o1", userId: "u1", product: "Laptop"}, {orderId: "o2", userId: "u4", product: "Mouse"}, {orderId: "o3", userId: "u2", product: "Keyboard"}]
3. Merge Node:
   • Mode: Inner Join
   • Key 1: id (from CRM Users)
   • Key 2: userId (from E-commerce Orders)

Expected Output: Only matching users and their orders will be combined. User u4 (who ordered a mouse) is not in the CRM, so that order is excluded. Charlie (u3) has no order, so he is also excluded.

[
  {
    "id": "u1",
    "name": "Alice",
    "orderId": "o1",
    "userId": "u1",
    "product": "Laptop"
  },
  {
    "id": "u2",
    "name": "Bob",
    "orderId": "o3",
    "userId": "u2",
    "product": "Keyboard"
  }
]

Example 2: Left Join – Getting All Users and Their Orders (If Any) 🧑‍💻

Scenario: You want a complete list of all your CRM users. If they have an order, you want to see it alongside their profile. If they don’t, you still want their profile.

How it Works:

1. Input 1 (CRM Users – Left Input): Same as Example 1.
2. Input 2 (E-commerce Orders – Right Input): Same as Example 1.
3. Merge Node:
   • Mode: Left Join
   • Key 1: id
   • Key 2: userId

Expected Output: All users from the left input are included. Matching orders are added. For users without orders, the order-related fields will be empty or null.

[
  {
    "id": "u1",
    "name": "Alice",
    "orderId": "o1",
    "userId": "u1",
    "product": "Laptop"
  },
  {
    "id": "u2",
    "name": "Bob",
    "orderId": "o3",
    "userId": "u2",
    "product": "Keyboard"
  },
  {
    "id": "u3",
    "name": "Charlie"
    // No matching order data for Charlie
  }
]

Example 3: Right Join – Seeing All Orders and Their Associated Users (If Any) 📦

Scenario: You need to process all incoming orders. For each order, you want to enrich it with the associated user’s CRM details, but only if that user exists in your CRM. You still want to process orders from non-CRM users.

How it Works:

1. Input 1 (CRM Users – Left Input): Same as Example 1.
2. Input 2 (E-commerce Orders – Right Input): Same as Example 1.
3. Merge Node:
   • Mode: Right Join
   • Key 1: id
   • Key 2: userId

Expected Output: All orders from the right input are included. Matching user data is added. For orders from users not in the CRM, the user-related fields will be empty or null.

[
  {
    "orderId": "o1",
    "userId": "u1",
    "product": "Laptop",
    "id": "u1",
    "name": "Alice"
  },
  {
    "orderId": "o2",
    "userId": "u4",
    "product": "Mouse"
    // No matching user data for user u4
  },
  {
    "orderId": "o3",
    "userId": "u2",
    "product": "Keyboard",
    "id": "u2",
    "name": "Bob"
  }
]

Example 4: Full Join – Comprehensive Overview of Users and Orders 🌍

Scenario: You want a single report that includes all users (even those without orders) and all orders (even those from users not in your CRM), with matching data combined. This is great for auditing or broad analysis.

How it Works:

1. Input 1 (CRM Users – Left Input): Same as Example 1.
2. Input 2 (E-commerce Orders – Right Input): Same as Example 1.
3. Merge Node:
   • Mode: Full Join
   • Key 1: id
   • Key 2: userId

Expected Output: All users and all orders are included. Fields for non-matching data are null or missing.

[
  {
    "id": "u1",
    "name": "Alice",
    "orderId": "o1",
    "userId": "u1",
    "product": "Laptop"
  },
  {
    "id": "u2",
    "name": "Bob",
    "orderId": "o3",
    "userId": "u2",
    "product": "Keyboard"
  },
  {
    "id": "u3",
    "name": "Charlie"
    // No matching order data
  },
  {
    "orderId": "o2",
    "userId": "u4",
    "product": "Mouse"
    // No matching user data
  }
]

Example 5: Merge By Index – Combine – Adding Metadata to Items 🏷️

Scenario: You have a list of products and a separate list of their current stock statuses, where the order of items in both lists corresponds directly. You want to combine them item by item.

How it Works:

1. Input 1 (Products): [{name: "Apple"}, {name: "Banana"}, {name: "Orange"}]
2. Input 2 (Stock Status): [{status: "In Stock"}, {status: "Low Stock"}, {status: "Out of Stock"}]
3. Merge By Index Node:
   • Mode: Combine

Expected Output: Items at the same index from both inputs are merged into a single item.

[
  {
    "name": "Apple",
    "status": "In Stock"
  },
  {
    "name": "Banana",
    "status": "Low Stock"
  },
  {
    "name": "Orange",
    "status": "Out of Stock"
  }
]

💡 Tip: This is perfect for situations where you’ve split items for parallel processing and need to bring them back together in their original order.

Example 6: Merge By Index – Append – Consolidating Lists 📚

Scenario: You have two separate lists of tasks from different departments (e.g., Marketing and Sales). You want to combine them into one master task list.

How it Works:

1. Input 1 (Marketing Tasks): [{task: "Plan Campaign"}, {task: "Create Ad Copy"}]
2. Input 2 (Sales Tasks): [{task: "Follow Up Leads"}, {task: "Update CRM"}]
3. Merge By Index Node:
   • Mode: Append

Expected Output: All items from Input 1 are followed by all items from Input 2 (and so on, if more inputs).

[
  {
    "task": "Plan Campaign"
  },
  {
    "task": "Create Ad Copy"
  },
  {
    "task": "Follow Up Leads"
  },
  {
    "task": "Update CRM"
  }
]

Example 7: Merging Data from Different API Calls (Product Details + Inventory) 🌐

Scenario: You’re fetching product details from your main product API and inventory levels from a separate warehouse management system API. You need to combine this information to display complete product data.

How it Works:

1. Execute Workflow:
   • HTTP Request 1 (Product Details API): Returns [{id: "p1", name: "Widget A", desc: "Great product"}, {id: "p2", name: "Gadget B", desc: "Cool gadget"}]
   • HTTP Request 2 (Inventory API): Returns [{productId: "p1", stock: 15}, {productId: "p2", stock: 0}, {productId: "p3", stock: 5}]
2. Merge Node:
   • Mode: Left Join (assuming you want all product details, even if inventory data is missing, but prefer Inner Join if only products with inventory are needed)
   • Key 1: id (from Product Details)
   • Key 2: productId (from Inventory)

Expected Output (Left Join):

[
  {
    "id": "p1",
    "name": "Widget A",
    "desc": "Great product",
    "productId": "p1",
    "stock": 15
  },
  {
    "id": "p2",
    "name": "Gadget B",
    "desc": "Cool gadget",
    "productId": "p2",
    "stock": 0
  }
]

Example 8: Enriching Data with Lookups (Support Tickets + Customer Info) 📞

Scenario: You receive new support tickets (e.g., from a webhook). Each ticket has a customerEmail. You want to look up the full customer profile from your CRM (via another API call or database query) and add that information to the ticket.

How it Works:

1. Input 1 (Support Tickets): [{ticketId: "T001", customerEmail: "alice@example.com", issue: "Login issue"}, {ticketId: "T002", customerEmail: "bob@example.com", issue: "Payment error"}]
2. Input 2 (Customer CRM Lookup – executed for each ticket): This involves branching. For each ticket, you’d use a Split In Batches or Item Lists node, then an HTTP Request or Database node to fetch customer details based on customerEmail. The result for “alice@example.com” might be [{email: "alice@example.com", name: "Alice Smith", tier: "Premium"}].
3. Merge Node:
   • Mode: Inner Join (or Left Join if you want to keep tickets even if no customer match)
   • Key 1: customerEmail (from Tickets)
   • Key 2: email (from CRM Lookup results)

Expected Output (Inner Join):

[
  {
    "ticketId": "T001",
    "customerEmail": "alice@example.com",
    "issue": "Login issue",
    "email": "alice@example.com",
    "name": "Alice Smith",
    "tier": "Premium"
  },
  {
    "ticketId": "T002",
    "customerEmail": "bob@example.com",
    "issue": "Payment error",
    "email": "bob@example.com",
    "name": "Bob Johnson",
    "tier": "Standard"
  }
]

💡 This is a common pattern: fetch primary data, then use a second branch to enrich it with related data using a Merge node.

Example 9: Rejoining Conditional Branches 🚦

Scenario: You have a list of new user registrations. You process them differently:

• Users from US get assigned to one sales team.
• Users from EU get assigned to another.
• Users from APAC get a different welcome email. After these conditional actions, you want to collect all processed users back into a single list for a final step (e.g., logging them to a central database).

How it Works:

1. Input (New Registrations): [{id: 1, country: "US"}, {id: 2, country: "EU"}, {id: 3, country: "US"}, {id: 4, country: "APAC"}]
2. Workflow:
   • If node branches based on country.
   • Each branch performs specific actions (e.g., Set node to add assignedTeam, Email node).
   • Crucially, each branch eventually outputs its processed user items.
3. Merge By Index Node:
   • Mode: Append (since you just want to combine the lists from each branch).
   • Connect all conditional branches as inputs to the Merge node.

Expected Output: All processed items from all branches are combined into a single flat list. The order might not be the original order, but all items will be present.

[
  { "id": 1, "country": "US", "assignedTeam": "Sales_US" },
  { "id": 3, "country": "US", "assignedTeam": "Sales_US" },
  { "id": 2, "country": "EU", "assignedTeam": "Sales_EU" },
  { "id": 4, "country": "APAC", "emailSent": true }
]

💡 If you needed to re-associate processed items with their original pre-branching state, you’d use a Merge node (not Merge By Index) and pass a unique ID through each branch as the key.

Example 10: Merging a Single Configuration Object with Multiple Items ⚙️

Scenario: You have a fixed configuration object (e.g., API key, default settings) and you want to inject this configuration into every item in a list before sending it to another system.

How it Works:

1. Input 1 (Items): [{data: "item1"}, {data: "item2"}, {data: "item3"}]

2. Input 2 (Configuration): [{apiKey: "abc123xyz", defaultRegion: "us-east-1"}]

   • Important: Use a Split In Batches or Item Lists node on the configuration, and set the batch size to the number of items in your Input 1. Or, if it’s a single item, make sure it’s replicated to match the number of items in Input 1 before the merge (e.g., using a Loop or Set node with expressions). The easiest way to achieve this for a single config is to have the config as the right input and use a Set node with a “Mode” of “Keep Data” on the Left side, adding the configuration fields using an expression from the right side.

   Let’s simplify for the Merge By Index (Combine) as it’s more direct for 1:1 mapping:

   • If you have 1 config item and 3 data items, you need to replicate the config item 3 times first. A Set node can do this by using the number of items from the other branch.
   • Replication Step (before Merge): Use a Set node for Input 2: [{"apiKey": "abc123xyz", "defaultRegion": "us-east-1"}] and use the “Combine all items” setting, then feed it to a Code node or another Set node to duplicate the configuration for each incoming item from Input 1.

   A more elegant solution that avoids explicit replication is often done without a Merge node, using a Set node on the primary list and referencing the single config item: Let’s reframe this for a true Merge Node example that makes sense.

Revised Example 10: Combining Batched Data with a Single Aggregated Metric 📊

Scenario: You’re processing user events in batches. After processing each batch, you calculate a totalEventsProcessed metric for that batch. You want to combine this totalEventsProcessed with the original items in the batch for logging or further processing.

How it Works:

1. Input 1 (Batch Items): [{event: "login", user: "A"}, {event: "logout", user: "A"}, {event: "click", user: "B"}]

2. Input 2 (Batch Metric – from a separate branch): A branch calculates totalEventsProcessed: 3. This might come from an Aggregate node or Code node.

   • Self-correction: For this to work with Merge By Index (Combine), the single metric would need to be replicated for each item in the batch. This is a more complex setup.

   Let’s revert to a more straightforward Merge (Key-based) scenario that’s common:

Revised Example 10: Merging Default Settings into User Preferences 🛠️

Scenario: You have a list of user-specific preferences, but you also have a set of default preferences. For any preference not explicitly set by the user, you want to apply the default.

How it Works:

1. Input 1 (Default Settings – Left Input): [{theme: "dark", notifications: true, timezone: "UTC"}]
2. Input 2 (User Preferences – Right Input): [{userId: "u1", theme: "light"}, {userId: "u2", notifications: false}]
   • Pre-processing: This scenario typically involves an Item Lists or Loop node to ensure you’re merging one default set with one user set at a time.
   • Better approach: This is less of a direct Merge node use case, and more of a Code node or a Set node using an expression like {{ Object.assign({}, $json.defaultSettings, $json.userPreferences) }}.

Okay, let’s find a perfect 10th example for the Merge node itself.

True Example 10: Combining Data for Reporting from Parallel Branches 📈

Scenario: You kick off a process that generates two distinct types of reports in parallel (e.g., Sales Summary and Marketing Performance). You want to collect both sets of reports into a single, combined output after they are generated.

How it Works:

1. Branch 1 (Sales Report Generation): Generates [{reportType: "Sales", month: "Jan", revenue: 10000}, {reportType: "Sales", month: "Feb", revenue: 12000}]
2. Branch 2 (Marketing Report Generation): Generates [{reportType: "Marketing", campaign: "Spring", leads: 500}, {reportType: "Marketing", campaign: "Summer", leads: 700}]
3. Merge By Index Node:
   • Mode: Append
   • Connect both report generation branches to this Merge node.

Expected Output: All reports are consolidated into a single list.

[
  {
    "reportType": "Sales",
    "month": "Jan",
    "revenue": 10000
  },
  {
    "reportType": "Sales",
    "month": "Feb",
    "revenue": 12000
  },
  {
    "reportType": "Marketing",
    "campaign": "Spring",
    "leads": 500
  },
  {
    "reportType": "Marketing",
    "campaign": "Summer",
    "leads": 700
  }
]

💡 This is an extremely common pattern for parallel processing where the outputs just need to be collected.

Advanced Tips & Best Practices for the Merge Node 🧙‍♂️

• Pre-process Your Data: Before merging, ensure your keys are clean, consistently named, and of the same data type. Use Set or Code nodes to standardize them. For instance, if one input has userId and another has customer_id, rename one to match the other.
• Handle Missing Data: Understand how null or missing fields behave in different join modes. Use If nodes after a merge to check for the existence of combined data (e.g., {{ $item("right").id }} to check if a right-side item was merged).
• Performance: For very large datasets, consider optimizing your workflow. Sometimes, fetching related data in batches or using database-level joins (if applicable) before n8n can be more efficient.
• Debugging: The “Input” and “Output” panels in n8n are your best friends. Check the data going into the Merge node and compare it to the output to understand why certain items might be missing or combined incorrectly.
• “Keep Only First Match”: In the Merge node (key-based), if you have multiple matches on the right side for a single left item, you can choose to Keep Only First Match or Combine All Matches. Choose wisely based on your data structure!
• Renaming Fields: After a merge, you might end up with duplicate field names (e.g., id from left, id from right). Use a Set node with “Rename Key” to avoid conflicts or make data clearer (e.g., userId_CRM, userId_Orders).

Conclusion: Your Merge Node Mastery Awaits! 🚀

The n8n Merge node is a foundational element for building robust and sophisticated workflows. By understanding its different types and modes, and by practicing with these practical examples, you’re now equipped to tackle complex data integration challenges with confidence.

From combining customer data, enriching API responses, to rejoining conditional branches, the Merge node empowers you to create seamless, automated processes. So go forth, experiment, and make your n8n workflows more powerful than ever before!

What’s your favorite way to use the Merge node? Share your insights in the comments below! 👇

Happy automating! 🎉