Warehouse System Integrations: How a WMS Connects to Your Store, Marketplaces and Carriers
The four connections every warehouse management system needs, how order and inventory data actually moves, and where integrations quietly drift out of sync.
A warehouse management system (WMS) is only as useful as the things it is connected to. On its own it knows where inventory sits and who picked it. It does not know that a customer just checked out, that a marketplace listing needs a new quantity, or that a carrier has quoted a rate. Those facts arrive through integrations — and integrations are where most warehouse software projects actually succeed or fail.
The four connections almost every operation needs
Whatever the channel mix, the same four links keep appearing:
- Sales channels inbound. Orders flow from a storefront or marketplace into the WMS so they can be allocated and picked.
- Inventory outbound. Available quantities flow back out to every channel that is selling the same units.
- Carriers. Rating, label generation, and tracking numbers returned to the order record.
- Finance and inventory of record. Receipts, adjustments and shipments flow to whatever system the business treats as the source of truth for stock and cost.
A fifth link — supplier or freight visibility on the inbound side — is common but not universal.
How the data actually moves
Three mechanisms cover nearly all of it, and the differences matter operationally more than technically.
| Mechanism | How it works | Where it struggles |
|---|---|---|
| Polling | The WMS asks the channel for new orders on a fixed interval | Interval length sets your floor for order latency |
| Webhooks | The channel notifies the WMS when something happens | A missed notification is silent unless something reconciles |
| Batch files | Scheduled file exchange, often EDI or flat files | Failures surface a cycle late, at file granularity |
Most real operations run a mixture: webhooks for order creation, polling as a safety net for anything the webhook dropped, and batch files for retail partners who work that way. The safety net is not redundancy for its own sake. A webhook-only integration will eventually miss an order, and without a reconciliation pass nothing in the system will ever notice.
Where integrations drift
Integrations rarely break loudly. They drift, and the drift is discovered by a customer.
- Inventory feeds that update slower than picking. If several channels sell from one pool and quantities publish on a long cycle, overselling is a matter of timing, not of bad data. Allocation rules and feed frequency, not a bigger buffer, are the real levers.
- A new field appears upstream. A channel adds a gift-message field or a new fulfillment flag; the mapping ignores it; the information never reaches the pack station.
- Status vocabularies diverge. "Fulfilled" in the store and "shipped" in the WMS may not mean the same event. If nobody defines the mapping, reporting quietly disagrees with itself.
- Silent authentication expiry. A token expires, the connection stops, and the only symptom is that no new orders arrived — which looks exactly like a slow day.
- Retry storms. A failing endpoint that is retried aggressively can duplicate orders rather than recover them. Idempotency keys are what prevent that.
Field mapping is most of the work
The connection itself is usually a weekend of work. The mapping is where the weeks go, because it forces decisions nobody wrote down before:
- SKU identity. Does the channel's SKU equal the warehouse SKU, or is there a translation table? Barcodes, listing IDs and internal part numbers are three different things, and treating them as one is the most expensive shortcut in the project.
- Bundles and kits. Does the channel sell a kit as one SKU that the warehouse holds as components? Something has to explode that at order intake.
- Multi-location stock. If inventory sits in more than one building, the feed has to say which quantity is publishable to which channel.
- Shipping method translation. A checkout option named "Express" has to resolve to a specific carrier service code, per channel.
- Cancellations and edits. A customer changing an order after it is downloaded is a normal event, and it needs a defined behaviour before it happens on a live order.
The scan events that keep the physical side honest deserve the same rigour — the scan points on the floor are what make the integrated data mean anything, since an integration is only ever as accurate as the events feeding it.
Testing before go-live
A short list that catches most of what goes wrong:
- Push a real order through end to end, including a label, before migrating anything.
- Test the edge cases deliberately: a cancelled order, an oversell, a partial shipment, a return.
- Break the connection on purpose and confirm you find out — pull the credential and see whether anything alerts.
- Run parallel for a defined period, comparing quantities between systems daily rather than at the end.
- Write down who is called when an integration fails at 6pm, before it does.
Questions worth asking before you sign
Whether the system is hosted or self-managed — a decision covered in cloud versus on-premise WMS — the integration questions are the same. Which connections are prebuilt and which are custom work? Who owns the mapping when a channel changes its API? What happens to queued messages during downtime? Is there a reconciliation report, or only a live feed? And can you see the message log yourself, or do you have to open a ticket to find out why an order never arrived?
An operation that can answer those five questions will survive an integration failure. One that cannot will discover the failure from a customer. If you are working through how a WMS should connect to your channels and carriers, our warehouse technology pages set out how the pieces fit, and the team can look at your specific channel mix.
