Shopify + WMS Integration Challenges

A Shopify order placed at 2pm should trigger warehouse picking within minutes. When the integration between Shopify and a warehouse management system fails, that order sits in a queue unprocessed, the warehouse picks nothing, and the customer receives no tracking information. The merchant discovers the problem when the customer emails two days later asking where their order is.

Shopify WMS integration connects Shopify’s order management layer to the operational systems that physically fulfill those orders. It is one of the highest-stakes integration categories in e-commerce because failures are not invisible data quality problems. They are missing shipments, incorrect stock counts, and customers who do not receive what they paid for.

This guide covers the eight most common WMS challenges in production Shopify integrations: the root causes that make each problem recur, the architectural patterns that resolve each permanently, and the implementation-level code for the critical components. It also covers the specific challenges of Shopify fulfillment integration patterns including multi-location routing, partial fulfillment reconciliation, and split order handling.

What Is Shopify WMS Integration?

Shopify WMS integration is the bidirectional data connection between Shopify’s order and inventory management layer and a warehouse management system that controls physical inventory storage, picking, packing, and shipping operations.

Data flows in two directions. From Shopify to the WMS: new orders requiring fulfillment, order cancellations and edits, return requests, and inventory allocation changes. From the WMS to Shopify: fulfillment confirmations with tracking numbers, inventory level updates reflecting physical stock movements, and return receipts acknowledging received merchandise.

The fundamental tension in warehouse management Shopify integrations is latency versus accuracy. Order data must reach the WMS fast enough for warehouse operations to begin picking before the customer’s expected ship date. Inventory data must return to Shopify accurately enough to prevent overselling. Optimizing one without the other creates either operational delays or customer-facing stock errors.

The fault-tolerant Shopify integration architecture principles that apply across all Shopify integrations apply with heightened urgency in WMS contexts because downstream failures directly block physical operations that cannot be automatically retried by code alone.

Shopify WMS Integration Challenge Reference

The eight challenges below account for the majority of production failures in Shopify WMS integration deployments. Each has a specific root cause, a predictable impact pattern, and a resolution architecture.

The remainder of this guide addresses each challenge in detail, starting with the ones that cause the most severe operational impact.

Challenge 1: Order Duplication in WMS

Order duplication is the most operationally damaging failure in Shopify WMS integration. When the same order is submitted to the WMS twice, the warehouse may pick and ship two separate fulfillments for a single customer order, consuming double the inventory and generating a carrier billing event for a shipment the customer never requested.

Root Cause: At-Least-Once Webhook Delivery

Shopify guarantees at-least-once webhook delivery. Under normal operating conditions, a single orders/create webhook is delivered once. Under retry conditions — your endpoint returned a non-200 response, a network timeout occurred, or Shopify’s delivery system retried due to an internal condition — the same webhook payload is delivered multiple times. Without idempotency controls in the integration middleware, each delivery triggers a separate WMS order submission.

Resolution: Idempotency Key at Submission

// Order submission to WMS with idempotency guard
// Prevents duplicate WMS orders from at-least-once webhook delivery
async function submitOrderToWMS(shop, shopifyOrder) {
const idempotencyKey = `wms:order:${shop}:${shopifyOrder.id}`;
// Atomic NX: only one worker can claim this order
const acquired = await redis.set(
idempotencyKey, JSON.stringify({ submittedAt: Date.now() }),
{ NX: true, EX: 86400 * 7 }  // 7-day window covers all retry scenarios
);
if (!acquired) {
// Already submitted: return stored WMS order ID for tracking
const existing = await redis.get(idempotencyKey);
return { status: 'duplicate', ...JSON.parse(existing) };
}
try {
const wmsOrder = await wmsClient.createOrder({
externalOrderId: shopifyOrder.id.toString(),
externalRef:     shopifyOrder.name,
lineItems:       mapLineItemsToWMS(shopifyOrder.line_items),
shippingAddress: mapAddressToWMS(shopifyOrder.shipping_address),
shippingMethod:  mapShippingMethodToWMS(shopifyOrder.shipping_lines),
});
// Update idempotency record with WMS order ID
await redis.set(
idempotencyKey,
JSON.stringify({ submittedAt: Date.now(), wmsOrderId: wmsOrder.id }),
{ EX: 86400 * 7 }
);
return { status: 'submitted', wmsOrderId: wmsOrder.id };
} catch (err) {
// Release idempotency key on failure so retry can proceed
await redis.del(idempotencyKey);
throw err;
}
}

