WMS Integration: Connecting a Warehouse Management System to Your Store, ERP, and Carriers

The four connections a WMS has to make

A warehouse management system sits in the middle of an operation, not at the end of it. Four connection types cover almost every mid-market ecommerce stack.

Sales channels and marketplaces

On the storefront side: Shopify and Shopify Plus, Magento and Adobe Commerce, BigCommerce, Shopware, WooCommerce. On the marketplace side: Amazon in both FBM and FBA models, eBay, and Walmart Marketplace. Orders come down, inventory and tracking go back up. This is the connection merchants think of first, and the one with the most edge cases.

ERP and accounting

QuickBooks Online and Desktop, Sage 100, and enterprise ERP systems. Orders, invoices, and inventory adjustments move between the two systems so the financial record and the physical record describe the same warehouse.

Shipping carriers

FedEx, UPS, USPS, DHL, plus regional and international services. These connect directly with your own carrier accounts or through an aggregator such as EasyPost. The point of the connection is not just label printing. It is rate shopping against the rates you have actually negotiated, and pushing the tracking number back to the order.

Everything else, through the API

Vendor and supplier systems, analytics tools, CRM, internal dashboards, and the one homegrown application every operation has. These do not get pre-built connectors from anybody. They get built against a documented API, which is why API depth matters more than connector count.

Sync direction is the decision that shapes everything else

Two questions come up in nearly every warehouse management system integration conversation, almost word for word. One merchant asked: as we add a product into Shopify, will it automatically add that product into the WMS? Another asked the reverse: if inventory changes in Magento, does that sync back down?

Both questions are really one question. For every object that exists in two systems, something has to be the master, and the other side has to be a subscriber. Answer it object by object before anyone writes code.

Which system owns inventory

In most ecommerce operations the WMS becomes the master once receiving, picking, and cycle counting happen there. The channel becomes a subscriber that gets told what it may sell. The failure mode is letting both sides write. A cycle count marks three units missing, the WMS writes the corrected number to the channel, and the channel also decrements on its own order flow. Now the number is wrong in a way nobody can trace.

Magento is the clearest example of why this matters. The platform decrements its own inventory when an order is placed, so the integration has to override the storefront number rather than add to it. Getting that one rule backwards produces slow, silent drift that only shows up as oversells during peak.

Which system owns the order

The order is created in the channel. From the moment the WMS accepts it, the WMS is the system of record for state: allocated, picked, packed, shipped, cancelled, short. Those states write back to the channel so the customer-facing status and the warehouse reality agree. If the channel keeps editing an order after the WMS has allocated it, define exactly which edits are allowed and which are rejected.

Which system owns the product record

Catalog usually starts in the ecommerce platform or the ERP. Decide whether a new SKU is created in the WMS at the moment it is created in the channel, or at the moment its first order arrives. Both work. Choosing neither is what produces order lines that cannot be matched to a product.

What has to push back

• On-hand quantity, ideally with the location behind it rather than one blended number.
• Shipment confirmation with carrier, service, and tracking number.
• Cancellations and short-ships, so refunds are triggered from a real warehouse event.
• Receiving updates, so backordered items release the moment stock lands.

WMS and ERP integration

The most common integration question in mid-market ecommerce is how a WMS should sit next to an ERP. The split is cleaner than most vendors make it sound.

The ERP keeps the financial and commercial record: purchasing, costs, invoices, the general ledger. The WMS keeps the physical record: locations and bins, receipts, allocations, picks, packs, cartons, and the labor around them. Three things cross the line between them, and only three: orders, invoices, and inventory adjustments.

Many operations keep the ERP they already run and replace the warehouse module inside it, because ERP warehouse modules are usually built for a stockroom rather than an ecommerce fulfillment floor. That is a legitimate architecture, not a compromise, as long as the adjustment path is defined.

Three questions worth asking any vendor about ERP integration:

• Do inventory adjustments made in the warehouse write back to the ERP automatically, or does someone re-key them?
• At what granularity does inventory sync: SKU only, or SKU plus location?
• What happens to warehouse work when the ERP is unreachable? An integration that blocks picking during an ERP outage is a warehouse that stops.

