Shiptheory integration for ecommerce fulfilment

Carrier selection rules configured in Shiptheory match on destination, weight, service level and other order attributes. When an order arrives, Shiptheory applies the rules in priority order and selects the first matching carrier. If that carrier is unavailable or hits rate limits, fallback rules select the next carrier in the chain.

If a carrier is unreachable, Shiptheory will attempt retry and then fall back to the next available carrier if rules allow it. Long outages may require manual intervention (selecting an alternative carrier or holding orders). iWeb configures alerting so operations can see when carrier issues occur and decide next steps.

Tracking publishes from Shiptheory to the ecommerce platform as soon as the label is created and handed to the carrier. iWeb ensures this flow runs within minutes so that shopper notifications and order status updates are near real-time.

iWeb connects each sales channel to a common order feed that flows into Shiptheory. All orders queue in Shiptheory regardless of origin. Despatch data is then written back to each channel's API so each channel's inventory and order status stay current.

iWeb implements idempotency checks and order reconciliation so that duplicate orders are detected and held, and missing orders trigger alerts. The integration tracks each order's state (submitted, queued, labelled, shipped) and logs exceptions when state transitions fail.

When Shiptheory creates a label and publishes tracking, iWeb writes a despatch event back to the ERP. This triggers stock movement, invoice generation if configured, and updates the order-to-cash cycle so accounting stays current.

Yes. Return labels and tracking are managed in Shiptheory. However, the return must first be authorised via your OMS or ERP so that credit approval and stock receipt reconciliation are linked. iWeb connects RMA decisions in your back office to return label generation in Shiptheory.

iWeb configures exception queues and age-based alerts so that orders stuck for more than a threshold (e.g. 2 hours) trigger warnings to your operations team. Dashboard visibility shows queue depth and bottlenecks so you can intervene before customers escalate.

Tracking refreshes as often as the carrier API publishes updates, typically every few hours. iWeb configures polling frequency based on your carrier contracts and customer expectations so you balance freshness against API cost and rate limits.

Carrier fallback rules are configured in Shiptheory by your logistics or procurement team and should be approved by operations before go-live. Rules can be updated without code changes, but changes should be tested and communicated to the warehouse team.

Not necessarily. Shiptheory can print return labels and track them. However, deciding which returns to accept and issuing credits usually requires an OMS, RMA module or ERP returns workflow. iWeb integrates these together so that the RMA approval gates despatch of the return label.

iWeb implements dashboards showing order-to-label time, despatch success rate, carrier performance, exception volumes and tracking publication latency. Alerts trigger if thresholds are breached (e.g. labelling takes >30 min, tracking is >2 hours late). Regular reports help you optimise carrier mix and identify bottlenecks.

iWeb designs a fallback so that critical orders can be captured and held temporarily in your ERP or a manual queue without being lost. Once Shiptheory recovers, queued orders flow in without duplication. Runbooks and escalation contacts are prepared before launch.

Yes. iWeb can route orders to different Shiptheory instances based on destination, fulfillment location or service level. Each instance handles its own dispatch queue and carrier integrations; a central dashboard aggregates tracking across all instances.