n8n Shopify Automation: Order & Inventory Workflows (2026)

TL;DR: Connect n8n to Shopify with the Access Token credential (the API Key method is deprecated), then drive workflows off the Shopify Trigger node, which exposes around 80 webhook topics including orders/create, orders/paid, inventory_levels/update, and checkouts/create. Start with one workflow: orders/paid to notification and fulfillment. Add low-inventory alerts and multi-channel stock sync next. Save abandoned-checkout follow-up for last, because it touches messaging and timing logic that breaks if your order workflows aren't solid first.

The reason to run Shopify through n8n instead of stacking single-purpose apps is control over the logic between events. Shopify's own Flow handles simple if-this-then-that automation inside the store, but the moment you need to enrich an order with data from another system, route it conditionally, or sync stock to a channel Shopify doesn't natively talk to, you want a real workflow engine. n8n gives you that without the per-task billing that makes high-volume stores expensive on hosted tools.

How n8n talks to Shopify: two nodes, one credential

There are two nodes you'll use, and they share a credential. The Shopify Trigger node listens for store events via webhook and starts a workflow. The Shopify (action) node performs reads and writes: it supports the Order and Product resources, each with create, delete, get, get-all, and update operations. Customer and inventory writes that the action node doesn't cover natively, you do with the HTTP Request node against the Shopify Admin REST or GraphQL API using the same credential.

That split matters for planning. If your workflow only needs to react to orders and update products, the built-in nodes carry you. If you need to touch customers, inventory levels, or fulfillments programmatically, expect to drop in an HTTP Request node. That's normal, not a workaround.

Set up the Access Token credential

Use the Access Token method. Shopify no longer generates API keys with passwords, so the older API Key credential type is deprecated and you should ignore it for new builds. OAuth2 exists but is meant for public apps and requires a Shopify Partner account, which is overkill for a single store.

To create the token:

In Shopify admin, go to Settings > Apps and sales channels > Develop apps.
Click Create a custom app, name it (something like n8n-automation), and set a developer.
Under Configuration, choose your Admin API access scopes. For order and product workflows, you need read_orders, write_orders, read_products, and write_products. Add read_inventory and write_inventory if you're doing stock sync, and read_customers for customer-based logic.
Install the app and copy the Admin API access token from the API credentials tab.

In n8n, create a Shopify Access Token credential with three fields: your shop subdomain (the part before .myshopify.com), the access token, and the app's secret key (used to verify webhook signatures). Get scopes right the first time. If a workflow returns a 403, it's almost always a missing scope, and changing scopes after install requires reinstalling the app.

The Shopify Trigger topics you actually use

The Trigger node exposes roughly 80 webhook topics. You will use maybe six of them. The ones worth knowing:

orders/create fires when an order is placed, paid or not. Use this for capturing all orders including manual and draft conversions.
orders/paid fires only after payment clears. This is the right trigger for fulfillment and accounting, because acting on orders/create means you sometimes process unpaid orders.
orders/fulfilled and orders/cancelled for post-purchase and refund flows.
inventory_levels/update fires when stock at a location changes. This is the backbone of low-stock alerts and multi-channel sync.
checkouts/create and checkouts/update for abandoned-checkout detection.
customers/create for welcome flows and CRM sync.

The most common mistake here is using orders/create when you mean orders/paid. If you fulfill or invoice off orders/create, you will eventually ship against an order that never gets paid. Pick the topic that matches the business moment, not the one that sounds closest.

One operational note: the Shopify Trigger registers a real webhook in your store when the workflow is activated and removes it when deactivated. If a trigger stops firing, check that the workflow is active and that the webhook still exists in Shopify under Settings > Notifications > Webhooks. A reinstalled app or rotated token can orphan webhooks.

Workflow 1: order paid to notify, fulfill, and log

This is the first thing every store should build. When an order is paid, post a notification to your team channel, write a row to a tracking sheet, and optionally trigger fulfillment. Branch on order value or tags so high-value orders get a different path.

Structure: Shopify Trigger (orders/paid) to a Code node that shapes the payload, to an IF node that splits on order total, to your notification and logging nodes.

The Code node is where you keep downstream nodes clean. Instead of mapping {{ $json.line_items[0].title }} in five different places, normalize once:

// Code node: shape the Shopify order payload
const order = $input.first().json;

return [{
  json: {
    orderId: order.id,
    orderNumber: order.name,            // e.g. "#1042"
    email: order.email,
    total: parseFloat(order.total_price),
    currency: order.currency,
    itemCount: order.line_items.reduce((n, li) => n + li.quantity, 0),
    items: order.line_items.map(li => `${li.quantity}x ${li.title}`).join(', '),
    customerName: `${order.customer?.first_name ?? ''} ${order.customer?.last_name ?? ''}`.trim(),
    isHighValue: parseFloat(order.total_price) >= 250,
  },
}];

The ?? guards matter: guest checkouts can arrive without a customer object, and an unguarded order.customer.first_name will throw and fail the whole run. For more patterns like this, see our n8n Code node JavaScript and Python examples. Then route on isHighValue with an IF node, send the normalized fields to your notification node, and append a row to a sheet using the patterns in our Google Sheets automation templates.

Build this one first because it touches the highest-frequency event in your store and surfaces every credential and payload issue you'll hit later. Get it stable, and the rest follow the same shape.

Workflow 2: low-inventory alerts and multi-channel stock sync

