Syncing a wholesaler's API into WooCommerce without overselling or melting the server

A common WooCommerce brief looks like this: the store does not own its inventory. A distributor does. The shop is a storefront on top of a wholesaler whose catalog, stock levels, and prices change daily, exposed through some REST or XML web service. The job is to make the store reflect the supplier's reality automatically, and to never sell something the supplier cannot ship.

We shipped exactly this for an automotive-parts store recently (client and supplier stay anonymous). Tens of thousands of indexes, a wholesaler REST API, and a hard requirement: no manual catalog work, and no orders for parts that are not actually in stock. Here is what the architecture looks like and the traps worth knowing before you start.

The store is a view, the wholesaler is the source of truth

The first mental shift is that WooCommerce is not the system of record for products. The distributor is. WooCommerce is a cache with a checkout attached. Once you accept that, the design falls out: a sync layer pulls from the supplier and writes into WooCommerce on a schedule, and you treat the WooCommerce product data as derived, not authored.

The integration answers three questions, and you should answer them explicitly before writing code:

• What syncs - catalog, attributes, media, stock, price.
• Which direction - here it is one-way (supplier to store); orders stay in WooCommerce.
• How often - split it. Stock and price are cheap and change constantly, so poll them frequently. Full catalog and media are expensive, so refresh them rarely.

Map fields declaratively, or you will rewrite it every month

The supplier describes a product its way (its own index, EAN, attribute names, HTML description blobs, image URLs). WooCommerce wants its way (product, attributes, variations, media library). The bridge between them is a field map, and the single best decision we made was keeping that map declarative - a data structure, not a pile of if statements. When the wholesaler adds a new attribute, you extend the map; you do not touch the sync logic. EAN and the supplier index become the stable keys that let each cycle find "the same product" again instead of creating duplicates.

Stock protection is the whole point, so make it boring

The expensive failure mode is selling a part the supplier does not have. So the stock rule is deliberately dumb: every cycle, if the supplier says an index is unavailable, the product is hidden or set to out-of-stock in WooCommerce. When availability returns, so does the product. No cleverness, no "probably still has some." The customer literally cannot add an unfulfillable item to the cart, because it is not purchasable when the supplier is dry.

Price is cost plus rules, computed at write time

Wholesaler prices are cost, not what you sell at. Above the pull layer sits margin logic: the supplier's net price comes in, the store's margin rule is applied, and only the result is written to WooCommerce as the product price. The owner steers profitability by editing rules, not by touching thousands of prices by hand. When the supplier's price list moves, the next cycle recomputes and the store stays profitable without anyone noticing.

The part everyone underestimates: not melting the server

Tens of thousands of products times "poll often" is how you take down a shared-hosting WooCommerce site. A few things that mattered:

• Do not do it in WP-Cron on page loads. Drive the sync from real scheduled tasks (system cron hitting WP-CLI, or Action Scheduler) so a burst of traffic does not trigger a burst of syncs, and a sync does not block a customer's request.
• Batch and paginate. Pull and write in chunks; never load the whole catalog into memory.
• Split the cadences. Stock/price on a short interval, full catalog/media on a long one. Most of your cycles should be small and cheap.
• Be idempotent. A cycle that dies halfway must be safe to re-run. Keying on EAN/index makes that free.
• Watch autoload and wp_postmeta. Large catalogs bloat both; a sync that writes sloppily to postmeta will quietly wreck query performance long before anyone blames the sync.

When this pattern generalizes

The interesting bit is that "wholesaler REST API" is not special. Swap the source for an ERP (Comarch, Dynamics, NetSuite, whatever exposes an API) and the shape is identical: pull, map, protect stock, compute price, schedule sanely, stay idempotent. The data source changes; the discipline does not. That is why we treat wholesaler-feed and ERP integrations as the same class of problem.

Written by WPPoland. We build WooCommerce ERP and wholesale-API integrations for stores that outgrew manual catalog work. Also on GitHub: a read-only WooCommerce MCP server for giving AI agents safe read access to a store.