What a nShift integration gives you.
Once an order is confirmed in commerce and stock is allocated, it flows to nShift, the right carrier is selected, a label is generated and the warehouse receives a clear picking list - all without human re-entry or data translation.
Tracking numbers and estimated delivery dates populate your storefront order tracking page within minutes of despatch, reducing support queries about shipment status and building confidence in delivery.
Return labels are issued from nShift, inbound returns are matched to original orders, and credit notes and stock reversals are triggered in the ERP without manual reconciliation or month-end adjustment.
Unshipped orders, carrier rejections and address failures are captured and routed to the warehouse or OMS team with clear context so they can be resolved quickly instead of languishing in a queue.
Despatch times, carrier costs, exception rates and on-time delivery performance can be tracked and attributed to specific carriers and routes, informing carrier negotiations and operational decisions.
Where a nShift integration earns its place.
If two or more of these are true, the integration usually pays for itself quickly.
Where off-the-shelf connectors fall short.
Vendor connectors are fine for simple cases. Here's where the real ones need more.
nShift allows complex carrier selection rules (weight bands, destination zones, cost thresholds), but changes to these rules are made outside commerce and must be manually communicated or monitored. No built-in alerting when rules change and orders start routing differently.
nShift confirms dispatch but does not reconcile actual picked quantities against the ERP in real time. Discrepancies between orders sent and quantities available at the warehouse can lead to partial shipments or holds without explicit feedback into commerce.
nShift generates return labels but does not automatically match inbound returns to the original order or trigger credit notes in the ERP. Manual linking of return events to orders and financial reversal is often required downstream.
Failed despatches, address errors and carrier rejections land in nShift but may not propagate clearly into commerce or warehouse systems. No default escalation or assignment means exceptions can be missed or resolved inconsistently.
nShift routes to carriers but not to warehouses or stock locations. If you operate multiple fulfilment points, you must pre-route orders in commerce or OMS and pass the correct warehouse context into nShift for each order.
The gap between confirmed orders and picked stock is where despatch failures hide; without clear exception routing and ownership, days can pass before anyone notices orders are not leaving the warehouse.
Where this integration sits in your estate.
nShift holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.
No platform lock-in. We integrate nShift with the commerce core you already have, or the one you are moving to.
- Carrier selection and routing rules
- Label generation and manifest data
- Despatch confirmation and tracking numbers
- Return label issuance and return tracking
- Despatch exceptions and failure codes
- Order confirmation and readiness signals
- Delivery address validation
- Parcel data (weight, dimensions, items)
- Customer tracking page and notifications
- Return request initiation and status
Systems this integration usually sits next to.
Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.
- Adobe Commerce
- Magento Open Source
- Shopify Plus
- BigCommerce
- Other storefronts
- ERP (SAP, NetSuite, Sage)
- Order Management System (OMS)
- Warehouse Management System (WMS)
- Inventory and stock allocation
- Shipping and fulfilment workflows
- Returns and RMA management
- Customer communications and tracking
Not sure if this works with your stack?
Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.
The data flows we wire.
Each flow has a direction and an owner. We agree both before a line of code is written.
How iWeb configures the integration around your business.
Same method on every integration. The decisions come before the code.
- 01Design order and inventory readiness checks
We define the conditions under which an order is ready to despatch (payment confirmed, fraud checked, stock allocated) and model how nShift is triggered without creating duplicate or orphaned despatch instructions.
- 02Build exception handling and escalation
We implement logic to detect and categorise despatch failures (address, carrier, weight, stock hold), route them to the right team inbox, and track resolution status so nothing falls into a black hole.
- 03Establish return and RMA workflows
We model how return requests flow from commerce into nShift, how return labels are issued and tracked, and how completed returns are matched to original orders and trigger ERP credit notes and stock adjustments.
- 04Implement despatch and tracking observability
We build dashboards and alerting so you can see order-to-despatch latency, despatch success rates, carrier performance and exception volumes, and correlate them with revenue and customer satisfaction metrics.
- 05Map multi-carrier and multi-location logic
If you operate multiple warehouses or use multiple carriers by geography or service level, we design the routing and instruction format so each order finds the right fulfilment point and carrier without manual intervention.
Who owns what.
The single most important table in any integration. One system owns each field; everything else reads it.
Built this before
iWeb has designed and built nShift integrations across retail, direct-to-consumer and marketplace models. We understand how despatch rules, exception handling and return workflows sit in the middle of order management, warehouse operations and ERP finance.
What we test before launch.
Every one of these is rehearsed before a customer ever sees the integration.
Common risks and where they bite.
We name these on day one. A risk written down is a risk you can plan around.
Orders confirmed in commerce but not yet picked or despached in the warehouse can become orphaned if nShift or the warehouse system does not report them back to commerce. Customers see 'processing' indefinitely while the order sits in a warehouse queue.
If the despatch confirmation from nShift or the warehouse does not flow back to commerce reliably, customers do not receive tracking numbers, and support teams must look them up manually or refund without visibility into what actually shipped.
Carrier weights, zones, service levels and costs are maintained in nShift, not commerce. A change to a rule (e.g. weight band updated) may cause orders to route to a different carrier or fail selection without warning, creating despatch delays or service failures.
Return labels are issued and returned items arrive at the warehouse, but the return event does not propagate to commerce or ERP. Stock is not recovered, credit notes are not issued, and customers see refunds as stuck or missing.
Commerce shows items in stock and sends orders to nShift for despatch, but the warehouse does not have the quantities available. Partial shipments or holds result, and the mismatch is not surfaced until after the customer is notified of despatch.
Address errors, weight mismatches, carrier rejections and out-of-stock situations land in nShift but are not automatically reported to commerce or the warehouse team. Hours or days pass before anyone notices orders are not despaching, leading to late shipments and chargebacks.
Relevant services and sectors.
Common questions about nShift integrations.
How do orders flow from commerce into nShift, and what happens if the connection breaks?
Confirmed orders are sent to nShift with address, items, weight and service level. If the connection fails, orders must queue locally in commerce or OMS until nShift is reachable, or a manual despatch instruction process must kick in. iWeb designs the queue and retry logic so orders do not get lost or duplicated during an outage.
Can we use multiple carriers in nShift, and how do we control which carrier each order goes to?
Yes. nShift integrates with multiple carriers and applies routing rules based on weight, destination, delivery speed and cost. You define these rules in nShift; iWeb ensures they are visible to your team and that changes to them are communicated and tested before affecting live orders.
How quickly do tracking numbers appear in the customer order page after despatch?
Tracking numbers are usually available within 15-60 minutes of the warehouse confirming despatch in nShift or the carrier system. iWeb designs the tracking flow so this data reaches commerce without delay and is immediately visible to customers.
What happens if an order cannot be despached (e.g. out of stock, address error, carrier rejection)?
nShift flags the order as failed or held. iWeb implements exception handling so these orders surface in your warehouse or OMS with clear reason codes, are assigned to the right team, and are escalated if they remain unresolved for a set time.
How do returns flow back, and how do we reconcile them against the original order?
Return labels are issued from nShift when a customer initiates a return. When the item arrives at the warehouse, it is scanned and matched to the original order. iWeb designs the matching logic and ensures that once a return is confirmed, a credit note and stock adjustment are triggered in the ERP automatically.
Do we need to pre-allocate orders to specific warehouses before sending them to nShift?
If you operate multiple fulfilment points, yes. nShift routes to carriers but not to warehouse locations. iWeb designs the order pre-routing logic in your OMS or commerce layer so each order arrives at nShift with the correct warehouse context.
How do we monitor whether despatch is keeping up with order volume?
iWeb builds dashboards showing orders confirmed vs. despached, average despatch latency, despatch success rate, and carrier-specific performance. These are tied to your order and revenue data so you can see the impact on customer experience and cash flow.
What happens if nShift is down or unreachable?
Orders queue in commerce or OMS until nShift is back online. iWeb designs a fallback mode so despatch instructions can be issued manually to the warehouse if nShift is unavailable for more than a few minutes, preventing customer shipment delays.
How do we handle split shipments or partial despatch?
If items are out of stock or on backorder, the warehouse may despatch a partial order. iWeb designs the logic so partial despatches are reported back to nShift and commerce, customers are notified of the split, and ERP stock is reconciled against what actually left.
Can we change carrier rules or weights without affecting orders already in the despatch queue?
Rules changes take effect for new orders immediately. Orders already sent to nShift are not re-routed. iWeb implements versioning and change notifications so you know which rules apply to which orders and can avoid surprises during peak periods.
How do we ensure stock allocated in commerce actually exists at the warehouse?
Commerce may reserve stock, but nShift and the warehouse are the sources of truth for what can actually be picked. iWeb designs the flow so if the warehouse cannot find the stock, despatch fails and the order is held until stock is resolved, rather than issuing a false tracking number.
Do we need to integrate nShift with our ERP directly, or can it go through commerce?
Despatch confirmations and tracking typically flow through commerce first (to update customer orders), then ERP receives them for stock reconciliation and invoicing. iWeb designs the sequence and retries so data reaches both systems reliably and in the right order.
What carrier data (weight, dimensions, barcodes) do we need to send from commerce to nShift?
At minimum: delivery address, order total weight, parcel count and desired service level (standard, express, etc.). Optional: SKU-level weights, dimensions, fragility flags, and customs data for international orders. iWeb maps your commerce data structure to nShift's expected format and validates completeness before sending.
How do we handle high-value orders or orders requiring signature?
nShift supports carrier-specific service options (signature required, adult signature, insured value). iWeb designs the mapping so order attributes in commerce (e.g. value threshold, delivery instructions) automatically trigger the right carrier options without manual selection.
Projects with a similar shape.
A workwear commerce platform designed around international catalogue scale and B2B supply.
Global catalogue operations across multiple markets.
A product data platform shaped around catalogue accuracy and downstream commerce.
Heritage parts commerce built around specialist catalogues, vehicle fitment and enthusiast demand.
An allergen data connector built around PIM automation, shared catalogues and product accuracy.
Allergen product data made easier to manage, share and scale across food industry catalogues.