The 7-day idempotency window covers Shopify’s full webhook retry schedule, which can span multiple days for endpoints that experience extended outages. Releasing the key on failure ensures retries proceed correctly rather than being blocked by a failed submission that holds the key permanently.

For the complete async webhook ingestion architecture that prevents synchronous blocking in the order submission path, the queue-based Shopify webhook processing guide covers the full ingestion-to-delivery pipeline.

Challenge 2: Inventory Desync Between WMS and Shopify

Inventory desync is the most persistent source of customer-facing errors in warehouse management Shopify integrations. Shopify displays quantity available based on its own inventory records. The WMS controls physical stock. When these diverge, Shopify accepts orders for items the warehouse cannot fulfill, or conversely, shows zero stock for items that are physically available.

Root Cause: Full Refresh Sync at Low Frequency

Most initial WMS integration implementations sync inventory by querying the WMS for all current stock levels and pushing them to Shopify on a cron schedule. At hourly frequency, this means Shopify’s inventory can be up to 60 minutes stale at any point. During high-velocity sales events, 60 minutes of stale inventory is sufficient to oversell hundreds of units.

Resolution: Event-Driven Inventory Push with Watermark Delta

Replace full refresh sync with a two-tier approach. The primary tier uses WMS inventory movement events — picking confirmations, receiving events, adjustment postings — to push inventory changes to Shopify within seconds of each warehouse operation. The secondary tier runs a watermark-based delta sync every 15 minutes as a reconciliation pass to catch any events the primary tier missed.

// WMS inventory event handler: push changes to Shopify in near real-time
// Called by WMS webhook or event stream when inventory moves
async function handleWMSInventoryEvent(event) {
const {
wmsItemCode,
warehouseId,
availableQuantity,
eventType,   // 'pick_confirm' | 'receive' | 'adjustment' | 'transfer'
eventId,
} = event;
// Idempotency: skip if this event was already processed
const eventKey = `wms:inv:event:${eventId}`;
const isNew = await redis.set(eventKey, '1', { NX: true, EX: 86400 });
if (!isNew) return { status: 'duplicate_event' };
// Resolve WMS item code to Shopify inventory item ID
const mapping = await db.query(
'SELECT shopify_inventory_item_id, shopify_location_id FROM wms_sku_map WHERE wms_item_code = $1 AND warehouse_id = $2',
[wmsItemCode, warehouseId]
);
if (!mapping.rows.length) {
await logUnmappedWMSItem(wmsItemCode, warehouseId, eventType);
return { status: 'unmapped_sku' };
}
const { shopify_inventory_item_id, shopify_location_id } = mapping.rows[0];
// Push updated inventory level to Shopify
await shopifyAdmin.post('/inventory_levels/set.json', {
inventory_item_id: shopify_inventory_item_id,
location_id:       shopify_location_id,
available:         availableQuantity,
});
return { status: 'synced', shopify_inventory_item_id, availableQuantity };
}

The event-level idempotency check prevents a WMS system that retries event delivery from pushing the same inventory update twice. A double-push of an inventory level is idempotent (setting 50 twice leaves 50), but a double-push of an inventory adjustment (setting -10 twice deducts 20) is not. Using the WMS event ID as the idempotency key prevents both patterns.

Challenge 3: SKU and Item Code Mismatch

SKU mismatch is the most common WMS challenge in initial integration deployments. Shopify identifies products by variant ID and SKU. WMS systems identify inventory items by internal item codes, warehouse part numbers, or UPC barcodes that follow entirely different naming conventions. An order line item with a SKU that has no WMS mapping cannot be fulfilled. The order sits in a pending state and no warehouse operator has any visibility into why.

Building and Maintaining the SKU Cross-Reference Table

The SKU cross-reference table is the foundation of every reliable Shopify WMS integration. It must be built before go-live, validated against live order data, and maintained in response to every product change in either system.

-- SKU cross-reference table schema
-- Maps Shopify variant identifiers to WMS item codes
CREATE TABLE wms_sku_map (
id                        SERIAL PRIMARY KEY,
shop                      VARCHAR(255) NOT NULL,
shopify_variant_id        BIGINT       NOT NULL,
shopify_sku               VARCHAR(255),
shopify_inventory_item_id BIGINT       NOT NULL,
wms_item_code             VARCHAR(255) NOT NULL,
warehouse_id              VARCHAR(100) NOT NULL,
shopify_location_id       BIGINT       NOT NULL,
is_active                 BOOLEAN      DEFAULT TRUE,
last_verified_at          TIMESTAMPTZ,
created_at                TIMESTAMPTZ  DEFAULT NOW(),
updated_at                TIMESTAMPTZ  DEFAULT NOW(),
UNIQUE (shop, shopify_variant_id, warehouse_id)
);
-- Index for high-frequency WMS item code lookups
CREATE INDEX idx_wms_sku_map_item_code
ON wms_sku_map (wms_item_code, warehouse_id);
-- Index for Shopify variant lookups during order submission
CREATE INDEX idx_wms_sku_map_variant
ON wms_sku_map (shop, shopify_variant_id);

