Make.com + n8n 如何將翻新工具的照片自動上架至 WooCommerce

A shop that sells refurbished professional power tools has a problem that new-goods shops don't: there are no manufacturer photos. Every unit is different, so every unit has to be photographed, cleaned up and listed by hand. Per product that is a few minutes. Across hundreds of products it is days of work that you can't hand to anyone without the photo quality dropping.

I built a pipeline for Luko Tools, a Slovak shop selling refurbished Milwaukee, DeWalt and Makita tools. Today the owner's whole job per product is to upload the photos into a Google Drive folder. This post is about how it is put together and, more usefully, where I deliberately stopped.

What the shop did before

For every product the same chain of steps:

1. Photograph the product.
2. Move the photos to the computer and sort them.
3. Fix the quality (refurbished goods are shot in a workshop, not a studio).
4. Remove the background so it looks like a product shot.
5. Upload to WooCommerce and create the product.
6. Fill in the name and attributes and assign a category.

How it works now

• Input: photos land in a Google Drive folder. Nothing else is required from a person.
• Trigger: a Make.com scenario watches the folder and starts by itself, no click.
• Upscale: the photos are enlarged and sharpened to sales quality by an image-processing service over an API.
• Background removal: a workshop shot becomes a clean product photo, again over an API.
• Product creation: the WooCommerce REST API creates the product together with a gallery of the processed images, and it goes live.
• Social post: once the product is live, an n8n workflow builds an Instagram and Facebook post from its photo and name.

Make.com orchestrates the product chain; n8n handles the social posts. They are separate on purpose: the second workflow only reacts to "a product is now live", so it can fail, be paused or be changed without touching the part that fills the catalogue.

One constraint I'd repeat: don't touch the shop

The whole solution runs outside WooCommerce and talks to it, and to the social networks, only through official APIs. No plugin, no edits to the theme or the shop's code. That way it can't break the shop and the shop's updates can't break it in a way that is hard to trace. The price of this approach is a precondition: it only works if the platform has an API. WooCommerce has one. With another platform I would check that first.

What I left with a person

This is the part case studies usually skip, and it decides whether the thing is usable:

• Photography. The system processes a photo; it does not take one. A blurred or badly lit photo stays bad. Input quality sets output quality.
• Price and description. For refurbished goods they depend on the condition of that particular unit. That is a commercial decision, so it stays manual.
• Unusual items. Anything that doesn't fit the pattern is faster to create by hand, and that is fine. Not everything needs to go through the pipeline.

The trade-off I want to be upfront about

Unlike a workflow where a human approves the result, publishing here is automatic. The product goes live in the shop and the social post goes out without a further approval step. That was the right call for this shop and this kind of work — but it has a direct consequence: because nothing sits between the pipeline and the customer, the quality of the input photos is the only quality gate. If you build something similar for goods where a bad listing is costly, put an approval step before publishing.

Limits

• Image-service running costs depend on how many photos you process.
• It doesn't write prices or descriptions.
• It needs an API on the shop side.

What I did not measure

I don't quote hours saved as a measured number, because I didn't measure it, and a figure you can't verify doesn't help you decide. What I can say is what changed: instead of a chain of steps per product, one thing remains — upload the photos. The batch of hundreds of products runs unattended, and listing stopped being postponed, so products now reach the shop continuously instead of in occasional pushes.

The client's review is published on an independent portal (Jaspravim.sk), not written on my site. The full case page, with the diagram and limits, is here: nexflow.sk/en/case-ecommerce-products.

I'm Maksym, an independent automation developer in Banská Bystrica, Slovakia. I build Make.com and n8n workflows and AI agents, and I work in writing only: nexflow.sk.

Disclosure: this post was written by an AI assistant (Claude) from my project's published case notes. The facts come from my own project; the wording is the AI's.