WooCommerce n8n integrationAutomate WooCommerce with n8n.

Creates the customer record in WooCommerce and returns it with the identifier every other customer operation asks for later.

• Email (required): the address the account is attached to, often {{ $json.email }} when the item comes from a form or an earlier node.
• Additional Fields: 7 optional fields, among them First Name, Last Name, Username, Password, Billing Address and Shipping Address.

This operation takes one identifier and removes the matching account from the store. There is no second parameter and no filter, so the branch that calls it deserves a condition in front.

• Customer ID (required): the ID of the customer to delete, not the email address. On a customer.* event, read it from the payload with {{ $json.id }}.

Pulling one customer back is the usual second step after an order event, because the order payload names the buyer by identifier and not much more.

• Customer ID (required): the ID of the customer to retrieve. Coming from an order, that is the Customer ID carried by the order itself.

Listing is where Return All earns its place: on, n8n chains the pages of the API until the customer base is complete.

• Return All: off, the node stops at Limit, the maximum number of customers to return.
• Filters: 3 fields, Email to look up one address, Order By among ID, Include, Name and Registered Date, and Sort Order for Ascending or Descending.

Editing an existing record works field by field: only what you add to the collection is sent, the rest of the customer stays untouched.

• Customer ID (required): the ID of the customer to update.
• Update Fields: 6 fields, including First Name, Last Name, Billing Address, Shipping Address, Password and Metadata.

Orders can be born outside the checkout, and that is what this operation is for: a phone sale, a subscription renewal, an order placed by a salesperson.

• Line Items: the products on the order, each with a Product ID, a Quantity and, when needed, a Variation ID.
• Additional Fields: 9 fields, among them Customer ID (0 for a guest), Status, Currency, Payment Method Title and Set Paid, which marks the order as paid, moves the status to Processing and reduces the stock.

Test orders pile up after a launch, and this is the operation that clears them out of the reports.

• Order ID: the order to remove. The node does not flag it as required, which is misleading: without it the operation has no target, so fill it in, usually from {{ $json.id }}.

After a webhook fires, the payload is not always the freshest version of the record. Reading the order again gives the workflow the current state.

• Order ID: the order to retrieve. Like the other order operations, it is not marked as required even though nothing works without it.

Reporting starts here. The 9 options of this operation turn a raw list into the exact slice a dashboard needs.

• Return All: on, every page is fetched; off, Limit caps the number of orders returned.
• Options: After and Before take an ISO 8601 date to frame a period, Status keeps a single state such as Completed or Refunded, and Customer or Product restrict the set to one buyer or one reference.

Most order automations end on this operation, because changing the status is what makes the rest of the store move.

• Order ID: the order to modify, not flagged as required by the node.
• Update Fields: 8 fields, with Status among Pending, Processing, Completed, Cancelled, Refunded and the rest, plus Transaction ID, Customer Note and Payment Method Title.

Adding a reference from a spreadsheet row is the classic use, and the node accepts far more than a name: 33 additional fields describe the product.

• Name (required): the product name, the only field the operation refuses to run without.
• Additional Fields: Regular Price and Sale Price, SKU as the unique identifier, Type among Simple, Grouped, External and Variable, Status to publish or keep a draft, plus Stock Quantity and Stock Status.
• Images: each image takes an Src URL and an Alt text.

Retiring a reference comes down to one field. The operation removes the product and everything the store shows about it.

• Product ID: the product to delete. The node leaves it optional, so a workflow that forgets the expression fails silently on an empty value.

Before promising a delivery date or applying a discount, a workflow usually needs the current state of the reference rather than the one cached somewhere else.

• Product ID: the product to read. On a product.* event, the identifier comes straight from the payload.

Catalog exports and price audits both go through this operation, and its 17 options are what keep the result usable.

• Return All: on for a complete catalog, off to stop at Limit.
• Options: Category Name or ID and Tag Name or ID narrow the set, Stock Status isolates In Stock, Out Of Stock or On Back Order, Min Price and Max Price frame a range, and SKU or Slug find one reference.

Repricing, restocking and unpublishing all land on the same operation, which accepts 34 fields and changes only the ones you fill in.

• Product ID: the product to modify, again not marked as required.
• Update Fields: Regular Price and Sale Price with Date On Sale From and Date On Sale To to schedule a promotion, Stock Quantity and Stock Status for inventory, and Status to move a reference between Publish, Draft, Pending and Private.