Warehouse Management System for 3PL: Setup Guide

A warehouse management system for 3PL fulfilment does not fail at the obvious step. Almost every Shopify team gets the SKU export and the basic Shopify-to-WMS connection working before go-live; what most skip is deciding EDI or API explicitly, mapping every order type the catalogue produces rather than just storefront checkouts, and running a pilot batch that would have caught the gap before it reached a customer. This guide covers all seven steps in the order they have to happen, the worked billing math at a real order volume, and the EDI-or-API decision with the method for pricing it — the parts a “send the 3PL our product list and turn on the integration” approach leaves out.

What Do You Need Before You Set Up a Warehouse Management System for 3PL?

Three things have to exist before the first field gets mapped. The SKU master has to be complete — every active SKU with a barcode, weight, dimensions and, for anything built at pick time, a bill of materials — because a 3PL that receives stock against an incomplete record holds it as unsellable until someone catches the gap by hand. The connection method has to be decided — EDI or API, covered in full below — because it determines the shape of every field mapping that follows it, and choosing it mid-setup means redoing earlier work. And every order type the catalogue actually produces has to be named before mapping starts: storefront checkout, subscription reorder from Recharge or Stay AI, and wholesale or B2B order if the store runs one, because a mapping built only against storefront orders will look correct in testing and still misroute the order type nobody tested.

One prerequisite is often missed because it looks like a formality: confirm which party’s WMS is the system of record for on-hand inventory once fulfilment moves. It is almost always the 3PL’s — Shopify’s own inventory count becomes a downstream mirror of it, updated by whatever sync mechanism Step 5 sets up, not an independent source. Anyone still treating Shopify’s inventory count as authoritative after go-live is looking at a number that lags the warehouse by however long the sync interval runs.

How Do You Set Up a Warehouse Management System for 3PL, Step by Step?

Seven steps, in this order. Skipping the order matters more than skipping any single step, because later steps assume earlier ones are already correct.

Step 1: Build the SKU Master Before You Touch the WMS

Export every active SKU from Shopify’s variant records — the sku, barcode, weight and dimension fields on each variant — and add anything the WMS needs that Shopify does not store natively, most commonly a bill of materials for kitted products. A SKU without a barcode either gets picked manually at a higher error rate or gets a WMS-generated internal barcode assigned during receiving, which is one more reconciliation step than a SKU that arrived with its own. Do this export once, completely, rather than sending an initial batch and patching gaps as they surface — a partial SKU master is the single most common reason a first shipment to a new 3PL sits in receiving longer than quoted.

Step 2: Decide EDI or API Before You Map a Single Field

The connection method is not a preference — it is usually mandated by whoever is on the other end of a given order flow, and which one applies determines the shape of every field mapping that follows. Make this decision explicitly, in writing, before Step 3, because the field names, the update frequency and who owns the mapping work all differ between EDI and API. The full comparison, including who typically requires which, is below.

Step 3: Map Every Order Type to a Fulfilment Profile, Not Just Storefront Checkouts

Order-type mapping is the step most teams get wrong. In outline: every order arriving in Shopify carries tags and a fulfillment_service assignment that determine which warehouse or fulfilment profile it routes to, and a mapping rule written to catch only storefront-standard fields will pass every storefront order and silently misroute or backorder every subscription or wholesale order that does not match those fields.

Step 4: Set the Pick-Ticket Cutoff and Wave Rules

Set a daily order cutoff — the time after which an order ships the next business day rather than the same one — matched against the actual hour your order volume clusters, not a default the 3PL quotes in a sales conversation. A 3PL with a 2pm cutoff that your order volume regularly clears by 1pm delivers same-day pick every day; the same cutoff against an order pattern that peaks at 3pm delivers next-day pick most days, on paper the identical SLA. Set the wave-release rule alongside it — whether pick tickets batch by a time interval, by order count, or release individually — since this is what determines how quickly a picked order actually reaches packing once it clears the cutoff.

Step 5: Set the Inventory Sync Trigger

Confirm whether the 3PL’s WMS pushes stock updates by webhook as each pick happens, or reports on a polling interval the integration checks periodically. A webhook-driven sync narrows the window between a physical pick and Shopify’s inventory count reflecting it to close to zero; a polling interval leaves a gap the width of that interval during which a SKU can oversell, because Shopify still shows it available after the WMS has already committed it to a pick. Set the interval as short as the connection supports if webhooks are not available, and treat “we sync inventory” as an incomplete answer until the mechanism and the interval are both named.

Step 6: Schedule Cycle Counts by SKU Velocity

Set a recurring cycle-count schedule rather than relying on an annual full count, and weight it toward the SKUs that move fastest — a fast-moving SKU accumulates a discrepancy faster than a slow-moving one, so counting both on the same schedule under-checks the SKUs where an error costs the most in stockouts or overselling. This is a WMS configuration decision, not just an operating practice: most platforms support velocity-based count scheduling directly, and setting it up during initial configuration means the count cadence is enforced by the system rather than remembered by a person.

Step 7: Run a Pilot Batch That Includes Every Order Type Before Full Cutover

Route a real, defined batch of orders through the new WMS setup before switching all volume over — enough orders, across every order type named in the prerequisites, that a mapping error shows up on the pilot instead of on live volume. A pilot that only includes storefront checkouts validates Steps 1, 2, 4 and 5 and tells you nothing about whether order-type mapping actually works, which is exactly the gap that produces a support ticket in week two of a “successful” cutover.

What Does 3PL Warehouse Billing Actually Look Like at 3,000 Orders a Month?

