Understand how every order flows through WarpWare — from ingestion to fulfillment — and what happens at each stage.
Orders are held during the Pending stage by rules or manual action. Orders fail at the Sent stage if Extensiv rejects them. Cancelled can occur before Sent.
The order has been ingested but has not yet been evaluated by the rules engine. This is the initial state for every order entering WarpWare — whether it arrives via API, Shopify webhook, EDI file, or email.
The order has passed all rules and has a valid routing destination. It is queued for dispatch to the assigned fulfillment connection (e.g., Extensiv, ShipStation, or a warehouse API).
WarpWare has successfully transmitted the order to the destination system. The order is now awaiting fulfillment externally. Tracking information may arrive via webhook or polling.
The order has been fulfilled and tracking information has been received. If the order originated from a sales channel (Shopify, WooCommerce, etc.), WarpWare writes tracking back to the source.
Orders can be placed on hold at any point before they are sent to the destination. Holds can be applied automatically via rules or manually from the dashboard.
The rules engine can flag orders for hold based on any condition — order value thresholds, specific SKUs, new customers, international addresses, etc. The hold reason is recorded on the order for visibility.
Any user can hold an order from the order detail view. A hold reason can be entered for the team. The order will not advance until explicitly released.
When a hold is released, the order re-enters the pipeline and is re-evaluated by the rules engine. If all conditions pass, it moves to Ready and is dispatched normally.
Tip: Use holds for high-value orders or pre-orders. Combine them with the pre-order release date feature to automatically release orders when inventory arrives.
When an order fails to transmit to the destination system, WarpWare records the error and marks the order as Failed. Failed orders are never lost — they remain in the system for retry.
WarpWare retries failed orders automatically with exponential backoff. The retry count and last error are visible on the order.
You can retry any failed order from the dashboard with one click. The order is re-queued and re-sent to the destination.
Every failure records a detailed error message — rate limits, validation errors, auth failures, and network timeouts are all captured.
Persistent failures trigger notifications so your team can investigate. Failures are also surfaced in the dashboard health panel.
Important: If an order fails more than 5 times, automatic retries stop and the order requires manual intervention. Check the error message and resolve the underlying issue before retrying.
WarpWare automatically detects and prevents duplicate orders. Every order is checked against existing records using a combination of source identifiers.
Note: If you need to re-import an order that was correctly deduplicated, you can clear the duplicate flag from the order detail view and re-ingest.
Every order in WarpWare maintains a complete timeline of events — from the moment it was ingested to the final tracking writeback. This audit trail is immutable and available on the order detail view.
Source, connection, and raw payload recorded
Which rules matched, what actions were taken
Destination connection and assignment reason
Timestamp, external ID, and response status
Carrier, tracking number, and writeback status
Who held it, why, and when it was released
Each failure with error message and retry attempt
Try the interactive demo or explore the Partner API to push orders programmatically.