Supplier XML product import: how to make it reliable

What to get from the supplier before you start

Most import problems begin with knowing nothing about the supplier's file except its address. Before building or configuring an import, ask for a few things.

If you also sell through Google Shopping, it helps to compare the supplier's fields with the Google Merchant Center product data specification: it shows well what data a reliable product card usually needs.

Field mapping: who owns what

The mapping table is the most important import document. It states not only which field goes where but who controls each field: the supplier or you. If the supplier controls the description, every import will overwrite the text you edited.

Categories and variants

Supplier categories reflect their warehouse logic, not the way your shoppers choose. So categories are almost never imported directly: a table turns each supplier category into one of yours, and a new, unmapped category goes to a review list rather than into the store.

Variants – sizes, colours, capacities – are often the hardest part. Some suppliers list each variant as a separate product, others as one product with a list of variants. Before importing, decide what will be one product with variants in your store, and which field groups the variants.

Validate before you load

The most important import rule: a bad file must never reach the store. The supplier's server may return half a file, an error page instead of XML, or a file with no prices – and an import that doesn't check for this corrupts the catalogue.

The XML 1.0 specification is strict here: a malformed file is a fatal error after which the processor must not continue normal processing, and every XML processor must be able to read UTF-8 and UTF-16. Carry the same logic into your import – if the file is malformed, update nothing.

If validation fails, the whole import should stop rather than load whatever succeeded. A half-updated catalogue is worse than yesterday's.

The first import and updates

The first import creates products; every later one updates them. They are two different jobs, so the rules differ too.

• First import: products, images, categories and descriptions are created. It's worth running in a staging environment and reviewing a few dozen products from different categories.
• Update: the product is found by SKU or another stable identifier, and only supplier-owned fields change.
• A new product in the supplier's file: it is created, but if its category isn't mapped yet it stays hidden until you've reviewed it.

Platform importers work the same way: WooCommerce's built-in CSV importer matches an imported product to an existing one by ID or SKU, and images must be uploaded beforehand or available online.

Stock and prices: how often to update

Prices and stock change more often than descriptions, so update them separately and more often. If the supplier provides a separate, smaller stock file, use it; if not, update only those fields without reprocessing the whole catalogue.

How often depends not on technology but on how fast your products sell and how often the supplier updates the file. Updating more often than the supplier is pointless; less often, and you risk selling what's gone.

What to do with products that vanish from the file

The simplest option is to delete a product that's no longer in the supplier's file. But then its address goes too: pages found by search engines, ads, links from other sites and shoppers' bookmarks lead to an error page.

When there are several suppliers

Two suppliers often sell the same product under different codes and titles. If you don't recognise it, duplicates appear in categories and shoppers see two different prices for the same product.

• Recognise the same product by EAN or another manufacturer code, not by title.
• Decide which supplier's price and stock are shown: the cheaper one, the one with stock, or the preferred one.
• Give each supplier its own version of the mapping table, but shared categories of yours.
• Import suppliers separately so one supplier's error doesn't stop the rest.

WooCommerce, Shopify and custom solutions

Neither WooCommerce's nor Shopify's built-in import accepts supplier XML directly. WooCommerce's built-in importer is made for CSV files and matches products by ID or SKU; Shopify imports products from CSV and can overwrite existing products with the same identifier (handle).

That's why there is almost always a layer between the supplier's XML and the store: an import plugin, a custom import script or an automation that downloads the file, validates it, applies the mapping and updates products through the platform's API. Which to choose depends on the number of suppliers, the size of the catalogue and how many rules are needed. We compare the platforms in more depth in Shopify vs WooCommerce.

Monitoring: how to know an import failed

Supplier servers sometimes don't respond, file structures change without warning, access credentials expire. An import that simply does nothing in that case is dangerous: the store looks fine while prices and stock go stale.

Response to such incidents follows your maintenance plan; without a plan, automation incidents are handled as separate work. More on how we build and look after these processes on our automation page.