Communicating Between n8n Workflows
1. Communicating Between n8n Workflows
In the last video, you built workflows that react to external events through the use of webhooks. In this video, we'll ask: what if the external event is from another workflow?2. Modular Workflows
In real-world automation, we almost never have a single workflow doing everything. We break things into pieces — one workflow detects something, another processes it, maybe a third one handles notifications. The question is: how do they talk to each other?3. The Producer-Consumer Pattern
Here's the pattern, and it builds directly on what you just learned. Workflow B — the one that does the processing — exposes a Webhook Trigger. It sits there waiting for a request, just like your previous workflow.4. The Producer-Consumer Pattern
Workflow A — the one that kicks things off — uses an HTTP Request node to send a POST request to Workflow B's webhook URL.5. The Producer-Consumer Pattern
Workflow A is the "producer" — it produces the request.6. The Producer-Consumer Pattern
Workflow B is the "consumer" — it consumes the request and does something with it. This producer-consumer pattern is everywhere in automation, extending far beyond just n8n. Microservices, event architectures, and different tool integrations all utilize the producer-consumer pattern. Let's build this!7. Example: Building a Producer-Consumer Workflow
We start with Workflow B — the consumer. It already has a Webhook Trigger listening for POST requests, an Edit Fields node that stamps a "processed" status and timestamp onto the incoming data, and a Respond to Webhook that sends the enriched result back to the caller. We copy its production URL and activate the workflow so that the URL is live and listening. Now we switch to Workflow A — the producer. We add a Manual Trigger, then an HTTP Request node. This node is how n8n talks to the outside world — you'll use it constantly throughout this course. We set the method to POST, paste Workflow B's production URL into the URL field, toggle Send Body on, and set Body Content Type to JSON. For our payload, we define a simple order — an order ID, a customer name, and an amount. When we execute Workflow A, the HTTP Request node sends that payload to Workflow B. Workflow B processes the order and responds, and the response shows up right here in the HTTP Request node's Output panel. We can see the status code, and the response body contains our original order fields plus the "processed" status and timestamp that Workflow B added. This means Workflow A can make decisions based on what Workflow B reported. Did it succeed? Did it return an error? You can inspect that response and route accordingly.8. Summary
For now, the core takeaway is this: an HTTP Request node plus a Webhook Trigger gives us a reliable, structured communication between workflows. Workflow A sends data and gets a response. Workflow B receives data and sends a response. Clean and predictable.9. Let's practice!
In the exercises, you'll be given a pre-built consumer workflow. Your job is to build the producer side and get these two workflows talking!Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.