You can connect your sales channels (Shopify, WooCommerce, Amazon) to n8n as a central hub, use the AI Agent nodes to normalize product data and route orders intelligently, and write back to a single source of truth like your ERP or unified database. The whole thing can run on the free self-hosted n8n Community Edition, but you still need to pay for the infrastructure it runs on. One person, one weekend, one integration layer that scales from 1 client to 20. The following AI architecture flow describes how.
Why Multi-Platform Integration Matters Now
If you're selling on Shopify and WooCommerce and Amazon, you have three separate systems that each believe they're the source of truth. Shopify thinks it owns the product catalog. WooCommerce disagrees. Amazon has its own opinions about your inventory counts. The result: you're manually copying SKUs between dashboards, overselling inventory that doesn't exist, and spending Tuesday afternoons reconciling order spreadsheets.
This is not a "nice to have" automation. It's the difference between running a business and working for your business. n8n has matured into a capable automation hub for AI-assisted workflows. The AI Agent node — combined with n8n's broad integration catalog — lets you build an integration layer that doesn't just move data, it thinks about it. An agent can look at a product title from Shopify ("Vintage Leather Messenger Bag - Brown - 15 inch") and map it to WooCommerce's structured fields without you writing regex. It can read an Amazon order and route it to the right warehouse based on inventory levels it checks in real time.
The Architecture uses n8n as Your Integration Hub
Here's the core pattern. Every channel talks to n8n. n8n talks to one unified backend. Nothing talks directly to anything else.
The Integration Layer Overview in a FlowZap Diagram
Copy and paste the following FlowZap code into a project in your FlowZap account to see this diagram.
main { # Multi-Platform Integration Layer
n1: circle label:"Start"
n2: diamond label:"Channel?"
n3: rectangle label:"n8n Webhook Receiver"
n4: rectangle label:"AI Agent: Parse & Validate"
n5: diamond label:"Event Type?"
n6: rectangle label:"Product Sync Pipeline"
n7: rectangle label:"Order Orchestrator"
n8: rectangle label:"Inventory Update"
n9: rectangle label:"Unified DB Write"
n10: rectangle label:"Fulfillment Trigger"
n11: circle label:"Done"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Shopify"]
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="product"]
n6.handle(right) -> n9.handle(left)
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left)
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left)
n2.handle(top) -> n3.handle(top) [label="WooCommerce"]
n5.handle(bottom) -> n7.handle(bottom) [label="Order"]
}
The flow is linear but the branching matters. A product creation event and an order event hit the same webhook — the AI agent classifies them and routes to different pipelines. You're not building separate integrations per channel. You're building one integration layer that handles all of them.
Building the Product Sync Pipeline
Product sync is where most solopreneurs hit a wall. Shopify's API returns variants[] with option1, option2, option3. WooCommerce wants attributes[] with terms[]. Amazon's SP-API wants completely different field names.
Hardcoding field mappings for every platform combination breaks the moment you add a fourth channel. This is where the AI Agent node earns its keep.
An AI-Powered Product Sync
Copy and paste the following FlowZap code into a project in your FlowZap account to see this diagram.
source { # Source Platform
n1: circle label:"Product Created"
n2: rectangle label:"Shopify Webhook"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n8n.n3.handle(left) [label="POST product"]
}
n8n { # n8n AI Agent Layer
n3: rectangle label:"Receive Webhook"
n4: rectangle label:"AI: Extract Fields"
n5: diamond label:"Has Variants?"
n6: rectangle label:"AI: Normalize Schema"
n7: rectangle label:"AI: Map Categories"
n8: rectangle label:"Queue Sync Tasks"
n3.handle(left) -> source.n2.handle(right) [label="200 OK"]
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="yes"]
n5.handle(bottom) -> n7.handle(top) [label="no"]
n6.handle(right) -> n8.handle(left)
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> target.n9.handle(left) [label="push product"]
}
target { # Target Platforms
n9: rectangle label:"Target API Router"
n10: rectangle label:"WooCommerce API"
n11: rectangle label:"Amazon SP-API"
n12: circle label:"Synced"
n9.handle(left) -> n8n.n8.handle(right) [label="ack"]
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left)
}
Here's the n8n workflow that implements this:
- Trigger: Shopify webhook fires on
products/create. - AI Agent node receives the raw JSON payload with this prompt: "Extract: title, description, price, SKU, variant structure (size/color/material), images, and category. Output as structured JSON."
- Switch node branches on
hasVariants. Variant products go through a normalization sub-workflow; simple products skip it. - AI Agent node #2 maps the source categories to the target platform's taxonomy: "Map these Shopify product categories to WooCommerce categories. If no match exists, suggest the closest parent category."
- HTTP Request nodes push to WooCommerce API and Amazon SP-API through a routing layer.
Tip: Use n8n's SplitInBatches node to handle multi-variant products. Each variant becomes its own API call but shares the parent product ID for linking.
Platform Comparison: What Each Integration Needs
| Platform | Trigger Method | Product Complexity | Order Events | API Quirks |
|---|---|---|---|---|
| Shopify | Webhook (near real-time) | Variants nested, metafields custom | orders/create, orders/paid | Rate limits vary by API and plan |
| WooCommerce | Webhook or Poll | Attributes as arrays, global attributes | order.created, order.updated | REST API v3, batch endpoints available |
| Amazon SP-API | SQS Notifications | Flat ASIN model, no variants natively | ORDER_CHANGE notifications | Throttled, requires selling partner authorization |
AI-Powered Order Routing
Orders are where your integration layer proves it's not just a script. When an order comes in from any channel, the AI agent decides what happens next — not a hardcoded switch statement.
Order Routing Decision Engine:
Copy and paste the following FlowZap code into a project in your FlowZap account to see this diagram.
channels { # Sales Channels
n1: rectangle label:"Order Received"
n2: diamond label:"Platform?"
n3: rectangle label:"Unified Order Payload"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> n3.handle(top)
n3.handle(right) -> agent.n4.handle(left) [label="new order"]
}
agent { # AI Decision Engine
n4: rectangle label:"AI: Classify Order"
n5: diamond label:"Risk Score?"
n6: rectangle label:"Auto-Process"
n7: rectangle label:"Flag for Review"
n8: diamond label:"Inventory Check"
n9: rectangle label:"Route to Warehouse"
n10: rectangle label:"Backorder Queue"
n4.handle(left) -> channels.n3.handle(right) [label="ack"]
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="low"]
n5.handle(bottom) -> n7.handle(top) [label="high"]
n6.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="in stock"]
n8.handle(bottom) -> n10.handle(top) [label="none"]
n9.handle(right) -> ops.n11.handle(left) [label="dispatch"]
}
ops { # Operations
n11: rectangle label:"OMS / ERP Write"
n12: rectangle label:"Shipment Created"
n13: rectangle label:"Notify Customer"
n14: circle label:"Complete"
n11.handle(left) -> agent.n9.handle(right) [label="confirmed"]
n11.handle(right) -> n12.handle(left)
n12.handle(right) -> n13.handle(left)
n13.handle(right) -> n14.handle(left)
}
The AI agent isn't just classifying — it's making contextual decisions a switch statement can't handle:
- Risk scoring: The agent checks order value, shipping address vs billing address, and customer history. A $2,000 order to a new customer going to a freight forwarder? Flagged. A $45 reorder from a 2-year customer? Auto-processed.
- Inventory routing: Instead of hardcoding "Warehouse A for US, Warehouse B for EU," the agent queries inventory levels and routes to whichever location has stock. If both are empty, it routes to backorder.
- Exception handling: If an order contains a pre-order item mixed with in-stock items, the agent splits the order and communicates the split shipment to the customer.
The AI Agent Prompt That Does the Heavy Lifting
You are an order routing agent for a multi-channel eCommerce business.
Given this order payload, determine:
1. Risk level (low/medium/high) based on: order value, customer history,
address match, and any red flags in the notes field.
2. Fulfillment route: check inventory at each warehouse, pick the one
with sufficient stock. If none have stock, route to backorder.
3. Action: auto-process (low risk + in stock), flag for manual review
(high risk), or split (partial stock).
Output as JSON:
{
"risk": "low|medium|high",
"risk_reason": "brief explanation",
"warehouse": "A|B|C",
"action": "auto|review|split|backorder",
"customer_notification": "draft message if needed"
}
Tip: Store the agent's decision JSON in your unified database with the order. When something goes wrong, you have the agent's reasoning — not just a silent routing decision you can't audit.
Self-Hosting vs n8n Cloud: What a Solopreneur Actually Needs
| Factor | Self-Hosted (Community) | n8n Cloud (Starter/Pro) |
|---|---|---|
| Cost | $0/month + VPS (~$6/mo) | $24-60/month |
| Executions | Unlimited | 2,500-10,000/month |
| AI Agent node | Full access, any LLM provider | Same |
| Multi-tenancy | Separate instances per client | Not built for this |
| Maintenance | You update it | n8n handles it |
| Data sovereignty | Full control | n8n's infrastructure |
For a solopreneur running multiple client stores, self-hosted can be the most cost-effective path when you want control over infrastructure and execution volume. A low-cost VPS can run n8n with Docker Compose, and self-hosting gives you more flexibility over execution volume and tenant isolation than entry-level cloud plans.
# docker-compose.yml — self-hosted n8n with PostgreSQL
version: '3.8'
services:
n8n:
image: n8nio/n8n:latest
ports:
- "5678:5678"
environment:
- N8N_DATABASE_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=${N8N_DB_PASS}
- N8N_ENCRYPTION_KEY=${ENCRYPTION_KEY}
restart: always
postgres:
image: postgres:16
environment:
- POSTGRES_DB=n8n
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=${N8N_DB_PASS}
volumes:
- pgdata:/var/lib/postgresql/data
restart: always
volumes:
pgdata:
What Works vs. What Breaks
What Works
| Practice | Why |
|---|---|
| One webhook per event type | One products/create webhook in n8n handles Shopify, WooCommerce, and Amazon. The agent figures out the source from the payload shape. |
| AI for schema normalization | LLMs are genuinely good at "this field is called option1 here and attribute:size there, map them." Better than regex, faster than manual mapping. |
| Unified database as source of truth | n8n writes to your DB, not back to the platforms. Platforms are spokes. Your DB is the hub. |
| Telegram/Slack notifications from the agent | When the AI flags an order for review, it drops a message with the order summary and its reasoning. You approve/reject in 10 seconds. |
| n8n sub-workflows for reusable logic | Build one "Product Normalizer" sub-workflow. Call it from Shopify→WooCommerce, Amazon→Shopify, and any future combination. |
What Breaks
| Anti-pattern | Consequence |
|---|---|
| Platform-to-platform direct sync | Shopify→WooCommerce without n8n in the middle means you rebuild the logic for every pair. 3 platforms = 6 sync paths instead of 3. |
| Hardcoded field mappings | WooCommerce changes their API, your regex breaks, you don't notice until a customer emails you. The AI agent adapts to field name changes. |
| No inventory check before routing | Order gets routed to Warehouse A, Warehouse A has zero stock, customer waits 3 extra days. Always query inventory in real time before splitting. |
| Running everything on n8n Cloud for multiple clients | 2,500 executions/month sounds like a lot until you have 3 clients with active stores. Shopify webhooks alone can fire 100+ times per product edit. Self-host. |
| Skipping the audit log | When the AI agent routes a $5,000 order to "auto-process" and it turns out fraudulent, you need to know why it made that call. Store every decision with its reasoning. |
The Solopreneur Lens: Build Once, Sell to Many
Here's what separates a weekend project from a sellable service:
You're not building this for yourself. You're building an integration layer that you can deploy for Client A (Shopify + WooCommerce), Client B (Amazon + Shopify + Etsy), and Client C (WooCommerce + custom ERP) — using the same n8n workflows with different API credentials.
The key architectural decisions that make this work across clients:
- Credential isolation: Each client's n8n instance (or at minimum, each client's credentials) lives separately. Never share API keys between client workflows.
- Config-driven channels: Your workflow reads active channels from a config node, not hardcoded. Tomorrow when a client adds TikTok Shop, you toggle it on — you don't rebuild.
- Unified data model: Every channel writes to the same normalized schema in your DB. Fields like
product.title,product.sku,order.totalare consistent regardless of source. The AI agent does the normalization at ingestion time. - Per-client AI prompts: The base prompt is shared; the specifics (warehouse names, shipping carriers, tax rules) come from client-level config. Template:
"Route this order using routing rules for {client_name}. Warehouses: {warehouse_list}."
This is not an internal tool. It's a product you sell. Multi-tenancy isn't an accident — it's the business model.
The Bottom Line
n8n's AI Agent node can reduce the amount of custom glue code needed for schema mapping, routing, and exception handling in multi-platform eCommerce workflows. The agent handles the messy parts — schema mapping, risk scoring, exception routing — that previously required months of edge-case coding.
Start with product sync. That's the highest-value, lowest-risk integration. Once products flow cleanly between your channels, add order routing. Then inventory. Each layer builds on the last without breaking what came before.
The solopreneur who standardizes this architecture across clients can turn the same core workflow into a repeatable service offering with relatively low infrastructure overhead.
Inspirations
- n8n AI Agent integrations — Official n8n AI agent documentation and templates
- What is n8n? Full Guide (UI Bakery, 2026) — Deep overview of n8n's AI capabilities and architecture
- Rutter: The Systems of Agentic Commerce — Why agentic commerce is a systems problem, not a single integration
- n8n Shopify integration — Official Shopify node documentation
- n8n WooCommerce integration — Shopify→WooCommerce bridge patterns
- n8n Amazon integration — Amazon SP-API node documentation
- Multi-Agent Orchestration with n8n (Medium, 2026) — How n8n evolved into a multi-agent orchestration platform
- n8n vs Make: Best Ecommerce Workflows 2026 — Comparison of automation platforms for eCommerce
- n8n Community: Top 5 AI Agents for Small Business — Real-world agent patterns from the n8n community
- Fluent Commerce: How OMS Data Powers AI Agents — The role of Order Management Systems in agentic commerce
- n8n Self-Hosted Setup Guide (Infralovers) — Production-grade n8n deployment patterns
- n8nLab: WooCommerce n8n Workflow Automation — Enterprise-grade WooCommerce automation patterns
- Shopify→WooCommerce migration workflow (Reddit r/n8n) — Community-built product importer with 100+ nodes
- Domo: Inventory Management AI Agents — Types and patterns for inventory management agents
- Agentic Commerce Systems (Rutter) — The four core systems of agentic commerce: platform, ERP, OMS, WMS