3PL · INTEGRATIONS · OPERATIONS · 17 JUNE 2025 · 8 MIN READ
Connecting a WMS when you already have a 3PL
Your 3PL already runs a warehouse management system. Buying a second one rarely fixes the problem you have, which is almost always that nobody agreed who owns the stock number.
Usually not. A 3PL already operates a warehouse management system — that is what you are paying for — and buying your own is only worth it when you hold stock somewhere they do not: your own warehouse, retail stock rooms, a second 3PL in another market, or a made-to-order workshop. The problem most merchants are actually trying to solve is that Shopify, the 3PL portal and the finance system each show a different number. That is an inventory ownership problem, and a second WMS makes it a three-way disagreement instead of a two-way one.
IN SHORT
- A 3PL runs its own WMS; buying yours duplicates it unless you hold inventory the 3PL never touches.
- The real requirement behind most "we need a WMS" conversations is a single system that owns inventory truth across every location and channel.
- On Shopify, a 3PL integration registers as a fulfilment service and gets its own location, which is what makes per-location stock and fulfilment order routing work.
- Shopify tracks inventory in distinct states — available, committed, on hand, incoming, reserved, damaged, safety stock, quality control — and the Admin API cannot adjust the committed state, because orders own it.
- Write inventory as authoritative on-hand values from the system that counts the shelf, not as deltas from whatever sent the last message.
- You need a WMS when stock moves inside your own four walls in ways no one else records. Otherwise you need a better integration.
Three different things people call a WMS
Most of the confusion is vocabulary, and it is worth ten minutes before it is worth a budget.
A WMS runs a building. Receiving, putaway, bin locations, pick paths, packing stations, cycle counts, and the handheld scanners the pickers hold. It is about where a unit physically is and who touched it. If nobody in your organisation walks past a shelf, you almost certainly do not need one.
A 3PL portal is your window onto someone else's WMS. It shows you their stock figures and lets you raise inbound shipments. It is not an integration, and treating it as one — someone exporting a CSV on Tuesdays — is the root cause of a surprising share of the incidents we get called about.
An inventory or order management system sits above both. It holds the single record of what stock exists across every location and channel, decides which location fulfils which order, and pushes sellable quantities out to Shopify, Amazon, eBay and the trade site. This is the thing most merchants are describing when they say "we need a WMS", and it is a different purchase.
When a WMS is genuinely right
The test is simple: does stock move in a place you control, in ways nobody else is recording? If yes, you need something recording it.
- You run your own warehouse alongside the 3PL — commonly the slow-moving or bulky lines it is not economic to store with them.
- Retail stores or a trade counter hold sellable stock, and someone needs to know what is in the back room.
- You assemble, personalise, kit or repair. Components arrive as one SKU and leave as another, and the transformation happens on your premises.
- Two or more 3PLs, often one per market, and neither will ever be the master record of the other's stock.
- Regulatory traceability — batch, lot or serial numbers you must be able to trace on demand.
And when it is the wrong purchase
The pattern we see most often: a merchant on one 3PL, with Shopify showing wrong stock figures, gets quoted for a WMS. Six figures, a year, and a change programme in a building they do not own. Almost always, the actual faults are these.
The sync is one-directional or batched. Stock is pushed to Shopify every few hours, or overnight, so the store oversells during peak and nobody can explain it. The fix is event-driven updates in both directions, not new software.
Two systems both believe they own the number. The 3PL sets stock, then an ERP sets it back, and they alternate all day. Nothing will fix this except deciding which one wins, per location, and making the other one read-only.
Adjustments are sent as deltas. "Reduce by three" applied twice is a store short six units. Authoritative on-hand quantities per SKU per location are replayable; deltas are not.
Nothing reconciles. There is no daily comparison of what the 3PL thinks it holds against what Shopify shows, so errors accumulate silently until someone counts. A nightly reconciliation report is a day's work and finds every one of these.
None of those four is a WMS-shaped problem. Do them first; if the numbers still disagree afterwards, now you have evidence for a bigger purchase rather than a hunch.
How Shopify models this, and why it matters
Whatever you buy, it has to meet Shopify's model, and the model is more capable than most integrations use.
Locations and fulfilment services. When a fulfilment service app is created, Shopify automatically creates a location for it. That is the mechanism by which your 3PL becomes a real place in Shopify rather than a label — stock is held against that location, and fulfilment orders are routed and assigned to it. Merchants request fulfilment, the service queries its assigned fulfilment orders, and accepts or rejects them; cancellation requests work the same way in reverse.
The fulfilment order model is the current one. Shopify moved integrations onto FulfillmentOrder objects and deprecated the older order-and-fulfilment approach several API versions ago. If a prospective 3PL's integration still talks in terms of fulfilments on the order, ask them what API version they are on before you sign anything.
Inventory states are not just a number. Shopify tracks quantities as available, committed, incoming, on_hand, and the unavailable subsets reserved, damaged, safety_stock and quality_control. on_hand is the physical total; available is what can be sold. Crucially, the Admin API cannot adjust or move quantities in the committed state — Shopify owns that, through orders and reservations.
That last point is the one that catches integrators. If your WMS tries to make Shopify's available quantity match its own count by writing available directly, it will fight with committed stock every time an order is placed mid-sync. Write on_hand from the system that counts the shelf and let Shopify derive what is sellable.
Designing the integration so it can be audited
The difference between an integration that survives Black Friday and one that does not is rarely sophistication. It is whether you can answer "why is this SKU showing four?" a week later.
- One owner per location. Write it down. For each Shopify location, exactly one system sets quantities and every other system reads. Ambiguity here is the single most common root cause.
- Absolute quantities, not deltas. Send on-hand per SKU per location. A message that arrives twice is then harmless, which matters because at some point one will.
- Use `referenceDocumentUri`. Shopify's inventory mutations accept one, and it gives you a trail back from a quantity change to the purchase order, count or 3PL message that caused it. Populate it; nobody ever regrets this.
- Reconcile nightly. A full comparison of 3PL stock against Shopify stock, with a report of every SKU that differs by more than a threshold. Send it to a person, not a log file.
- Handle the backlog. When the 3PL is unreachable for two hours, messages queue and then arrive at once, possibly out of order. Absolute quantities with timestamps make that a non-event; anything else makes it an incident.
- Keep safety stock in one place. A buffer applied by the WMS and again by the middleware is a buffer applied twice, and you will not notice until a line is unsellable with forty units on the shelf.
What we would ask before quoting either
Five questions. They take an afternoon and they have redirected more of these projects than any technical assessment we have done.
- Which system, today, is right when Shopify and the 3PL disagree — and does everyone give the same answer?
- How often does stock move, and how stale is the figure in Shopify at its worst? An hourly batch is a different problem from a nightly one.
- How many locations will hold sellable stock in two years, including stores and any second market?
- Does anything physically happen to inventory on premises you control?
- Who runs the daily reconciliation now, and what do they do when it disagrees?
The honest recommendation
If you have one 3PL and no stock of your own, do not buy a WMS. Spend a fraction of it on an event-driven two-way integration with a single declared owner, absolute quantities and a nightly reconciliation, and the symptoms that prompted the conversation usually disappear.
If you are running a 3PL plus your own warehouse plus three retail stores, you have a genuine multi-node problem, and the right first purchase is still probably not a WMS — it is the inventory management layer that decides what is sellable and which node ships it. The WMS comes later, and only for the building you actually run.
The expensive mistake is not choosing the wrong system. It is buying a system to settle an argument about who owns the stock number, because software does not settle that argument. People do, and then the software enforces it.
Questions this raises
Do you need a WMS if you use a 3PL?
Usually not. The 3PL already runs one, and that is part of what you pay for. A WMS earns its cost when stock moves in a place you control — your own warehouse, retail back rooms, or an assembly and personalisation operation. If your only complaint is that Shopify's stock figures are wrong, that is an integration problem, not a missing WMS.
What is the difference between a WMS and an inventory management system?
A WMS runs a building: bins, pick paths, scanners, cycle counts. An inventory or order management system sits above every location and decides what is sellable and which location fulfils an order. Most merchants asking for a WMS are describing the second one.
How does a 3PL connect to Shopify?
Through a fulfilment service app. Shopify automatically creates a location for the service, stock is held against that location, and fulfilment orders are assigned to it. The app queries its assigned fulfilment orders and accepts or rejects requests, including cancellations. Integrations should be on the `FulfillmentOrder` model — the older order-based approach has been deprecated for several API versions.
Why does Shopify show different stock from our 3PL?
Almost always one of four causes: the sync is batched rather than event-driven, two systems both write the same location, adjustments are sent as deltas that get applied twice or lost, or nothing reconciles the two nightly. Fix those in that order before buying anything.
Should an integration write available or on-hand quantities?
On-hand, from the system that physically counts. Shopify tracks `available`, `committed`, `on_hand`, `incoming` and unavailable states separately, and the Admin API cannot adjust the `committed` state because orders own it. Writing available directly puts your integration in a fight with every order placed mid-sync.
How do you keep an inventory integration auditable?
Declare one writing system per location, send absolute quantities with timestamps rather than deltas, populate `referenceDocumentUri` on every inventory mutation so a change traces back to its cause, and run a nightly reconciliation that reports differences to a person.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.