Subscribe to Shopify’s products/update and variants/update webhooks to detect SKU changes in Shopify. When a SKU changes, mark the corresponding cross-reference entry as requiring re-verification and alert the operations team. A SKU change in Shopify that is not reflected in the WMS cross-reference table renders all future orders for that variant unfulfillable until the mapping is corrected.

Every order submission to the WMS must validate that all line item SKUs have active cross-reference entries before the order is sent. An order with one unmapped SKU should fail the entire submission with a clear error message — not silently drop the unmapped line item and submit a partial order that the warehouse fulfills incorrectly.

Challenge 4: Multi-Location Warehouse Routing

Merchants operating multiple warehouses face a routing problem that Shopify does not solve natively. Shopify tracks inventory per location but does not determine which warehouse should fulfill a given order. That decision requires business logic: proximity to the shipping address, available stock per location, fulfillment capacity constraints, and shipping cost optimization rules.

Location Routing Rules Engine

Implement a location routing rules engine in the integration middleware that evaluates each order against a priority-ordered set of routing rules and assigns it to the correct warehouse location before submission to the WMS.

// Multi-location warehouse routing engine
// Evaluates order against routing rules to select fulfillment location
async function routeOrderToWarehouse(shop, shopifyOrder) {
const shippingCountry = shopifyOrder.shipping_address?.country_code;
const shippingState   = shopifyOrder.shipping_address?.province_code;
const lineItems       = shopifyOrder.line_items;
// Fetch all active warehouse locations for this shop
const locations = await db.query(
'SELECT * FROM warehouse_locations WHERE shop = $1 AND is_active = TRUE ORDER BY priority ASC',
[shop]
);
for (const location of locations.rows) {
// Rule 1: Geographic restriction
if (location.serves_countries?.length > 0) {
if (!location.serves_countries.includes(shippingCountry)) continue;
}
// Rule 2: All line items must have sufficient stock at this location
const hasStock = await checkAllItemsInStock(shop, lineItems, location.id);
if (!hasStock) continue;
// Rule 3: Location capacity (not paused for maintenance, not over capacity)
const isAvailable = await checkLocationCapacity(location.id);
if (!isAvailable) continue;
// This location passes all rules — assign the order
return {
locationId:    location.id,
warehouseCode: location.wms_warehouse_code,
locationName:  location.name,
};
}
// No location can fulfill: alert operations for manual intervention
await alertOpsTeam('No warehouse can fulfill order', {
shopifyOrderId: shopifyOrder.id,
orderName:      shopifyOrder.name,
shop,
shippingCountry,
});
throw new Error(`No eligible warehouse for order ${shopifyOrder.name}`);
}
async function checkAllItemsInStock(shop, lineItems, locationId) {
for (const item of lineItems) {
const stock = await db.query(
`SELECT available FROM inventory_cache
WHERE shop = $1 AND shopify_variant_id = $2 AND location_id = $3`,
[shop, item.variant_id, locationId]
);
if (!stock.rows.length || stock.rows[0].available < item.quantity) return false;
}
return true;
}

The routing engine checks an inventory_cache table in the middleware database rather than calling the Shopify API for each routing decision. This cache is kept current by the inventory sync from the WMS, reducing API calls and routing latency. Routing decisions that require a live API call add hundreds of milliseconds and consume API rate limit budget on every order.

For merchants with complex routing logic including shipping cost optimization across carriers, integrate carrier rate shopping into the routing rules engine. The Shopify load balancing patterns for distributing work across multiple infrastructure components apply directly to warehouse routing: treat each warehouse as a processing node and route based on current load and capacity, not just inventory availability.

Challenge 5: Partial Fulfillment and Split Order Handling

Partial fulfillment occurs when the WMS ships a subset of an order’s line items, either because some items are out of stock at the warehouse, because items ship from different warehouse zones with different lead times, or because the WMS splits the order into multiple shipments for carrier optimization reasons.

