What the integration actually does
Three things cross the connection, and only one of them is the one people think about.
Orders go out. Paid Shopify orders are pushed to ShipBob for picking, packing and shipping, subject to whatever sync rules you set.
Inventory comes back. ShipBob writes on-hand quantities into a Shopify location that represents the warehouse. This is a scheduled sync, not a live feed.
Fulfilments come back — and that is the part that matters. When a shipment leaves, ShipBob writes a fulfilment with a tracking number onto the Shopify order. That write is what triggers Shopify’s shipping confirmation email and Klaviyo’s fulfilment event.
Which means this is not really a warehouse integration. It is the thing that drives your customer notifications, and it is doing that on behalf of a system your marketing team cannot see. Almost every problem below follows from that.
For a brand billing on a schedule there is a fourth characteristic worth naming up front: your order volume is not smooth. Renewal days produce a spike that no browsing customer created, and a 3PL integration that is comfortable on a Tuesday can behave very differently on the day a few thousand subscriptions bill at once.
Before you start
- Decide the inventory model first. Which Shopify location represents the warehouse, and which products it stocks. Multi-location Shopify plus a 3PL is where most of the pain in this integration originates, and it is far cheaper to decide than to unwind.
- Export your variant list with SKUs. You are going to need to prove that every variant has a SKU, that no SKU is duplicated across variants, and that every one of them has a counterpart on the warehouse side.
- List every bundle, variety pack and subscription box you sell, with its components and quantities. This is the kit list, and it is the single most common cause of a stuck order in week one.
Setting it up, step by step
- Fix the catalogue before you connect anything. Every variant needs a SKU. No SKU may appear on two variants. Blank and duplicated SKUs are the two failures that surface immediately, and they are much easier to fix before orders are flowing than after.
- Connect the store. Install the ShipBob channel, authorise it against your Shopify store, and select the Shopify location that represents the warehouse. Screen names to confirm against the current ShipBob app
- Register kits on the warehouse side. A bundle that exists only as a Shopify product arrives at the warehouse as a SKU nobody can pick. Every kit needs its component SKUs and quantities registered with the 3PL, separately from however you model it in Shopify.
- Set the order sync rules. Which orders are eligible (paid only; exclude local pickup, pre-orders, wholesale tags), and what hold window applies before an order is released to the floor. The hold window is a customer-service decision as much as a logistics one — it is the only time in which an address correction or a subscriber’s edit can still land.
- Turn on inventory sync, and decide whether Shopify may oversell. Review the “continue selling when out of stock” setting per variant rather than globally. For anything the 3PL fulfils, the answer is almost always no.
- Run one real order end to end. Not a test order that skips payment — a real one. Then watch what comes back: the fulfilment, the tracking number, and every email and event that write triggers.
- Re-check your shipping flows against the fulfilment shape you actually get. If the test order came back as one fulfilment, order something that will split and watch what happens to the notifications. That is failure three below, and it is better to find it now.
The three things that break
The warehouse cannot pick a bundle that only exists in Shopify
- Symptom
- Orders sit unfulfilled against an unrecognised SKU, or ship with a component missing. Component inventory looks wrong afterwards and nobody can reconstruct why. It shows up first on a new variety pack, usually during a promotion.
- Cause
- Bundles, variety packs and subscription boxes are commonly modelled in Shopify as a single product with its own SKU. The warehouse holds component SKUs on the shelf. Unless that bundle is registered as a kit with its exact component list and quantities on the 3PL side, the mapping simply does not exist — and the failure surfaces at the pick face, not at the point of sale.
- Fix
- Register every kit at the 3PL with its exact components, and make the kit definition a release step rather than an afterthought — when marketing launches a new pack, the kit is on the launch checklist next to the product page. Then run a standing audit for Shopify variants whose SKU has no counterpart in the warehouse, and run it before every promotion rather than after. If the catalogue changes faster than the 3PL configuration can keep up, that is the argument for exploding kits into components in middleware before the order is ever sent.
Inventory reads high, and you oversell on the day it matters
- Symptom
- A promotion sells units you do not have. The counts drift back into line a few hours later, which makes it look like a display bug rather than a real oversell. Support spends the next day cancelling and apologising.
- Cause
- Inventory sync is periodic and per-location, not instantaneous and global. If a variant is stocked at more than one location, or “continue selling when out of stock” is on, or another app also writes to that variant, then the number Shopify shows is a composite that no single system owns. Subscription renewals make it sharper: a renewal batch can consume real stock in minutes without a single person browsing the site.
- Fix
- One location per SKU wherever the business allows it. Continue-selling off for anything the 3PL fulfils. A buffer on fast-moving SKUs so the sync interval has somewhere to be wrong safely. Then reconcile on a schedule — a daily job comparing warehouse on-hand against Shopify’s per-location count, alerting on drift past a threshold, catches this before a promotion does. And forecast the renewal spike against stock rather than discovering it: the upcoming-charge queue tells you seven days ahead what the pick demand will be.
One order becomes three shipments, and the customer gets three emails
- Symptom
- Customers report several shipping notifications for one order. The Klaviyo fulfilment flow fires repeatedly against the same person. WISMO tickets rise while nothing is actually wrong with the shipment.
- Cause
- Split fulfilment is normal, not an error: items picked from different bins, shipped from different fulfilment centres, or one line held while the rest goes. Each shipment writes a separate fulfilment onto the Shopify order, and each fulfilment independently triggers Shopify’s shipping confirmation and Klaviyo’s fulfilment event. Nothing has failed — the notification layer simply has no concept of “the second parcel of the same order”.
- Fix
- Choose deliberately which system sends the shipping notification and switch the other off. Then build the flow to treat shipments differently: a full-detail message on the first fulfilment of an order, and a short “the rest of your order is on its way” on subsequent ones, keyed off the fulfilment count rather than the event alone. If the splits are being caused by the catalogue rather than the warehouse — a bundle whose components live in different facilities — fix the catalogue, because no amount of email logic makes three parcels feel like one.
What syncs, and what doesn’t
| Data | Direction | Notes |
|---|---|---|
| Paid orders | Shopify → ShipBob | Subject to your sync rules and hold window |
| Order edits and cancellations | Limited | Once an order is released to the floor, treat it as final |
| Inventory on hand | ShipBob → Shopify | Per location, on a schedule — never treat it as live |
| Fulfilment and tracking | ShipBob → Shopify | One per shipment; each one triggers customer notifications |
| Kit and bundle definitions | Not synced | Maintained at the warehouse, by hand, forever |
| Lot codes and expiry dates | Not in Shopify | Matters for anything with a shelf life; lives only in the 3PL |
| Returns | Depends on setup | Usually handled by a returns app writing to Shopify, not through this connection |
| Customer address and contact | Shopify → ShipBob | For the label; treat it as a PII transfer in your privacy documentation |
| Renewal forecast | Neither | The 3PL cannot see your upcoming charge queue unless you send it |
Behaviour differs by 3PL and by app version, and several of these are configurable rather than fixed. Confirm each row against your own account before you rely on it. Sync behaviour to confirm per account
Advanced: when the native integration isn’t enough
Native 3PL connectors are built for a merchant with a flat catalogue and a smooth order curve. A brand at $3M–$30M running bundles, a renewal schedule and more than one sales channel has neither. Four things we build in between.
A middleware layer that owns the order shape. A self-hosted n8n instance receives Shopify’s order webhook, applies the rules the connector has no opinion about — kit explosion, hold windows for subscribers who can still edit, gift notes, batching on renewal days — and posts a clean order to the 3PL’s API. The point is that a catalogue change stops requiring a 3PL configuration change.
Reconciliation and drift alerting. A nightly comparison of warehouse on-hand against Shopify’s per-location counts, plus a standing report of SKUs with no warehouse counterpart. Both failures above are silent; a schedule is the only thing that finds them early.
Renewal forecasting into the warehouse. Read the upcoming charge queue, project pick demand seven days out, and put it in front of the 3PL and the buyer before it lands. This is the highest-value thing most subscription brands are not doing, and it costs a scheduled workflow.
A single owner for customer notifications. One service decides which fulfilment gets which message, so the split-shipment problem is solved once rather than approximated in three settings screens.
All of it is built in your own accounts and documented. Ops automation is the service; the audit is how you find out which of the four you actually need, with hours and dollars attached.
If you are choosing the automation layer to build this on, n8n vs Zapier covers why per-execution billing matters once every renewal is an order.