Trigger this off inventory_levels/update. The webhook payload gives you inventory_item_id, location_id, and the new available count. From there you have two jobs: alert when stock drops below a threshold, and push the new level to other channels.

For alerts, add an IF node checking available against your reorder point and route low items to a notification. The catch is that inventory_levels/update sends the inventory item ID, not the product or SKU, so a human-readable alert needs a lookup. Resolve it with an HTTP Request node against the Admin API:

{
  "method": "GET",
  "url": "=https://&#123;&#123;$credentials.shopSubdomain&#125;&#125;.myshopify.com/admin/api/2026-01/inventory_items/&#123;&#123; $json.inventory_item_id &#125;&#125;.json",
  "authentication": "predefinedCredentialType",
  "nodeCredentialType": "shopifyAccessTokenApi"
}

For multi-channel sync, the principle is one source of truth. Pick the system that owns true stock (usually Shopify, sometimes a warehouse or ERP) and push from it outward. Do not set up two-way sync between Shopify and another channel as your first build. Bidirectional sync creates race conditions where a sale on each side fires simultaneous decrements and you oversell. Run one-directional from your source of truth, and only add the reverse path once you've added idempotency.

The honest warning: inventory sync is the workflow most likely to cause a customer-facing problem if it's wrong. A broken order notification annoys your team; a broken stock sync oversells products and forces refunds. Test it against a single low-volume SKU before pointing it at your whole catalog.

Workflow 3: abandoned-checkout follow-up

Build this last. It depends on checkouts/create and checkouts/update, plus timing logic and a send-or-suppress decision, and it's the workflow where bad logic embarrasses you in front of customers.

The pattern: when a checkout is created, store it (a Google Sheet, Airtable, or a database) with a timestamp. On a schedule, scan for checkouts older than your wait window (commonly an hour) that have no matching completed order, then send one follow-up email. The two pieces people get wrong:

First, suppression. Before sending, confirm the checkout didn't convert. The Shopify abandoned-checkout data can lag, so cross-check against orders by email or checkout token before you email someone "you forgot something" after they already bought it. That single mistake erodes trust faster than no email at all.

Second, frequency. One follow-up, maybe two. An abandoned-checkout sequence that fires four emails reads as desperate and gets marked as spam, which hurts deliverability for your transactional mail too.

Because this workflow combines a trigger, persistent state, a scheduled scan, and conditional sending, it's a poor first project. By the time you build it, you'll already have credentials, payload shaping, and notifications working from the first two workflows, and you can focus on the logic that actually makes or breaks it.

What to automate first, ranked

If you run a store and want the order that gives you the most return per hour of build time:

Order-paid notification and logging. Highest event frequency, immediate operational value, lowest risk. Start here.
Low-inventory alerts. Read-only, so it can't break anything customer-facing, and it prevents the stockouts that quietly cost sales.
Order-paid to fulfillment. Once notifications are stable, automate the handoff to your 3PL or fulfillment tool.
One-directional inventory sync. Real value, real risk. Build it carefully, test on one SKU.
Abandoned-checkout follow-up. Highest logic complexity, do it once the foundation is solid.

The pattern across all of these: react to a verified business event, shape the payload once in a Code node, branch on real conditions, and write to systems you control. Skip the temptation to build the clever multi-channel sync first. The boring order-paid notification is what pays for the time you spend learning the tooling.

If you'd rather have these running than spend a weekend learning webhook scopes and idempotency, that's the kind of thing we set up at n8n Logic. Either way, build the order-paid workflow first and let it earn the next one.

FAQ

Does the n8n Shopify node support customers and inventory directly?

The built-in Shopify action node supports the Order and Product resources, each with create, get, get-all, update, and delete operations. For customers, inventory levels, and fulfillments, use the HTTP Request node against the Shopify Admin API with the same Access Token credential. The Shopify Trigger node, separately, does fire on customer and inventory webhook topics.

Which Shopify credential should I use in n8n?

Use the Access Token method. It needs your shop subdomain, the Admin API access token from a custom app, and the app's secret key. The older API Key (with password) credential is deprecated because Shopify no longer issues those passwords. OAuth2 is only for public apps and requires a Shopify Partner account.

Should I trigger on orders/create or orders/paid?

Use orders/paid for anything involving fulfillment, invoicing, or accounting, because it only fires after payment clears. Use orders/create when you genuinely need every order including unpaid and manually created ones. Triggering fulfillment off orders/create eventually means processing an order that never gets paid.

Why did my Shopify Trigger stop firing?

The Trigger node registers a webhook in Shopify only while the workflow is active and removes it on deactivation. If events stop arriving, confirm the workflow is active and check the webhook still exists under Settings > Notifications > Webhooks. Reinstalling the custom app or rotating the token can orphan the registered webhook.

Is two-way inventory sync between Shopify and another channel safe?

Not as a first build. Bidirectional sync creates race conditions where simultaneous sales on both sides fire conflicting stock decrements and you oversell. Run one-directional sync from a single source of truth, test against one low-volume SKU, and only add the reverse path once you've built in idempotency checks.

What Admin API scopes does n8n need for Shopify?

For order and product workflows: read_orders, write_orders, read_products, and write_products. Add read_inventory and write_inventory for stock sync, and read_customers for customer logic. A 403 error almost always means a missing scope, and changing scopes requires reinstalling the custom app.