n8n + WooCommerce

Not "order created". WooCommerce creates the order at checkout, before payment clears, so an order.created event also fires for pending payments that are later abandoned or fail. For anything that ships goods or sends a receipt, trigger on order updates and let an IF node continue only when the status is processing (paid, awaiting fulfillment) or completed. Expect order.updated to fire several times for one order, as notes, status, and payment details change, so the workflow should check the status and ignore updates it has already handled.

WooCommerce queues webhook deliveries as background jobs that run on WP-Cron, and WP-Cron only runs when someone visits the site. On a quiet store, events can sit in the queue for minutes; the fix is a real server cron job that calls wp-cron.php every minute. The second trap is that WooCommerce disables a webhook after several consecutive failed deliveries, which can happen while n8n is down for an update, and it stays off until someone re-enables it under WooCommerce's webhook settings. A nightly n8n workflow that pulls recently modified orders through the WooCommerce node catches anything a missed webhook dropped.

It can, but on the cheapest VPS plans it shouldn't. WordPress with WooCommerce already uses most of a small server's memory, and n8n is a separate Node.js process that needs its own headroom, especially when a workflow handles large order exports. If both share one machine, size it with room to spare (2 GB of RAM or more) and keep them in separate containers or services. Otherwise, run n8n on a second small server or on n8n Cloud; a separate host also means a store traffic spike cannot slow down your automations, and vice versa.

Yes. n8n's WooCommerce node creates and updates orders, products, and customers through WooCommerce's REST API, using an API key pair generated under WooCommerce's advanced settings. Common uses are marking an order completed when a shipping provider reports delivery, or adjusting stock when an external warehouse system changes. Give that key read/write access only if the workflow truly writes, and remember that writes trigger their own order.updated webhooks, so a workflow listening for updates should ignore the changes it made itself.

The WordPress Automation stack is the broader one: it automates a whole WordPress site (new posts, form submissions, user sign-ups, and WooCommerce events too) and lets you pick n8n, Zapier, or Make as the engine. This stack narrows in on running a store with n8n: order, refund, customer, and stock workflows, where the order-status and webhook-delivery details above matter most. Pick this one when the store is the reason you are automating; pick WordPress Automation when content and forms matter as much as orders, or when you'd rather use a hosted engine like Zapier.