No 3PL, WMS vendor or aggregator publishes a representative all-in rate — every rate card is negotiated, and the figures that circulate in round-ups trace back to each other rather than to a measured population of contracts. What is published, consistently, is the shape of the bill: storage, receiving, pick-and-pack and accessorial charges as separate line items, a structure Extensiv’s own published guidance on 3PL pricing describes without attaching dollar figures to any of the four (vendor-reported). The method that works is building the arithmetic yourself against one specimen order profile, pricing storage, receiving, pick-and-pack and accessorial charges separately with invented rates rather than accepting a single benchmark number.

The rates in this table are invented, for illustration only, and every figure in it is recomputed from those rates — none of it is a published or measured number.

At this invented set of rates, $7,855 across 3,000 orders works out to $2.62 per order — a figure that looks close to the pick-and-pack line alone ($2.10) but is about 25% higher once storage, receiving and kitting are added in, which is the whole point of pricing the four lines separately rather than quoting the pick-and-pack fee as if it were the total.

The actual per-order figure for a specific SKU mix and order volume is — metric to confirm. Price it by sending at least three 3PLs the same specimen order profile — the real top-20 SKUs by order frequency, the real weight and dimension distribution, the real monthly order count — and asking each to quote the four lines above separately, plus any monthly minimum commitment that applies below a stated volume. A quote that states only the pick-and-pack figure has not stated the cost.

EDI or API: How Deep Does the Shopify-to-3PL WMS Integration Actually Go?

EDI and API differ in when data moves and who owns the mapping, not just in the acronym. EDI exchanges structured documents — an 850 purchase order, an 855 acknowledgment, a 940 warehouse shipping order sent to the 3PL, a 945 warehouse shipping advice sent back once it ships, and often an 856 advance ship notice — in batches, on a schedule or triggered by an event, usually over an AS2 or VAN connection (ANSI ASC X12 transaction set standard). An API integration exchanges the same information as near-real-time calls: an order-paid event fires from Shopify, a call creates the order in the 3PL’s system, and a webhook or a polling call reports the pick and the inventory change back. ShipBob’s own description of the choice states it plainly: EDI compliance exists because large retailers, distributors and other trading partners still require it, while API access is the faster, more direct path for a 3PL serving storefront orders (ShipBob, vendor-reported).

Both rows in the last line are genuinely unpublished for the same reason the per-order 3PL billing figure is unpublished: implementation time depends on how many trading partners’ EDI specifications a 3PL already has mapped, how much of the SKU master is clean before the project starts, and whether wholesale or B2B order types add a third mapping on top of storefront and subscription — variables specific enough to a brand’s own catalogue that a generic weeks-and-cost figure would not describe any real project accurately. Get a comparable answer by asking each candidate 3PL for the same three things, broken out separately: the hours or weeks for SKU and catalogue mapping, whether any EDI trading-partner setup is needed beyond what the 3PL already has built, and the test-order volume they require before agreeing to go live. A quote that only states a single total-weeks figure has not answered any of the three, and cannot be compared against a second 3PL’s quote that has.

Which Step Do Most Teams Get Wrong When Setting Up a Warehouse Management System for 3PL?

Order-type mapping (Step 3) is the step most teams get wrong, and it fails silently: a rule that was never built to recognise a subscription or wholesale order’s tags does not error when one arrives, it just misroutes the order or backorders it against a default, and nobody finds out until a customer emails about an order that never shipped.

A brand with no subscription programme and no wholesale channel does not carry this exposure. A brand running Recharge, Stay AI or Shopify’s B2B channel alongside a standard checkout does — and the fix is not a smarter default rule, it is testing the Step 7 pilot batch against a real instance of every order type the catalogue produces, not just storefront volume.

How Do You Verify the Warehouse Management System Setup Is Actually Working?

Verification is not “did the first order ship correctly” — a single successful order proves the happy path, not the mapping. Four checks confirm the setup is holding up rather than looking correct on a small sample. First, reconcile a full day’s Shopify order export against the WMS’s pick-ticket log, order by order, confirming every order type generated a pick ticket and none silently dropped. Second, compare Shopify’s on-hand inventory count against the WMS’s own count for a sample of SKUs spanning fast- and slow-moving stock, since an inventory-sync-trigger problem shows up as drift on the SKUs that move fastest first. Third, confirm the pick-ticket cutoff and wave-release rule against actual ship timestamps for a week of orders, not against the SLA the 3PL quoted — an SLA measures the 3PL’s median performance, not what a specific order pattern actually produces. Fourth, and specific to the order-type failure mode above, pull every subscription and wholesale order from that same week and confirm each one shipped through the correct fulfilment profile rather than the default.

Order-type misrouting, inventory drift and cutoff mismatches are not warehouse problems once the 3PL is chosen and the WMS is configured — they are systems problems, and they stay systems problems for as long as the integration runs, not just during setup week. A capable 3PL will hit its own service-level agreement on the orders its WMS was built to recognise; the exposure sits in the order types nobody mapped and the sync gaps nobody is watching for, and both get worse, not better, as order volume grows past what a person can spot-check by eye. That is the class of problem we build reconciliation and order-routing checks for as part of ops automation — a scheduled process that reads both the 3PL’s warehouse management system and Shopify and raises the orders and SKUs where they disagree, instead of waiting for a support ticket to raise them first. It is also usually one of the first systems worth building for brands scaling past their first ops hire, the point at which nobody has spare attention left to watch two warehouse feeds by hand — a problem the 3PL fulfilment definition and the 3PL warehouse definition both point to from the concept side; this is the setup work that follows once the decision to move is made.