Shipmate integration for ecommerce fulfilment

Your OMS or warehouse operations team approves despatch based on stock and readiness checks. Once approved, the order flows to Shipmate, which generates labels and notifies carriers. If Shipmate is down at that moment, orders queue until it recovers. Your operations team should know how long they can hold orders before customer SLA is broken and have a fallback carrier or manual label process ready.

Shipmate polls carrier APIs (or receives webhooks) to pull tracking, estimated delivery and status updates. These are sent to your commerce platform, which displays them on the customer account and sends notification emails. If a carrier feed fails or is delayed, Shipmate will not have updates, so your customer portal shows stale data. You need monitoring to detect feed gaps within minutes and a manual check process to request tracking from the carrier.

Orders destined for despatch will queue in your OMS or commerce platform. Your warehouse team needs a fallback: manual label printing, a secondary carrier service, or a temporary pause in despatch. iWeb helps you design this runbook so your team knows the threshold (how many queued orders before escalate) and the action steps. Recovery should be idempotent so that when Shipmate comes back, queued orders retry without creating duplicate labels.

Carrier assignments, service-level choices and rate tables must be owned in one source of truth (usually Shipmate or ERP) and synced to the others. iWeb designs an atomic sync so that a rule change propagates to all systems at once, or all rollback together if validation fails. Without this, you risk one system using an old rule, causing mispriced or mis-routed shipments.

Customer or support team initiates return in your commerce platform. Shipmate generates a return label and captures the address where the item should go. When the item is received at the warehouse, Shipmate (or a warehouse scan system) confirms receipt. This trigger should auto-create a credit note in ERP and adjust stock. If that link breaks, you lose the financial reversal.

Shipmate reads available stock from ERP at despatch time. If stock is not physically reserved before Shipmate dispatches, the same inventory can be allocated to multiple orders (across channels or from re-orders). iWeb integrates stock reservation so that the moment an order is approved for despatch, ERP holds it. This prevents oversell.

Shipmate should mark an order as dispatched in your OMS once a label is generated and sent to the carrier. If the despatch instruction is retried (because Shipmate was slow to confirm), the OMS should reject the retry or Shipmate should be idempotent (recognise the retry and return the same label number). iWeb ensures this logic is in place and tested.

Yes, if each channel order flows through your OMS to Shipmate with consistent line-item data, carrier assignments and return policies. If one channel has different rules (e.g. marketplace requires signature, your storefront does not), Shipmate must either support channel-aware rules or your OMS must route each channel order to a different despatch queue. iWeb maps this logic upfront.

iWeb builds dashboards tracking: orders queued for despatch, orders dispatched in the last hour, orders with missing tracking after N hours, returns pending reconciliation. Alerts fire when queues grow, feeds fail or SLAs slip. This visibility lets your team act before customers complain.

Shipmate should have failover rules: if the primary carrier cannot accept the shipment, automatically try a secondary carrier or service level. Your commerce and ERP must be notified of the change so the customer is not surprised and accounting is not disrupted. iWeb tests failover paths and documents them in your runbook.

Shipmate records the actual cost charged by each carrier for each shipment. This must be exported to ERP for freight expense tracking and accrual reconciliation. If Shipmate costs do not match carrier invoices, your freight accrual will drift. iWeb sets up a monthly reconciliation report and exception workflow so your finance team catches cost gaps.

Core flows: orders and fulfilment instructions from OMS to Shipmate; tracking and despatch confirmation from Shipmate to OMS and ERP; return requests from OMS to Shipmate; receipt confirmation from Shipmate to ERP for stock and credit. Carrier rules and stock levels may sync both ways. iWeb documents every flow, who owns each piece and what happens when one leg fails.

Yes, if your commerce platform can send order and fulfilment instructions directly to Shipmate. However, without an OMS, you lose a central place to queue orders, handle exceptions and route orders to different carriers or fulfilment networks. iWeb often recommends a lightweight OMS (or order-queue layer) to sit between commerce and Shipmate so your warehouse team has visibility and control.