WooCommerce Make integrationAutomate WooCommerce with Make.

Search for a Coupon goes through the coupons of the shop and hands back what matches. Being a search, it can return nothing, one coupon or several, and every module placed after it runs once per result.

Get a Coupon pulls one coupon back from its identifier, so the scenario works on the real record rather than on a value somebody typed into a field.

Create a Coupon adds a new code to the shop from inside the scenario. The discount your automation decided on exists in WooCommerce a second later, with nobody opening the admin.

Rather than piling up near-duplicate codes, Update a Coupon edits the one that already exists. The scenario points at it and changes what has to change.

Delete a Coupon removes a code from the shop for good. It closes a campaign cleanly, and it is also the module that deserves the most care in this group.

Search for a Customer digs through the customer list and returns the ones that match. Zero results is a perfectly normal answer, and your scenario should have a route for it.

Get a Customer fetches one customer record from its identifier. Useful when a trigger hands you an identifier and the following modules need everything else.

Create a Customer opens an account in the shop from data the scenario already holds, so a person who arrived through another channel ends up in WooCommerce like everyone else.

Update a Customer writes a change onto an existing record instead of creating a second one. The shop keeps a single customer, and the order history stays attached to it.

Delete a Customer takes an account out of the shop. Scenarios built around a removal request or a data policy end on this module.

Search for an Order goes through the orders of the shop and returns each one that matches. Several results mean the modules after it run several times, once per bundle, and each run counts one operation, the unit Make deducts from your plan.

Get an Order retrieves a single order from its identifier, with whatever the shop holds on it at that moment.

Create an Order writes a new order into WooCommerce. The shop becomes the place where the sale is recorded even when it started somewhere else entirely.

Update an Order changes an order that already exists, which is what you want when the sale itself is fine but one detail moved.

Update an Order Status moves an order from one state to the next, the step most fulfillment scenarios finish on.

Delete an Order erases an order from the shop. Rare in a healthy shop, genuinely useful when tests or duplicates pollute the data.

List Order Notes returns the notes attached to one order, the fastest way to see what your team and your automations already wrote on it.

Get an Order Note brings back one note from its identifier, when the scenario knows exactly which one it needs rather than the whole list.

Create an Order Note writes a line on the order, visible to whoever opens it in WooCommerce. It turns a silent automation into something your team can read.

Delete an Order Note removes a comment from an order, usually one your own scenario wrote a moment earlier.

Search for a Product scans the catalog and returns what matches. It answers the question every catalog scenario opens with: is this reference already in the shop?

Get a Product fetches one reference from its identifier, with the data the shop holds at that instant.

Create a Product adds one reference to the catalog. The scenario does the typing, and the shop gets a product that behaves like any other.

Update a Product edits a reference already in the catalog, which is how a scenario keeps prices and descriptions aligned with the source your team maintains.

Delete a Product takes a reference out of the catalog. Clean and immediate. Worth a second look all the same, because the scenario will keep doing it on every run, to whatever reference the previous module hands over.

Create Products (Batch) sends several references to the shop in one go instead of one module run per line. Make hands back one bundle per product created, so whatever follows runs once for each of them.

Update Products (Batch) applies a wave of changes to several references at once, the counterpart of the batch create when the products are already in the shop.

Delete Products (Batch) clears several references in a single run. It is the quickest cleanup in the list and the one with the least margin for error.

List Product Attributes returns the characteristics your shop knows about: size, color, material, whatever your catalog happens to use.

Get a Product Attribute returns a single characteristic, the one your scenario points at, with what the shop stores about it. It reads rather than changes anything.

Create a Product Attribute declares a new characteristic for the catalog. Nothing is filled under it yet: you are opening the column, not its values.

Update a Product Attribute edits a characteristic already declared, without touching the products that use it.

Delete a Product Attribute removes a characteristic from the shop, and the documentation says its terms leave with it.

Create Product Attributes (Batch) declares several characteristics in one run and returns one bundle per attribute created, ready for the modules that come next.

List Product Attribute Terms gives you the values stored under one attribute: every color, every size the shop already knows.

Get a Product Attribute Term returns one value and its details, the narrow version of the list module above.

Create a Product Attribute Term adds a value under an attribute, a new shade under Color for example, so products can use it right away.

Update a Product Attribute Term rewrites a value that exists, which keeps the catalog readable when a label was wrong from the start.

Delete a Product Attribute Term removes one value from an attribute while the attribute itself stays in place.

Create Product Attribute Terms (Batch) loads a whole set of values under an attribute in one run, with one bundle back per term.

Search Product Categories hands your scenario the category list of your shop, one category at a time. As a search module, it can come back with nothing, with one, or with a whole set.

When your scenario already knows which category it needs, Get a Product Category pulls that one and stops there. It brings back the details your shop keeps on it, ready to map into the next module.

Create a Product Category builds a new category in your shop from values your scenario is already carrying, so nobody opens the WordPress admin to prepare the ground.

Category names age badly. Update a Product Category rewrites one that already exists, with the values your scenario holds at that moment, one category per run.

Deleting a category by hand takes one click in WordPress, and that click never happens on the day a season ends. Delete a Product Category removes the category your scenario points at, when the rule says so.

Every version of a product leaves List Product Variations on its own, one after another, so the branch below works through them without anyone opening the product page.

Get a Product Variation goes after one precise version, the one whose ID your scenario already holds, and brings back what the shop stores on it.

A supplier ships a product in several versions and your shop knows only one of them. Create a Product Variation adds a missing version to a product that is already online, from the values your scenario carries.

Stock moves faster than anyone can retype it. Update a Product Variation changes one version of a product with the values your scenario is holding, and leaves the other versions alone.

Delete a Product Variation takes one version off a product and leaves the product itself online. It works on the version your scenario names, nothing wider.

Sooner or later a scenario needs something none of the listed modules covers. Make an API Call is the way out: it reaches the WooCommerce API from inside the scenario, on the connection you already created.