How to Integrate a WMS With Shopify Without Overselling

Integrating a WMS with Shopify comes down to two decisions: which system owns each inventory number, and how orders reach the warehouse. Shopify documents both precisely, and most overselling traces back to one of them being left vague. This guide walks through Shopify’s own model first, then the warehouse events that change sellable stock.

In Shopify, every product variant has one inventory item, and an inventory level ties that item to a location such as your store, your warehouse or a 3PL. Each level splits stock into states: available, committed, reserved, damaged, safety stock and quality control make up on hand, and incoming is stock not yet on site. When a customer orders, units move from available to committed; fulfilment releases them. Apps cannot adjust committed stock themselves. The number your storefront sells against is available, so the integration’s job is to keep available honest.

The first pattern is a fulfillment service app. Creating a fulfillment service automatically creates a location in Shopify, and Shopify recommends one service per physical warehouse. Shopify sends fulfillment requests to the service, which accepts or rejects them and then reports fulfilments with tracking. If the service manages inventory, Shopify asks it for stock per SKU when a SKU is set up or changes, and requests all stock once an hour; SKUs are case-sensitive, so they must match exactly.

The second pattern is an inventory app that writes quantities to Shopify. Shopify’s inventory mutations accept a reason for each change, including cycle-count, correction, shrinkage and received, plus a compare-and-swap check and an idempotency key so a retried update does not double-count. Either pattern needs one owner per number: if Shopify and the WMS both adjust available stock for the same location, they will drift.

Shopify can notify a WMS when inventory levels or fulfillment orders change, but it does not guarantee that webhooks arrive, or arrive in order, and it recommends periodic reconciliation jobs and de-duplicating on the webhook ID. Changes to committed, reserved, damaged, safety-stock and quality-control quantities do not fire inventory webhooks at all. Plan a scheduled reconciliation that compares the WMS’s sellable stock with Shopify’s available quantity per location, and investigate differences rather than overwriting them.

Shopify only lets a product keep selling at zero when inventory tracking is on and “Continue selling when out of stock” is enabled for that product or variant. Review that setting for every SKU the warehouse supplies. With several locations, online availability depends on the locations set to fulfil online orders, so a warehouse location left out of that set will not protect the storefront. Shopify also limits locations by plan (two on Starter, ten on Basic, Grow and Advanced, 200 on Plus), although locations created by fulfillment service apps do not count toward the limit.

Receiving, cycle counts, pick exceptions, packing shorts, returns and adjustments all change what can be sold. Each should reach Shopify as a reasoned change, not a silent overwrite: a damaged return belongs in damaged, a unit awaiting inspection in quality control, and a buffer for a volatile SKU in safety stock. Those unavailable states exist so that on-hand stock can stay truthful while available stays conservative.

WarePulse does not ship a native Shopify app. Inventory exports from WarePulse to CSV, and items, locations and opening stock import from CSV, but orders do not move by file: a direct connection scoped during implementation uses one of the patterns above, and orders can also be entered in the portal. Scoping starts from the same questions: which system owns available stock per location, which warehouse events are sent to Shopify and with which reasons, and how the two are reconciled.

Ask each vendor whether it connects as a fulfillment service or writes inventory levels, and which one owns available stock. Ask how it reports damaged, returned and quality-hold units, whether it sends a reason with every change, and how it reconciles missed webhooks. Then test cancelled picks, partial receipts, returns and bundle components on your own SKUs. Strong answers describe the warehouse workflow first and the data exchange second.