Deeper reading on that pairing: seven things to know about pairing an ERP with a WMS.

Marketplace, EDI, and carrier connections

These three get grouped together because they are the connections merchants discover late, usually after the storefront integration is already live.

Marketplaces need inventory staged per channel rather than a single pooled number, or one busy marketplace will consume stock the others already promised. Amazon adds a wrinkle: FBA stock is physically somewhere else, so it is handled as a separate warehouse location rather than as part of your own on-hand.

EDI is a different animal from an API. Big-box trading partners exchange documents on their schedule and to their spec, with chargebacks attached to getting it wrong. SPS Commerce is the common path for that compliance layer, and the documents map to the same warehouse events an API connection would carry. More on that in making big box retailers accessible with EDI.

Carriers connect either directly or through an aggregator. Whichever route you take, the integration has to carry your negotiated rates, or rate shopping just picks the cheapest published rate rather than the cheapest rate you can actually buy. Service rules by destination type and channel belong in the integration, not in a packer's memory.

How deep the API has to go

Connector counts are a weak signal. Every platform has a logo wall. The question that separates them is what happens when you need something that is not on the wall.

One buyer evaluating platforms described the pattern he kept hitting: most vendors do not expose real data endpoints, and when pushed, they offer direct database access instead. That is not an API. It is a liability with a login.

A usable integration surface has four properties:

• Read and write parity. Every object you can see in the interface can be read and written through the API, not just a curated subset.
• Documentation you can work from. A RESTful API with full Swagger documentation lets a developer build against it without a support ticket for every field.
• Events, not polling. Webhook subscriptions fire when something happens. Scheduled batch syncs create a window between the sale and the update, and that window is where oversells live.
• Somewhere safe to test. Development, staging, and production environments, mapped to the matching environments on your ecommerce platform, so integration changes are proven before they touch live orders.

Ask for the API documentation during evaluation, not after signature. It is the fastest available read on how a vendor thinks about customers who need something specific.

Where WMS integrations break after go-live

Integrations rarely fail on launch day. They fail three weeks later, on a Tuesday, in ways that look like warehouse problems. These are the recurring ones.

• SKU identity. The channel SKU, the internal item code, the supplier part number, and the UPC are four different strings for one product. Every unmatched order line traces back to this.
• Partial writes. The order lands but allocation fails, so it sits in an accepted state that nothing picks up. Someone has to be told, and there has to be a queue where these land.
• Buffers set in two places. A safety buffer configured in both the channel and the WMS applies twice, and you quietly stop selling stock you have.
• Kits and bundles. The channel sells a bundle, the warehouse holds components. Decide which side does the math, because if both do, availability is wrong in both.
• Reversals. Cancellations, refunds, and returns need a defined path back through every system that was told about the original sale. This is the most commonly skipped part of an integration scope.
• Multi-location blending. Sending one blended availability number to a channel hides which building actually holds the unit, which breaks routing and delivery promises. Multi-location order management depends on the location surviving the sync.
• Peak rate limits. Channel APIs throttle. An integration that works at 300 orders a day and queues silently at 3,000 is a Black Friday incident waiting to be scheduled.

How SkuNexus approaches WMS integration

SkuNexus is an inventory, order, and warehouse platform for mid-market ecommerce operations that have outgrown off-the-shelf tools but cannot justify an enterprise WMS. Integration is not a module bolted to the side of it. The warehouse and inventory functions, order management, and pick, pack, and ship all read from the same records the integrations write to, which removes an entire class of sync bug that exists only because two products had to agree.

Three things are worth knowing if you are evaluating the fit:

• Native connections to the major ecommerce platforms, marketplaces, carriers, and accounting systems are configured during onboarding rather than bought as add-ons. The integrations ecosystem page lists what ships in the box.
• The connections were built in-house by a team that came out of enterprise ecommerce development work on Magento, Shopify, and BigCommerce, rather than resold from a third-party connector marketplace. That matters mostly when something breaks and the fix has to come from the same people who wrote it.
• Everything else runs on a RESTful API with Swagger documentation and webhook subscriptions. Sync rules, field mappings, and the direction of each object are configuration, not a feature request on somebody's roadmap.

