how to import wholesaler feeds into woocommerce products and stock

why wholesaler csv feeds keep breaking woocommerce stock

Wholesale suppliers drop overnight CSV or XML files with new prices, pack sizes and stock. Someone downloads the file, opens Excel, fixes decimal commas, and pastes into a WooCommerce import plugin. By mid-morning half the catalogue shows zero stock because a blank quantity column was treated as an update, or a supplier renamed a manufacturer code and every match failed. Shops that sell the same SKU from two wholesalers fight over which feed wins, and the ERP in Comarch Optima or Subiekt still holds a third quantity that purchasing trusts more than the shop. Manual imports also destroy enrichment. Editors spent weeks on PL and EN descriptions, attribute translations and hero images; a full catalogue replace from the wholesaler overwrites titles with ALL CAPS supplier strings and strips categories. Margin rules disappear when the feed ships gross prices and the shop expects net, or the other way around. B2B merchants feel this as sudden price jumps that violate contracts with key accounts who were promised a locked net price list. Failure modes compound under load. A 40,000-row feed imported synchronously through WP-Admin times out, leaves a partial apply, and nobody knows which SKUs committed. Action Scheduler helps only if the job is designed as chunked upserts with a run ID. Without a quarantine table, one malformed EAN can abort the whole batch in stricter importers, or worse, succeed with wrong units so you sell pieces as packs. The business impact shows up as oversells, margin leaks and angry account managers. Support promises next-day dispatch based on green stock in the shop while the wholesaler API already returned zero an hour earlier. Marketing launches a campaign on a SKU whose feed price rose overnight. Finance cannot explain why shop revenue and Optima purchase prices no longer reconcile for the same article code. Automation here is not "run the import plugin on cron". It is a controlled pipeline: fetch, validate, map, apply deltas with buffers, quarantine exceptions, and report. Stock and price updates should be separable from content updates so editorial work survives. When an ERP is the true inventory ledger, the wholesaler feed should update purchasing or the ERP first, then let the shop receive a vetted push - not race the ERP with a parallel CSV paste. Seasonality adds another layer. Before Black Friday a wholesaler may push optimistic stock that evaporates by noon; without caps tied to confirmed purchase orders the shop oversells kits that purchasing never ordered. Conversely, after a container arrival the feed may lag six hours while the warehouse already scanned pallets into Subiekt, so the shop under-sells. The automation must know whether the wholesaler quantity is sellable promise or merely supplier warehouse gossip, and label meta accordingly for support macros. Purchasing should review quarantined rows in a daily stand-up during feed onboarding weeks, then weekly once stable. Photograph or archive sample raw files for each schema version the supplier ships so disputes about column meaning are evidence-based. When lead times stretch past two weeks, raise the safety buffer and tell marketing which SKUs are promise-limited versus on-hand. Operational detail for checksum and truncated file guards: document owners, failure examples, and the metric that proves the control works in production for this WooCommerce automation. Write the runbook step, the alert destination, and the rollback or compensate action so night-shift support can act without guessing. Include the system of record name and the correlation ID field used in logs. Sequence marker en-wholesaler-feed-to-products-stock-pad-1.

when a wholesaler feed drop should update shop catalogue data

Run after the wholesaler posts a new file to SFTP or when their API exposes a `feed.updated` timestamp newer than your last successful run ID. Typical cadence is every one to four hours for stock, nightly for full price lists. Also allow a manual `replay_feed` with a specific file version for incident recovery. Do not trigger on every tiny FTP timestamp flicker without a checksum change, or you will burn API limits rewriting identical rows.

steps to map wholesaler rows into woocommerce products safely

1. Fetch the feed to object storage or a staging disk, compute checksum, and refuse to process if the file is empty, truncated below a row floor, or identical to the last successful checksum.
2. Parse rows with explicit decimal and encoding rules. Normalise supplier SKU, EAN and your internal SKU through the mapping table. Flag unknown SKUs to an onboarding queue instead of auto-creating junk products unless the policy allows controlled creation with a draft status.
3. Validate business rules: max price delta percentage, unit of measure, minimum order quantity, and stock not negative. Apply a safety buffer that keeps shop stock below wholesaler stock when lead times are long.
4. Upsert WooCommerce products in chunks via REST or a privileged internal endpoint: price, stock, backorder flags and purchasing meta only. Skip content fields unless an explicit content-sync flag is set for that supplier.
5. Write a run report: rows ok, quarantined, unknown SKUs, and SKUs that hit the price-delta brake. Notify purchasing when quarantine exceeds a threshold, and store the run ID on updated products for audit.
6. Publish a post-run event so Google Merchant feeds, marketplace stock pushes and low-stock alerts consume the new run ID only after commit, avoiding half-updated catalogue reads.

how ftp api and n8n move wholesaler data into the shop

n8n or a small worker pulls SFTP/API, stores the raw file, and parses into a staging table. Mapping lives in a versioned sheet or database table that product ops owns. WooCommerce updates go through REST with Application Passwords or a custom route that bypasses UI importers, using Action Scheduler inside WordPress only for the final chunked writes if you need shop-side locks. When Comarch Optima or enova owns stock, the feed updates ERP purchasing cards first; the shop listens to ERP deltas instead of applying wholesaler stock directly - that avoids dual-write fights. Make.com can replace n8n for simple single-supplier CSV cases, but complex quarantine and delta brakes are clearer in n8n or custom PHP workers. Never let the wholesaler FTP credentials live in a public plugin option without encryption. Chunk size should match hosting limits: a few hundred REST updates per wave with jitter beats a single giant admin-ajax import. Store per-SKU last feed hash so unchanged rows skip writes and object cache invalidation stays calm. When Google Merchant or marketplace syncs depend on shop stock, sequence those jobs after the feed run ID completes rather than racing mid-apply. For wholesaler feed to products stock, keep run IDs in operator dashboards and page the mapping owner rather than a generic inbox when failure rates spike. Operational detail for decimal comma normalisation rules: document owners, failure examples, and the metric that proves the control works in production for this WooCommerce automation. Write the runbook step, the alert destination, and the rollback or compensate action so night-shift support can act without guessing. Include the system of record name and the correlation ID field used in logs. Sequence marker en-wholesaler-feed-to-products-stock-pad-2.

how to quarantine bad wholesaler rows without wiping stock

If the file fails checksum or row-floor checks, abort the run and keep yesterday's shop stock untouched. Quarantine individual bad rows without failing the whole batch when the error is local (bad price, unknown UOM). If WooCommerce REST returns 429, pause the chunk worker with backoff and resume the same run ID. On partial shop outage, do not mark the run successful: persist cursor offsets so replay continues. Price-delta brakes should require a human approve action before applying outliers, logged with who approved. Alert when more than a set share of rows quarantine, because that usually means the supplier changed columns. For dual-source SKUs, resolve conflicts with an explicit priority list rather than last-write-wins. If mapping table version mismatches the feed header version, fail closed and page purchasing. Rollback is rarely a full catalogue restore; prefer compensating transactions that revert only SKUs touched by the failed run ID using the pre-image snapshot taken at run start.

when a wholesaler feed sync is not worth automating yet

You have fewer than a few hundred SKUs updated weekly and a single supplier who already pushes clean WooCommerce-ready CSV with stable columns. In that case a supervised weekly import may beat building quarantine tooling. Also wait if the supplier replaces the entire schema every month without notice - stabilise the contract first.

kpis for wholesaler feed to woocommerce stock health

• Time from feed checksum to last chunk committed
• Share of rows quarantined per run
• Oversells attributable to stale wholesaler stock
• Count of content fields accidentally overwritten per month