Shopify’s fulfillment model supports partial fulfillment natively: the fulfillments API allows creating fulfillment records for a subset of line items on an order. The challenge is mapping the WMS’s fulfillment events — which may arrive as multiple shipment confirmations over hours or days — to Shopify’s fulfillment records correctly without creating duplicate fulfillment records or missing line items.

Fulfillment Callback Processing

// Process WMS fulfillment callback: creates Shopify fulfillment for shipped items
// Handles both full and partial fulfillment scenarios
async function processWMSFulfillmentCallback(wmsCallback) {
const {
wmsOrderId,
wmsShipmentId,
shippedItems,      // Array of { wmsItemCode, quantityShipped }
trackingNumber,
carrierCode,
shippedAt,
} = wmsCallback;
// Prevent duplicate fulfillment creation for same WMS shipment
const fulfillmentKey = `wms:fulfillment:${wmsShipmentId}`;
const isNew = await redis.set(fulfillmentKey, '1', { NX: true, EX: 86400 * 30 });
if (!isNew) return { status: 'duplicate_shipment' };
// Look up Shopify order ID from WMS order ID
const orderMap = await db.query(
'SELECT shopify_order_id, shop FROM wms_order_map WHERE wms_order_id = $1',
[wmsOrderId]
);
if (!orderMap.rows.length) throw new Error(`No Shopify order for WMS order ${wmsOrderId}`);
const { shopify_order_id, shop } = orderMap.rows[0];
// Map WMS item codes to Shopify line item IDs
const lineItemIds = await Promise.all(
shippedItems.map(async (item) => {
const map = await db.query(
`SELECT li.shopify_line_item_id FROM wms_sku_map m
JOIN order_line_items li ON li.shopify_variant_id = m.shopify_variant_id
WHERE m.wms_item_code = $1 AND li.shopify_order_id = $2`,
[item.wmsItemCode, shopify_order_id]
);
return map.rows[0]
? { id: map.rows[0].shopify_line_item_id, quantity: item.quantityShipped }
: null;
})
);
const validLineItems = lineItemIds.filter(Boolean);
// Create Shopify fulfillment for shipped line items only
await shopifyAdmin.post(`/orders/${shopify_order_id}/fulfillments.json`, {
fulfillment: {
location_id:      await getShopifyLocationId(shop, wmsCallback.warehouseId),
tracking_number:  trackingNumber,
tracking_company: mapCarrierToShopify(carrierCode),
line_items:       validLineItems,
notify_customer:  true,
}
});
return { status: 'fulfilled', trackingNumber, lineItemCount: validLineItems.length };
}

The 30-day idempotency window on fulfillment callbacks is deliberately longer than the order submission window because WMS shipment events can arrive days after the initial fulfillment trigger, especially for orders involving international freight or multi-warehouse consolidation before final shipment.

Challenge 6: Order Cancellation and Edit Handling

Order cancellations and edits introduce a race condition in Shopify WMS integration. A customer cancels an order in Shopify at the same moment the warehouse begins picking it. Shopify fires a orders/cancelled webhook. The WMS, already processing the pick task, may have items staged for packing. The integration must communicate the cancellation to the WMS and handle the case where cancellation arrives after physical work has already begun.

Cancellation State Machine

Model the order cancellation workflow as an explicit state machine with four states:

• Cancellable: order not yet received by WMS or confirmed in pick queue. Cancel immediately via WMS cancel API.
• In-progress: order acknowledged by WMS, pick task active. Request cancellation from WMS; WMS confirms if pick not yet started or declines if in progress.
• Uncancellable: WMS has completed pick and order is in packing or shipping. Cannot cancel. Trigger return label workflow instead.
• Cancelled: WMS confirmed cancellation. Inventory released back to available stock. Shopify order marked cancelled.

