Order Management
Part of Fulfilment integrations
Monitoring a failed order import
Find where an order import failed, inspect the rejection, retry safely and reconcile the accepted warehouse work.
Compare orders that should have reached the warehouse with instructions the warehouse actually accepted to find failed imports. For each gap, identify the last confirmed step, retain the error and assign an owner. Before retrying, check whether the first attempt created warehouse work.
Watch each transition
A storefront event, integration queue entry, WMS order and released pick are separate records. Track the source order and line reference through the states the connected products actually expose. Record when an order entered its current state, so stalled work is visible even without an error message.
Symptom / First place to look
- No integration event
- Source eligibility, subscription or scheduled extraction
- Event received but no WMS message
- Integration validation and mapping log
- Message queued but no WMS order
- Downstream processor state and error log
- WMS order exists but no pick work
- Release, hold, reservation or warehouse rule state
A missing pick task may be a valid hold rather than an import failure. Confirm the source order’s expected state before treating the gap as an error.
Investigate the rejection
Keep the source order and line IDs, warehouse message ID, attempt time, error text and any current warehouse record. Compare item cross-reference, unit, location and required address fields with the actual rejection. Do not substitute a plausible value merely to clear the queue.
In Microsoft’s Warehouse management only mode, inbound and outbound shipment orders use the message processor. Its Message processor messages page shows incoming messages and the message log. You can manually process messages and troubleshoot issues there. These are controls in that product, not a ready-made recovery route for every WMS.
Separate webhook delivery from import
If a Shopify webhook triggers the transfer, inspect delivery status separately from downstream processing. Shopify’s Dev Dashboard logs show response, topic, shop, time and delivery-attempt information, but the logs cover a limited period and can update with a delay.
Shopify retries failed webhook calls up to eight times in a four-hour period; if failures persist, the subscription is removed. A successful webhook response therefore does not prove that a WMS accepted the order.
Use the delivery ID (X-Shopify-Webhook-Id) to recognise a repeated delivery. Use a stable order or instruction reference to prevent duplicate warehouse work. Reconcile eligible storefront orders against accepted WMS orders to find missed events and later processing failures.
Shopify Webhook Retry Behavior and Delivery Monitoring
- Retry window
- Four hours
- Delivery ID header
- X-Shopify-Webhook-Id
Retry to a known outcome
After correcting the cause, search for an existing warehouse instruction and any work already released. Use the receiving product’s supported reprocessing route, or send a corrected instruction with the agreed business reference. Record the new attempt and compare accepted lines and quantities with the source order. Escalate an uncertain result instead of resending blindly.
Alert on failed messages and on orders with no confirmed warehouse outcome beyond the operation’s chosen review window. Close a case when the intended work exists, an authorised hold is recorded, or the source obligation was cancelled with a traceable decision.
