A Shopify 3PL integration is the connection between a Shopify store and a third-party logistics warehouse, and it is made of five handoffs: stock goes in, the order goes out to the warehouse, fulfilment and tracking come back, inventory comes back, and returns come back. It is reliable when every handoff has a trigger, a record on both sides, and a named person who owns the cases that do not go cleanly.
Most of the work is not the connector. It is deciding in advance who resolves a short pick, who answers the customer whose address was wrong, and which system is believed when the two disagree about stock. Sources checked September 2026; every platform behaviour below links to Shopify’s documentation.
This is written for the operations, ecommerce or fulfilment lead moving stock into a third-party warehouse. It is a handoff guide, not a provider comparison: we cite Shopify’s documented behaviour rather than any individual 3PL’s software, and nothing here is a measured client result.
The five handoffs in a Shopify 3PL integration
Shopify models a 3PL as a fulfillment service: an app that provides “third-party warehousing, print on demand, or fulfillment services that prepare and ship orders on behalf of merchants”. When that service is created, Shopify automatically creates a new location for it, and the warehouse’s stock lives there. Orders are assigned to it, requests go to the service that owns it, and the quantity Shopify holds at that location is what the storefront sells against.
| Handoff | Record in Shopify | Trigger | Exception owner to name |
|---|---|---|---|
| Stock in | Incoming then on hand at the 3PL location | The inbound shipment is received and counted | Who reconciles a short or over receipt |
| Order out | Fulfillment order at the 3PL location | A fulfillment request is submitted | Who acts on a rejected request |
| Fulfilment and tracking back | Fulfillment with carrier, tracking number and URL | A package ships | Who chases a shipment with no tracking |
| Inventory back | Quantities at the 3PL location | Scheduled refresh, receipt or adjustment | Who investigates a count difference |
| Returns back | Return, refund and restock | The return arrives and is inspected | Who grades the unit and deselects restock |
Stock in comes first and is the easiest handoff to skip, because it happens once per shipment rather than once per order. Shopify holds the units as incoming, and incoming stock is not sellable until it is received. Confirm how your provider reports a receipt and how fast it appears, then name the person who reconciles a pallet counted short.
Fill this in before anyone writes a statement of work. A row with no named owner will consume your mornings.
Name the owner, not just the direction. An arrow on a diagram is not a decision. Each handoff needs the record it moves, the event that triggers it, and the person called when it fails.
Compare connection options by fit and ownership
Four common options differ less in what they move than in who maintains them when something changes.
- The 3PL’s own Shopify app. The shortest path when the provider’s standard flows cover your orders. Ask which of the five handoffs it supports and how it behaves on order edits.
- A fulfillment service built through the Admin API. A custom app registers the warehouse as a fulfillment service and handles the fulfillment order lifecycle directly. It fits when the warehouse has an API but no Shopify app, or when the published app misses a flow you need.
- An integration platform. Useful when the 3PL is one of several systems in the path, or when orders need transformation or routing before they leave.
- Custom middleware. A service of your own between the two, often because routing, batch files or a second warehouse sit in the path. The most flexible and the least free.
For anything you build yourself, settle who owns the code, the API version upgrades, the alerting and the pager. Rank by fit and by maintenance, then ask any candidate to demonstrate your awkward cases: a rejected request, a short pick, an order edited after it was sent, a cancellation after acceptance, a returned unit that is not sellable. A demo of a new order flowing through tells you almost nothing.
Give every exception an owner before the first order ships
Each case needs two answers: who decides, and where that decision becomes visible to the person who must act on it.
Rejected requests. Once a request is submitted, “the fulfillment service either accepts or declines the fulfillment, and the outcome is noted in the order timeline”. A timeline entry is not an alert. Decide who reads rejections, how often, and what happens to the promised ship date meanwhile.
Cancellations after acceptance. Before acceptance a request can be cancelled. After it, the merchant must send a cancellation request the warehouse can accept or reject, and Shopify states it plainly: “Reverting an order to unfulfilled doesn’t stop your fulfillment service from fulfilling the order”. The same caution adds that the order can still ship and that you will be charged for the product and the fulfillment. Agree a cut-off and tell support what it is. Past that point a cancellation is a recovery conversation, not a click.
Address changes. These arrive after checkout, often after the request has gone out. Shopify documents a mutation that applies a hold to a fulfillment order, and the documented hold reasons include INCORRECT_ADDRESS, AWAITING_PAYMENT, HIGH_RISK_OF_FRAUD and INVENTORY_OUT_OF_STOCK. Confirm whether the provider’s app places and releases holds or your team does, and what a hold means for their pick schedule.
Order edits after export. Shopify allows editing unfulfilled items, but “you can’t remove fulfilled items or adjust their quantity”. The same page warns that “if you edit an order to remove an item, then your fulfillment app might not remove the item”, and that edits can “cause missed or incomplete orders” where a service does not support them. Ask whether edits are honoured, then write your support policy to match.
Partial shipments and short picks. Shopify documents that a fulfillment service “can create multiple fulfillments for a given fulfillment order if required, representing multiple packages to be shipped”, and warns that when “items in an order are fulfilled by different services or shipped in separate packages, then some items might be delivered to your customers before others”. Decide who tells the customer, whether the remainder is held or cancelled, and how a short pick is told apart from a delay. A short pick is also an inventory event.
Split locations. If you also hold stock in your own warehouse, your order routing configuration decides: “If a location has enough inventory to fulfill an entire order, then the order is assigned to that location”. Otherwise the order is split or the highest-priority location oversells. A split means two tracking numbers, possibly two shipping costs and one confused customer, so give routing an owner.
All of these need a queue an operator can see, not a log line. From the customer’s side, a rejection, a refused cancellation and a hold nobody released look identical: a parcel that has not moved.
Treat inventory as a two-way handoff with a discrepancy check
Inventory is the handoff most likely to be reported as broken when it is behaving as configured. Shopify tracks inventory separately for each location, and the 3PL has a location of its own, created with the fulfillment service. The same product can be stocked at your locations and at the 3PL at once, so the warehouse’s count and your own describe different shelves.
Shopify also distinguishes inventory states: on hand is everything at a location, available is what you can sell, committed is set aside for unfulfilled orders, unavailable is held back by apps or for damage and quality control, and incoming is not sellable until received. Ask what your provider’s reported count actually measures. If it is a physical count it is describing on hand, and comparing it to Shopify’s available quantity shows a difference that is not an error.
For a fulfillment service app with inventory management enabled, Shopify documents that “a request for all inventory data happens once every hour to keep Shopify up to date with the remote fulfillment service”, alongside per-SKU requests at setup and on SKU changes. Ask which mechanism your provider uses, then compare both counts at a fixed time each week. Investigate in order: timing, then quantity definitions, then mapping, then a genuinely missed update. Our guide to Shopify inventory sync problems covers that path.
Compare the same state, at the same location, at the same moment. A warehouse’s physical count and Shopify’s available quantity differ for valid reasons. Agree which state you are comparing before anyone calls the difference a bug.
Decide who grades a returned unit and where it restocks
Returns close the loop and are the easiest handoff to leave undefined, because the first one arrives weeks after go-live.
Restocking is not silent. Shopify preselects Restock items on a refund when the items are inventory tracked, so a refund puts units back into sellable stock at the return location unless someone deselects it. Shopify also notes that “if you refund an unfulfilled item, then the item is removed from the order and can’t be fulfilled”. Decide who deselects it, and when.
When the parcel reaches the warehouse, someone decides whether the unit is sellable and who refunds. Restock location in a 3PL flow is a decision to settle with the provider, not a default you inherit. Write that sequence down with names against it.
Prove each handoff before go-live
Acceptance is a list of testable handoffs with a known starting state and an agreed result. Our Shopify ERP integration guide publishes a worksheet pattern these rows adapt to a 3PL. Record the input, the expected result and the records seen on both sides. An untested row stays untested, never a pass.
| Scenario | Acceptance condition to agree |
|---|---|
| First inbound received | The counted quantity appears at the 3PL location, a short or over receipt reaches a named owner, and nothing is sellable before it is received |
| Standard order to the 3PL location | One fulfillment order at the right location, accepted, then fulfilled with tracking the customer can see |
| Rejected fulfillment request | The rejection reaches a named owner and the customer promise is resolved |
| Cancellation after acceptance | The request is sent, the warehouse response recorded, support knows the cut-off |
| Address change before pick | A hold is applied and released, or the agreed manual path works, and the parcel ships corrected |
| Order edited after export | The warehouse reflects the edit or raises an exception, and nothing removed gets shipped |
| Short pick or split shipment | Shipped items and the remainder land in the agreed state, and the customer is told once |
| Split across your warehouse and the 3PL | Routing follows the configured rule and both shipments report tracking |
| Return received and restocked | A sellable unit restocks at the agreed location, a damaged unit has Restock items deselected, and the refund matches policy |
At cutover, name the person watching exceptions daily, the escalation path, and the point this becomes routine support. Re-run affected rows when the provider changes their app, when routing rules change, or when the API version moves.
Shopify 3PL integration questions
How long should we run both the old fulfilment path and the 3PL?
Not in parallel. A second fulfilment path splits inventory across two places and creates the discrepancy you are trying to avoid, so run the acceptance list before the first live order and cut over once. The overlap that matters is human rather than systems: one named person watching the exception queue daily until it is boring.
Who owns the inventory number once a 3PL holds the stock?
The warehouse owns the physical count and Shopify owns what is sellable, so name one reconciliation owner rather than declaring a single source of truth. Compare the same state at the same location weekly, and treat an unexplained gap as an investigation rather than an adjustment.
What happens to an order once the 3PL accepts the fulfillment request?
The fulfillment order moves into progress and the warehouse can create fulfillments against it, adding carrier, tracking number and tracking URL as packages ship. The merchant can no longer simply cancel: a cancellation request has to be sent, and the warehouse can accept or reject it. A hold can be applied to a fulfillment order at any point, but what it does to a request already sitting with the warehouse is provider behaviour, not platform behaviour. Confirm it before you rely on it.
Is Shopify Fulfillment Network a 3PL?
Not today. Shopify does not operate the warehouse. As of September 2026 Shopify presents Fulfillment Network as a way to connect with a third-party logistics partner from the admin, naming partners including Flexport, ShipBob, GoBolt and Amazon Multi-Channel Fulfillment, and its help documentation describes 3PLs that “store your inventory and fulfill orders on your behalf”. The handoffs and exception ownership in this guide apply either way.
Turn the handoff map into an implementation scope
Bring three things into the scoping conversation: the five-handoff table filled in, the exception list with a name on each row, and the acceptance tests you intend to run. Together they show whether the immediate work is configuration, a provider conversation, integration code, or a decision nobody has made yet.
The same ownership questions apply to the back office, where the ERP guide above is the field-level version. If stock numbers already disagree, start with the inventory sync guide. If you are replatforming at the same time, fulfilment cutover belongs in the Shopify migration checklist.
Autonomous helps teams design and implement Shopify integrations and custom apps, including fulfilment handoffs to third-party warehouses. The starting point is the handoffs you need and who owns them.
