Before connecting a supplier stock feed to WooCommerce, agree which supplier record matches each sellable item, what its availability figure means and what the shop should do when the feed is late or incomplete. Automate only the fields whose meaning and ownership you have settled.
A regularly imported file can save manual work, but it cannot reserve stock at the supplier unless the order process provides that function. If several retailers share the same availability figure, an item shown as available can be sold elsewhere before your order reaches the supplier.
Start with the stock you are promising to customers
Separate stock on your own shelf from stock a supplier may dispatch. Your shelf count can be checked and allocated by your own operation. A supplier figure needs an explanation: does it mean physical stock, stock available to order, a status such as “available”, or an estimate covering several warehouses?
Ask whether the data includes reservations, damaged items, incoming deliveries and discontinued products. Also establish the unit. A quantity may describe individual items, cases or packs. Matching the right product code while misreading a case quantity can still produce an incorrect buying promise.
If you sell stock you own and also offer supplier-dispatched items, make the fulfilment rules explicit. Adding both quantities together can conceal different delivery times. Decide how the website will describe and fulfil an order containing each type.
Match the sellable item, including its variation
Keep a mapping between the supplier’s identifier and the shop’s stable SKU or other supported product identifier. Compare the exact model, colour, size, pack contents and unit. Similar titles are useful for a human review but should not silently settle an uncertain automatic match.
Take two suppliers offering the same named mug. One supplies individual mugs and the other supplies a boxed pair. Their quantities cannot be combined under one listing without a documented conversion and fulfilment rule. Keep the difference visible in the mapping.
For a variable product, match the sellable option. Supplier stock for a blue medium shirt should not update the whole range. The variation and stock plan helps establish whether stock belongs to each option or a genuinely shared parent pool.
Hold unknown and ambiguous records for review. A feed should not create a new public listing merely because a supplier has introduced a new code. New-product creation is a separate approval task, including descriptions, pictures and delivery information.
Decide whether a number replaces stock or changes it
A feed can describe a current total or a change since the previous update. Those require different handling. In an illustrative example, a value of five might mean “five available now” or “five more received”. Applying the second meaning to a current-total file would keep increasing the stock incorrectly.
Ask how repeated processing is handled. Receiving the same file twice should not apply a receipt twice. If the source supplies changes rather than totals, the integration needs a dependable way to recognise already processed events and preserve their order.
Own-stock sales introduce another problem. Suppose a file records ten units, the shop sells one, and a delayed job writes the older ten back. The customer order may be intact while the quantity has become wrong. Agree which system is authoritative and how activity between reading and writing is reconciled.
With multiple suppliers, establish whether they represent independent stock. Two feeds can sometimes describe the same underlying warehouse. Adding them together without checking can count the same items twice.
Treat missing, zero and stale as different conditions
Zero can be a valid confirmed quantity. Missing may mean the supplier omitted an item, removed it from the range or sent an incomplete file. Stale means you no longer know whether the last successful value is dependable. Choose a response for each before switching on the feed.
Define whether the file is a full snapshot or a partial update. If it is partial, an absent row may simply mean no change. If it is supposed to contain the entire range and suddenly contains only a handful of rows, applying it as a complete snapshot could affect many valid listings.
Set sensible checks around the real source: expected columns, usable timestamps, duplicate identifiers and unusually large changes in record count. These checks should hold suspicious data for review rather than guess what the supplier intended.
The response to stale information depends on the promise you make. You might hold affected products from sale, restrict quantities or require confirmation before accepting an order. Keeping the last figure may be acceptable for a particular operation, but give that decision an owner and a maximum acceptable age.
Check the whole update timeline
Ask when the supplier produces its data, when your integration retrieves it and how long processing takes. A job running frequently still reads old information if the supplier refreshes the source less often. Include the time needed to place or transmit the resulting customer order.
Record both the last attempt and the last successful accepted update. A dashboard saying a job “ran” can hide a download failure, rejected file or import that changed no matching items. The useful question is when the shop last received valid information.
Scheduling also depends on the installation. WordPress documents that its default WP-Cron mechanism is triggered by page loads. Some integrations use different scheduling arrangements. Ask the implementer how yours runs during quiet periods and how a missed job is detected; a configured interval alone does not establish that updates arrive on time.
Choose an integration by the controls you need
Compare tools using your source format, identifiers, product types and exception rules. Check whether the job can update stock without replacing your product copy, images or other fields. Ask where credentials are held and who can access the source, without putting secrets in a public sheet or an enquiry message.
For a documented example, Stock Sync Sheets describes previews, dry runs, logs and manual review of uncertain matches. Check its source requirements against your supplier file, and test the difficult matches before choosing it.
If your supplier sends an occasional file and a person can review it before use, a controlled CSV process may be enough. The catalogue update-method guide compares that route with ordinary bulk editing and an ongoing integration.
Prove the failure response before widening the feed
Pilot a small representative range on a controlled test copy. Include a normal item, a variation, an unknown code, a confirmed zero and a deliberately missing row. Check the proposed changes before allowing a live update.
- Process the same input again and confirm that quantities do not drift.
- Test an inaccessible source and an old file; confirm the agreed hold or warning appears.
- Reject a changed column layout and an ambiguous product match.
- Check a product sold or edited during the update window.
- Confirm that descriptions, images and unrelated products stay intact.
- Test stopping the job and correcting one affected product without replacing later orders.
Keep the expected results with the recorded outcomes. A dry run is useful for seeing a proposed change; it does not prove the entire order and fulfilment process. After a small controlled live release, check the product page, order record and actual supplier ordering route.
Leave someone responsible for exceptions
Name the person who sees failed-run alerts, reviews new codes and checks supplier format changes. Document how to pause updates, which products are affected and how to investigate the last accepted file. A feed needs a maintenance handover as well as an initial setup.
For a WooCommerce project in Formby, Freshfield or L37, send the shop URL and describe the supplier connection you need. Useful starting details include the file format, update frequency, stock ownership and a few anonymised records showing the difficult cases. Keep supplier passwords, access tokens and customer information out of the message.
