← All posts Insights 3 min read

WooCommerce Order Routing with NetSuite: Multi-Warehouse Logic That Actually Works

Multi-warehouse order routing is where WooCommerce + NetSuite integrations graduate from straightforward to architecturally complex. The routing logic itself — ship from the closest warehouse with available stock — sounds simple. The edge cases, NetSuite’s location model, and WooCommerce’s limited native routing support make the implementation significantly more involved. How NetSuite Models Multi-Location Inventory NetSuite…

Multi-warehouse order routing is where WooCommerce + NetSuite integrations graduate from straightforward to architecturally complex. The routing logic itself — ship from the closest warehouse with available stock — sounds simple. The edge cases, NetSuite’s location model, and WooCommerce’s limited native routing support make the implementation significantly more involved.

How NetSuite Models Multi-Location Inventory

NetSuite uses Locations as the primary organizational unit for inventory. Items have quantity on hand, committed, and available at each location. The integration needs to know not just total available quantity but available quantity by location to make routing decisions.

SuiteQL queries against the InventoryBalance records return per-location availability efficiently. The challenge is latency: querying availability at checkout adds API round-trip time to the customer experience. The standard mitigation is a cached inventory availability layer that syncs from NetSuite on a schedule (every 5–15 minutes for most use cases) and serves the routing logic without hitting NetSuite in real time.

Routing Logic Design Decisions

Before writing routing code, document the business rules explicitly:

  • Primary routing criterion: closest warehouse, lowest shipping cost, or specific warehouse assignment by customer?
  • Split shipment policy: can a single order ship from multiple locations, or must all items come from one location?
  • Fallback behavior: if the preferred location has insufficient stock, fall back to the next closest, or hold the order for review?
  • Pre-order behavior: if no location has stock, can the order be accepted and fulfilled when stock arrives, and which location receives the backorder?

These decisions have significant implications for both the routing logic and the NetSuite transaction structure. A split shipment requires multiple Item Fulfillment records in NetSuite, each from a different location. An order held for review needs a status in both WooCommerce and NetSuite that is visible to the operations team.

The NetSuite Fulfillment Side

Once a routing decision is made, the integration creates a NetSuite Sales Order with the assigned location. NetSuite’s fulfillment workflow then handles pick/pack/ship, and the resulting Item Fulfillment records — including tracking numbers — flow back to WooCommerce to update order status and trigger customer notifications.

The fulfillment-to-WooCommerce sync is often implemented as a webhook from a NetSuite Workflow Action or a scheduled SuiteScript that polls for newly created fulfillment records. The webhook approach is lower latency; the scheduled approach is more tolerant of temporary WooCommerce unavailability.

Testing Multi-Warehouse Routing

Test the edge cases before go-live: zero stock at all locations, sufficient total stock but no single location with enough to fulfill the order, a routing decision that changes between cart and checkout because another order depleted stock in the interim. The last scenario — race conditions in inventory reservation — is the most common source of post-launch incidents in multi-warehouse implementations. Address it explicitly in your design rather than discovering it when two customers simultaneously order the last unit from the same location.


Ship it

Need this in your stack?

We build, integrate, and ship — no calls, just delivery.

Start a project →