The practical version: when a merchant asks whether we can connect to a system nobody has heard of, the answer does not depend on whether it is popular enough to have earned a connector.

Three integrations that went live

Graeter's Ice Cream

A family-owned craft ice cream producer in Cincinnati with over 50 locations and nationwide grocery distribution. As ecommerce grew, manual order processing caused delays and errors, inventory visibility across multiple warehouses was limited, and dry ice packing decisions were made by hand. SkuNexus integrated with their existing Magento storefront and automated order routing, packing, and shipping, with real-time inventory tracking across all warehouses. The result was 100% order automation and enough processing speed to handle over 550,000 pints annually, up from 270,000.

Carewell

An ecommerce retailer of home health products running a zero-inventory dropshipping model. Inconsistent vendor and dropshipper communication caused delays, and manual processes hurt order accuracy. SkuNexus integrated directly with their BigCommerce platform for real-time data flow, automated purchase order generation for dropship orders, and centralized vendor communication. Carewell has since secured $30MM in venture capital funding and ranked #74 on Inc.'s 2021 5000 Fastest-Growing Private Companies in America.

New Look Vision Group

Canada's largest eyewear retailer, with over 477 locations. Manual fulfillment created bottlenecks, and complex data exchange between Magento 2 and other systems added delays. SkuNexus automated their pick, pack, and ship processes, integrated with Magento 2 and Canada Post, and delivered training and documentation for staff. The implementation was completed in nine months.

Sequencing an integration project

The order of operations matters more than the timeline. This sequence keeps the expensive discoveries early.

1. Inventory the systems, then the objects. List every system that touches an order or a unit. For each shared object, write down the master and the subscriber. This document is the integration spec.
2. Reconcile identifiers first. Before any connection is built, agree on the field that identifies a product across systems and fix the records that do not carry it.
3. Connect one channel, in a test environment. Not the biggest one. The one with the most representative order types.
4. Run both systems in parallel. Real orders flowing through the new path and the old one, compared daily, until the differences are explainable.
5. Write the exception paths. Unmatched SKU, failed allocation, carrier rate failure, channel timeout. Each needs a queue and a named owner before go-live, not after the first incident.
6. Cut over by channel, then by warehouse. Phased, with the ability to roll a single channel back without touching the others.
7. Watch the reconciliation for a full cycle. Compare channel availability against warehouse on-hand daily through at least one replenishment cycle. Drift shows up in that comparison before it shows up in a customer complaint.

FAQs

What is WMS integration?

WMS integration is the process of connecting a warehouse management system to the other systems that create or consume warehouse data, most commonly an ecommerce platform, marketplaces, an ERP or accounting system, and shipping carriers. A working integration is bidirectional: orders and product data flow into the WMS, and inventory counts, shipment confirmations, and tracking data flow back out.

What are the first steps in planning a WMS integration?

List every system that touches an order or a unit of inventory, then go object by object and decide which system is the master for products, inventory, orders, and shipments. Reconcile product identifiers across those systems before any code is written. Only then evaluate tools, because the mastership decisions determine which integration capabilities you actually need.

How do I choose the right WMS for integration with my existing ERP?

Check three things. Whether inventory adjustments made in the warehouse write back to the ERP without re-keying. Whether inventory syncs at SKU plus location granularity or only at SKU level. And whether warehouse operations continue when the ERP is unreachable. Ask to see the API documentation during evaluation rather than after signing.

What are the signs that my current WMS integration isn't effective?

Recurring oversells, order lines that cannot be matched to a product, staff re-keying data between systems, availability numbers that disagree between the channel and the warehouse, and integrations that need manual restarts. Each of those traces back to a mastership or identifier problem rather than to a warehouse process problem.

How can small to medium businesses benefit from WMS integration?

The gain is mostly in removed handoffs. Orders stop being exported and imported, inventory stops being reconciled by hand, and tracking numbers stop being pasted between systems. For an operation without a dedicated systems team, that recovered time is usually worth more than any single feature in the software.

See it against your own stack

The useful version of this conversation is specific: your platform, your marketplaces, your ERP, your carrier accounts, and the one system nobody has a connector for. Book a demo and we will walk the integration path for the stack you actually run, including which side should own inventory and where your current setup is likely to drift.