// Order cancellation handler with WMS state awareness
async function handleOrderCancellation(shop, shopifyOrderId) {
// Look up current WMS order state
const wmsOrder = await db.query(
'SELECT wms_order_id, wms_status FROM wms_order_map WHERE shopify_order_id = $1 AND shop = $2',
[shopifyOrderId, shop]
);
if (!wmsOrder.rows.length) {
// Order never reached WMS — nothing to cancel
return { status: 'not_sent_to_wms' };
}
const { wms_order_id, wms_status } = wmsOrder.rows[0];
if (['shipped', 'manifested'].includes(wms_status)) {
// Too late to cancel: initiate return workflow
await initiateReturnWorkflow(shop, shopifyOrderId, wms_order_id);
return { status: 'return_initiated', reason: 'already_shipped' };
}
try {
// Attempt WMS cancellation
const result = await wmsClient.cancelOrder(wms_order_id);
if (result.cancelled) {
await db.query(
'UPDATE wms_order_map SET wms_status = $1, updated_at = NOW() WHERE wms_order_id = $2',
['cancelled', wms_order_id]
);
return { status: 'cancelled' };
}
// WMS declined cancellation (pick in progress)
await alertOpsTeam('WMS cancellation declined — manual intervention required', {
shopifyOrderId, wms_order_id, wms_status
});
return { status: 'cancellation_declined', wmsStatus: wms_status };
} catch (err) {
await alertOpsTeam('WMS cancellation error', { shopifyOrderId, error: err.message });
throw err;
}
}

Challenge 7: Fulfillment API Rate Limits Under High Order Volume

Shopify’s REST API enforces a 2 requests per second rate limit per app per store, with a 40-request burst. During high-volume order periods — flash sales, product launches, promotional campaigns — the integration must submit hundreds of orders to the WMS and process hundreds of fulfillment callbacks simultaneously, all against the same rate limit budget.

Rate-Limit-Aware Fulfillment Processing

Implement per-shop rate limit tracking using the X-Shopify-Shop-Api-Call-Limit response header, and queue Shopify API calls with a token bucket approach that respects the 2 RPS sustained rate while taking advantage of burst capacity during low-utilization periods.

// Rate-limit-aware Shopify fulfillment API client
// Tracks per-shop bucket credits and throttles before exhaustion
class ShopifyFulfillmentClient {
constructor(shop, accessToken, redis) {
this.shop        = shop;
this.accessToken = accessToken;
this.redis       = redis;
this.rateLimitKey = `shopify:rate_limit:${shop}`;
}
async request(method, path, body = null) {
// Check cached remaining credits before making request
const cached = await this.redis.get(this.rateLimitKey);
if (cached && parseInt(cached) <= 3) {
// Bucket nearly empty: wait 500ms per missing credit
const wait = (4 - parseInt(cached)) * 500;
await new Promise(r => setTimeout(r, wait));
}
const response = await fetch(
`https://${this.shop}/admin/api/2025-04${path}`,
{
method,
headers: {
'X-Shopify-Access-Token': this.accessToken,
'Content-Type': 'application/json',
},
body: body ? JSON.stringify(body) : undefined,
}
);
// Update bucket tracking from response header
const limit = response.headers.get('X-Shopify-Shop-Api-Call-Limit');
if (limit) {
const [used, total] = limit.split('/').map(Number);
await this.redis.set(this.rateLimitKey, total - used, { EX: 10 });
}
if (response.status === 429) {
const retryAfter = parseFloat(response.headers.get('Retry-After') || '2');
await new Promise(r => setTimeout(r, retryAfter * 1000));
return this.request(method, path, body);
}
if (!response.ok) throw new Error(`Shopify API ${response.status}: ${path}`);
return response.json();
}
}

For the complete rate limit management architecture including GraphQL cost tracking and multi-worker coordination patterns, the Shopify API rate limit handling guide covers every rate limit scenario that high-volume WMS integrations encounter.

Observability and Monitoring for Shopify WMS Integration

WMS integration failures cause operational disruptions that are often reported by warehouse operators or customers before they appear in system logs. A comprehensive observability layer must surface integration health proactively, giving operations teams visibility into the integration’s state before failures escalate to missed shipments.

Critical WMS Integration Metrics

• Order submission lag: the time between an orders/create webhook receipt and the corresponding WMS order submission confirmation. Alert when median lag exceeds 2 minutes or any order exceeds 10 minutes.
• Unmapped SKU rate: the percentage of order line items that fail SKU cross-reference lookup. Any value above 0% requires immediate investigation. An unmapped SKU is an unfulfillable order line.
• WMS API error rate by error type: track transient errors (rate limits, timeouts) separately from permanent errors (invalid data, rejected orders). Persistent permanent errors indicate a field mapping or business rule problem.
• Inventory sync lag: the age of the most recent inventory update per SKU per location. Alert when any actively sold SKU has not been synced within twice the configured sync interval.
• Fulfillment callback processing time: the time between WMS shipment event emission and Shopify fulfillment record creation. Tracking numbers that arrive in the WMS but take hours to appear in Shopify degrade customer experience.
• Dead-letter queue depth: each DLQ message represents an order or inventory event that failed all retry attempts. Any non-zero DLQ depth on the order submission queue is a potential missed fulfillment.

