Turning a 35,000-Product Feed Into a Danish WooCommerce Shop

Thirty-five thousand products is not a number you fix by hand. If a category is wrong, if a description reads like it was translated by someone in a hurry, if an image is missing: at that scale, hand-editing listings isn't a plan, it's a life sentence. For a Danish WooCommerce store selling VidaXL products, that was roughly the situation: supplier data split across an API and a CSV, categories that didn't map cleanly to the store's structure, and product copy that needed to read naturally in Danish, not like it had been run through a translator and left there.

We built a pipeline to handle it in stages, rather than trying to force one tool to do everything at once: Python, Supabase, n8n, OpenAI, and WooCommerce, each doing the part it's actually good at.

Give the data somewhere to live before you publish it

The VidaXL API didn't carry every field the store needed, so a large supplementary CSV filled the gaps. Rather than trying to reconcile two inconsistent sources live, in production, on every sync, a Python process merged them into a single structured record for all 35,000-plus products and loaded that into Supabase. That gave the rest of the pipeline a clean, central product database to work from, instead of asking WooCommerce to make sense of a messy raw feed every time it ran.

From there, an n8n workflow periodically pulls products out of that database for processing. OpenAI handles the Danish translation, tightens up descriptions, and helps assign categories. Once a product's data is in shape, the workflow maps it into WooCommerce's expected format and publishes it: images, pricing, category relationships, VidaXL identifiers, the whole listing.

The categories problem nobody mentions until it bites them

Here's a failure mode that's easy to miss until it's already happened: run a large catalog import repeatedly, and every pass can quietly spawn new, slightly different duplicate categories instead of reusing the ones that already exist. Months later, the store's category tree turns into an archaeology project. We built the workflow to check whether the parent and child categories it needs already exist before creating anything new. It's a small check, but it keeps the catalog navigable for shoppers and sane for whoever has to maintain it.

The same discipline applies to product identity. Every listing carries its VidaXL identifier through to the published product, specifically so later runs of the pipeline know which store listing traces back to which source record. That part's solid. What isn't fully documented yet is the long-term update and deletion policy for when a supplier discontinues a line. That's a reasonable next problem, not a flaw in the current one.

AI did the writing, not the deciding

It's worth being specific about where AI actually sits in this pipeline, because it's not where people usually assume. OpenAI doesn't invent product facts. The structured database built from the CSV and API carries those. Its job is narrower: turn supplier copy into readable Danish, and help route products into the right categories. The facts come from the source data; the language and classification work is where the model earns its place.

We don't have a public count of how many listings are live today, translation review rates, or sales performance. Those are good numbers to add once they can be verified rather than estimated. What's already clear is the design choice that made the rest possible: staging a catalog this size in a real database, before it ever touches the storefront, is what turned an unmanageable import into a controlled, repeatable process.

If your supplier feed needs cleanup before it's fit for a storefront, show us what you're working with.