Build a WMS integration health dashboard that surfaces all six metrics in a single view, with thresholds configured to alert the operations team rather than only the engineering team. Warehouse managers and operations directors are often the first people who can take action on WMS integration failures, and they need visibility without requiring access to technical monitoring tools.

Pair WMS integration monitoring with Shopify technical mistakes observability patterns to ensure your monitoring stack covers both the integration layer and the underlying Shopify platform behavior that drives integration events.

Conclusion

Shopify WMS integration failures are operational failures, not just data quality problems. A missed order submission, an inventory desync, or a failed fulfillment callback directly affects a customer’s physical delivery experience. The three most critical implementation decisions that prevent the majority of production failures are:

1. Implement idempotency on every WMS submission and fulfillment callback. Use a Redis NX check with the Shopify order ID or WMS shipment ID as the key. Release the key on failure. Set a 7-day window for order submissions and a 30-day window for fulfillment callbacks. These two controls eliminate order duplication and duplicate fulfillment records — the two most operationally damaging failure modes in WMS integration.
2. Build and validate the SKU cross-reference table before go-live, and maintain it actively after. Subscribe to products/update and variants/update webhooks. Alert on every SKU change that affects an active cross-reference mapping. Validate all line item SKUs against the cross-reference table before every order submission. An order with one unmapped SKU should fail loudly, not silently submit a partial order.
3. Replace full inventory refresh sync with event-driven push from WMS inventory movements. A 60-minute sync interval is insufficient for any merchant operating at meaningful volume. WMS inventory movement events — picks, receives, adjustments — should push inventory updates to Shopify within seconds. Run a watermark-based delta sync every 15 minutes as a reconciliation pass, not as the primary sync mechanism.

Start every WMS integration engagement by building the SKU cross-reference table, defining the warehouse routing rules, and specifying the idempotency key strategy before writing any integration code. These three artifacts determine the correctness of the integration before a single API call is made. Review the async Shopify architecture patterns to ensure the event pipeline delivering orders and inventory updates handles retries, deduplication, and dead-letter routing correctly under the high-volume conditions that WMS integrations regularly encounter.

Frequently Asked Questions

What is Shopify WMS integration?

Shopify WMS integration is the bidirectional data connection between Shopify’s order and inventory management layer and a warehouse management system that controls physical inventory storage, picking, packing, and shipping operations. Data flows from Shopify to the WMS for order fulfillment requests and cancellations, and from the WMS to Shopify for fulfillment confirmations with tracking numbers, inventory level updates, and return receipts.

How do you prevent duplicate orders being sent to a WMS from Shopify?

Prevent duplicate WMS order submissions by implementing an idempotency key check before every submission. Use a Redis SET NX command with a key combining the shop domain and Shopify order ID. Only the worker that successfully sets the key submits the order to the WMS. Release the key on failure so that retries can proceed. Use a 7-day expiry window to cover Shopify’s full webhook retry schedule. This prevents duplicate WMS orders from Shopify’s at-least-once webhook delivery guarantee.

What causes inventory desync between Shopify and a WMS?

Inventory desync between Shopify and a WMS most commonly occurs when the integration relies on full inventory refresh sync at low frequency. A 60-minute sync interval means Shopify’s inventory can be up to 60 minutes stale, sufficient to oversell hundreds of units during high-velocity sales events. The resolution is event-driven inventory push from WMS inventory movements such as pick confirmations, receiving events, and adjustments, which update Shopify within seconds of each warehouse operation.

How do you handle partial fulfillment in Shopify WMS integration?

Handle partial fulfillment by mapping each WMS shipment event to a Shopify fulfillment record covering only the line items included in that shipment. Shopify’s fulfillments API supports creating multiple fulfillment records for a single order, each covering a subset of line items. Use the WMS shipment ID as an idempotency key to prevent duplicate fulfillment creation when the WMS retries callback delivery. Set a 30-day idempotency window to cover delayed shipment events from multi-warehouse consolidation orders.

What is the best way to route orders to multiple warehouses in Shopify?

The best approach is a location routing rules engine in the integration middleware that evaluates each order against a priority-ordered set of rules before submission to the WMS. Rules should check geographic coverage per warehouse, stock availability across all line items at each location, and location capacity status. Maintain a local inventory cache in the middleware database to make routing decisions without consuming Shopify API rate limit budget on every order. Alert operations when no warehouse can fulfill an order rather than silently failing the submission.