Skip to main content
Talk to an expert
ShipStation delivery platform

ShipStation Fulfilment Integration Specialists

Orders dispatch with tracking flowing back cleanly iWeb integrates ShipStation with your commerce, order management and ERP systems so orders route to the right carrier, tracking reaches customers immediately, stock and refunds reconcile on time. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

ShipStationiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Shopify Plus · Adobe Commerce · Magento Open Source · BigCommerce · Other storefronts
On this pageGet a brief reviewed
00 · At a glance

ShipStation at a glance.

Category
WMS · shipping · fulfilment
Role in the estate
Runs the warehouse, picks, packs and carrier hand-off - the system that turns a promised order into a shipped order.
Commonly connects with
OMS · order management · ERP · finance · Commerce platforms · POS · retail · branch systems
Typical use cases
Route orders to carriers with configurable rules based on weight, destination or order attributes · Generate and track shipment labels across multiple carriers and service levels from a single queue · Send dispatch and tracking events back to ecommerce platforms and customer accounts · Reconcile stock movements and fulfilment status between fulfilment nodes and ERP
Relevant services
BuildSupportRescue
01 · What you get

What a ShipStation integration gives you.

Orders dispatch without manual handoff

Orders move from commerce to ShipStation automatically, labels print, carriers collect, and tracking flows back to shoppers. No queue backlog, no lost orders, no manual order entry.

Tracking and status flow to customers in real time

Customers see carrier confirmation and tracking number in their account and email the moment the order ships. No gaps between fulfilment action and customer visibility.

Stock and financials reconcile from dispatch

Dispatch events trigger stock deductions and COGS posting in ERP. Inventory on-hand stays accurate. Returns flow back to inventory and receivables on time.

Carrier rules stay consistent across channels

Service tiers, rates and zone definitions in ShipStation align with OMS and ERP logic. No surprise rate changes, no mis-selected service levels, no channel-specific carrier drift.

Returns and RMAs close the loop

Return labels print from ShipStation, returned items re-enter inventory, and refunds post to customer accounts and ERP on time. No refund delays, no stray stock, no customer service chaos.

02 · When it's worth it

Where a ShipStation integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Route orders to carriers with configurable rules based on weight, destination or order attributes
Generate and track shipment labels across multiple carriers and service levels from a single queue
Send dispatch and tracking events back to ecommerce platforms and customer accounts
Reconcile stock movements and fulfilment status between fulfilment nodes and ERP
Handle returns, RMAs and refund workflows across channels and back to inventory
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

Carrier rate logic locked into ShipStation configuration

Carrier service selection and rate calculation are governed by ShipStation rules, not ERP pricing or contract tiers. If your ERP holds negotiated rates or zone definitions that differ from ShipStation's setup, manual maintenance or custom feeds are needed to keep rates aligned.

Limited visibility into stock reserves and multi-location allocation

ShipStation does not natively understand stock allocation logic across locations, fulfilment nodes or channels. If you operate branch pickup, dropship or split-shipment rules, those must be encoded in order-routing logic upstream in OMS or ERP; ShipStation receives pre-decided orders.

Returns and refund workflow gaps with ERP

ShipStation handles return labels and inbound logistics, but refund processing, credit-note generation and customer-account credit are not native to ShipStation. Those workflows must be owned by ERP or customer-service systems and triggered via return-received webhooks.

No native order-reject or fulfilment-capacity logic

ShipStation does not hold stock levels or fulfilment capacity per location. Orders that arrive in ShipStation are assumed to be fulfillable; oversell or capacity failures must be caught by OMS or order-validation logic upstream.

Webhook and polling latency in high-volume scenarios

Real-time dispatch and tracking updates depend on ShipStation webhooks or polling intervals. During peak trading or carrier outages, latency between shipment event and storefront update may be minutes to hours, leaving customers and customer service without current status.

03b · Honest limits

When ShipStation may not be the simplest fit.

A short, honest list. Not a warning; just where a different shape of system usually costs less to run.

A single carrier and a warehouse the current process handles well
No operations lead willing to own rule maintenance
Expecting the storefront to own the fulfilment truth
Order volumes far below the vendor threshold
04 · The real work

Dispatch queues expose the boundary between order routing and fulfilment execution; without clear ownership and exception handling, stuck orders silently cost customer trust.

05 · Where it sits

Where this integration sits in your estate.

ShipStation 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.

Commerce platform agnostic. Connect ShipStation across your entire technology stack.

System of record
Source / owner
ShipStation
Multi-carrier dispatch, label generation and tracking layer between order capture and customer
  • Shipment label generation and carrier integration
  • Tracking number polling and status updates
  • Return label generation and reverse-logistics coordination
  • Carrier account and service-tier configuration
  • Dispatch queue and label-print workflow
iWeb integration layer
Customer-facing commerce
Commerce platform
Shopify PlusAdobe CommerceMagento Open SourceBigCommerceOther storefronts
  • Order capture and customer detail
  • Order-status display and tracking links
  • Return authorisation and RMA initiation
  • Storefront notification triggers
Connected neighbours
Integration layer
ERP
ShipStation dispatches orders that ERP has validated; dispatch confirmations trigger stock deduction and COGS posting in ERP.
Integration layer
OMS
OMS routes orders to the right location before they reach ShipStation; ShipStation executes the dispatch that OMS decided.
Integration layer
WMS
ShipStation may receive picking status from WMS; WMS may receive dispatch confirmations from ShipStation to update on-hand inventory.
Integration layer
Customer service / CRM
ShipStation tracking and return events feed into customer service systems so support staff can see shipment status and process refunds.
Integration layer
Marketplace connectors
Orders from Amazon, eBay, Etsy and other channels flow through a central commerce or OMS layer to ShipStation; tracking flows back to each marketplace.
Two-way sync where relevant
06 · Surrounding systems

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.

Ecommerce platforms (examples)
  • Shopify Plus
  • Adobe Commerce
  • Magento Open Source
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • ERP (SAP, NetSuite, Dynamics 365, Sage, Infor)
  • OMS (order management system)
  • WMS (warehouse management system)
  • Customer service and CRM systems
  • Marketplace connectors (Amazon, eBay, Etsy)
  • Accounting and invoicing systems
Not sure?

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.

Ask us about your stack
07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into COMMERCE & ERP
←From COMMERCE
↔BOTH WAYS
Order and item detail to ShipStation: Orders, customer addresses, line items and shipping instructions flow from your commerce platform(s) and OMS into ShipStation for dispatch queue and label generation
Order attributes such as weight and service-level preferences inform carrier and rate selection.
Tracking and dispatch confirmation back to storefronts: Shipment tracking numbers, carrier confirmation, dispatch timestamp and label URLs flow from ShipStation back to the commerce platform and customer accounts
Shoppers receive tracking detail in order status and email notifications.
Stock movement and despatch event flow: Dispatch confirmations and stock-deduction events from ShipStation feed into ERP to reconcile on-hand inventory, cost of goods sold and fulfilment status
Returns and RMA receipts also flow back to ERP for credit processing.
Carrier rules and service-level configuration: Carrier accounts, service tiers, zone-based rates and weight-break rules are configured in ShipStation and synchronised with order-management rules in ERP or OMS
Changes to carrier availability or rates propagate to both systems.
Return and RMA intent: Returns authorisation and RMA requests from customer service or ecommerce systems feed into ShipStation to trigger return-label generation and reverse-logistics workflows
Returned items re-enter inventory when received and confirmed.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Design the order-to-ShipStation contract

    iWeb maps which order attributes trigger carrier selection, which orders go to which fulfilment location, and how split or dropship orders are handed off. This ensures ShipStation receives orders that are already dispatchable.

  2. 02
    Build bidirectional webhook pipelines

    iWeb handles order confirmation from ShipStation to ERP, dispatch and tracking events to commerce and customer service, and return-received signals to trigger ERP credit workflows. Exception queues and retry logic protect against carrier or webhook latency.

  3. 03
    Govern ownership and failure modes

    iWeb names who owns carrier selection, who monitors the dispatch queue, who handles stuck or unshipped orders, and who reconciles returns. When ShipStation goes down or a carrier becomes unavailable, the fallback path is clear.

  4. 04
    Support multi-location and multi-channel dispatch

    iWeb designs order-routing rules that account for branch stock, allocated inventory, dropship suppliers and click-and-collect handoffs. ShipStation receives orders that are already routed to the right node.

  5. 05
    Monitor dispatch SLAs and exception queues

    iWeb builds dashboards and alerts for order-to-ship time, unshipped-order backlogs, carrier failures and tracking-update latency. Exceptions surface to the right owner before customers complain.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataDispatch instructions and order readiness
Source / ownerOMS or order-validation layer
Maintained byOrder management team
NotesShipStation receives orders that are confirmed dispatchable; OMS decides which location and carrier before the order arrives in ShipStation.
DataShipment labels, tracking numbers and carrier confirmation
Source / ownerShipStation
Maintained byCarrier and ShipStation systems
NotesShipStation generates labels and polling carriers for tracking; these events must flow back to commerce platform and customer accounts in real time.
DataStock movement and on-hand reconciliation at dispatch
Source / ownerERP
Maintained byFinance and warehouse teams
NotesDispatch confirmations from ShipStation trigger stock-deduction and COGS posting; return-received signals reverse those entries.
DataCarrier accounts, rates, service tiers and zone rules
Source / ownerCarrier contracts and OMS / ERP
Maintained byProcurement and order-management teams
NotesRates and service tiers may be stored in ShipStation configuration or fed from ERP; both routes require alignment to avoid rate mismatches.
DataReturns authorisation, RMA status and refund decision
Source / ownerERP or customer-service system
Maintained byCustomer service and finance
NotesShipStation prints return labels and tracks inbound logistics; ERP and customer service own the refund and credit-note decision.
DataIntegration transport, exception queues and monitoring
Source / ownerIntegration layer
Maintained byiWeb and operations team
NotesWebhook failures, carrier outages, dispatch backlogs and tracking delays must be surfaced and escalated to the right owner.
10 · Experienced integrator

Built this before

iWeb has designed and built ShipStation integrations across multi-location, multi-channel and split-shipment estates. We understand how ShipStation sits between order routing (OMS) and finance (ERP), where the real operational tension is, and how to handle failure modes that only appear at scale.

iWeb designs order-routing contracts that ensure ShipStation receives dispatchable orders without re-work or manual handoff.
iWeb builds webhook pipelines and fallback polling so tracking, dispatch confirmations and returns reach storefronts, ERP and customer service on time.
iWeb governs dispatch queue ownership, unshipped-order escalation and carrier-outage fallback paths so exceptions surface to the right person.
iWeb handles multi-location, click-and-collect, dropship and split-shipment scenarios where ShipStation is one node in a larger fulfilment network.
iWeb integrates ShipStation with ERP stock deduction, COGS posting and refund workflows so finance and inventory stay accurate.

Enterprise digital commerce specialists since 1995

UK-based, employee-owned team

Adobe Gold Commerce Partner

ERP, PIM and operational integration experience

Build, replatform, rescue and long-term support

Platform-led where appropriate, integration-led across the wider estate

11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Orders flow from commerce platform to ShipStation without duplication and with all required attributes (weight, service level, address).
Shipment tracking and carrier confirmation return to the storefront and customer accounts within five minutes of label creation.
Stock deduction and COGS posting occur in ERP at dispatch time; returned items reverse those entries when ShipStation confirms receipt.
Unshipped orders are detected and escalated to warehouse staff within 15 minutes of passing the dispatch SLA threshold.
Return labels print from ShipStation and return-received signals trigger ERP credit-note generation without manual intervention.
Carrier rules and zone definitions stay aligned between ShipStation and OMS / ERP; rate mismatches are caught in pre-production.
ShipStation downtime does not block order capture; a fallback queue holds orders and processes them when ShipStation recovers without data loss.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Orders stuck in dispatch queue

Orders arrive in ShipStation but are not picked, packed or shipped. This happens when fulfilment capacity is overwhelmed, carrier accounts are full, or dispatch rules are unclear. Customers see no tracking and contact support; finance does not deduct stock.

Tracking or dispatch events fail to reach the storefront

ShipStation generates tracking but webhooks to commerce time out or fail silently. Customers do not see their tracking number; storefronts show 'pending' for days. Meanwhile, goods are already in transit.

Stock and COGS not reconciled when orders dispatch

Dispatch confirmations do not trigger stock-deduction or COGS posting in ERP. Inventory appears on-hand after goods ship. Month-end reconciliation fails. Finance cannot close the period.

Carrier rules or rates silently drift

Carrier service levels, zone definitions or rates are updated in ShipStation but OMS or ERP rules are not. Orders are routed to the wrong carrier or service tier. Freight costs and customer delivery expectations misalign.

Returns or refunds lost between ShipStation and ERP

Return labels print in ShipStation and customers ship items back, but return-received signals do not reach ERP or customer service. Items sit in inbound or are lost. Credit notes are never posted. Customer refund is delayed or denied.

Multi-location or multi-channel orders break the dispatch flow

Orders for click-and-collect, branch pickup, dropship or split shipment are not pre-routed by OMS. They arrive in ShipStation as ambiguous. Dispatch staff manually re-route them or choose the wrong location. Some orders ship from the wrong node; others are delayed.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about ShipStation integrations.

How do we decide which orders go to ShipStation and in what format?

iWeb designs an order-routing contract that names which systems feed orders to ShipStation (commerce platform, OMS, marketplace connectors), what attributes are required (weight, dimensions, service-level preference), and how split or dropship orders are pre-decided by OMS. Orders arrive in ShipStation ready to pick and label without re-routing.

What happens if an order is stuck in ShipStation and not dispatching?

iWeb builds monitoring and alerting so unshipped orders are surfaced within minutes, not hours. The integration layer names who owns the dispatch queue (warehouse manager, ShipStation admin, customer service), what the fallback is (escalation, manual pick, order cancellation), and how to prevent backlogs during peak trading.

How does tracking get back to customers on time?

iWeb implements ShipStation webhooks that fire when a label is created and when the carrier updates tracking status. These webhooks post tracking numbers to the commerce platform and trigger order-status emails. If webhooks fail, a backup polling job fetches tracking from ShipStation every few minutes. Latency is typically seconds to minutes, not hours.

How do we reconcile stock and COGS when an order ships?

iWeb maps dispatch confirmations from ShipStation to ERP stock-deduction and COGS posting events. When ShipStation confirms an order is shipped, the integration posts the stock movement and invoice line to ERP automatically. Returns flow the same path in reverse. This ensures inventory and financials stay in step.

What if a carrier becomes unavailable or changes rates?

iWeb designs the integration so carrier rules (service tiers, zone definitions, rates) are either stored in ShipStation or fed from ERP / OMS on a schedule. If a carrier drops a service level or rate, the integration can detect the change and alert the procurement or order-management team before it impacts live orders.

How are returns and RMAs handled from customer request to refund posting?

iWeb maps the return workflow: customer initiates RMA in customer service or self-service portal; ShipStation prints a return label and the customer ships back; ShipStation confirms receipt of the return; the integration triggers ERP credit-note generation and customer-account credit posting. If any step fails, the integration escalates to customer service.

Do we need to manually configure carrier accounts in both ShipStation and ERP?

No. iWeb maps carrier accounts once into ShipStation and either replicates the rates and zone definitions to ERP via a scheduled feed, or references ShipStation rules from ERP order-routing logic. This avoids duplicate maintenance and rate mismatches.

What happens if ShipStation goes down during peak trading?

iWeb designs a fallback: orders can be held in a queue in OMS or the commerce platform pending ShipStation recovery. When ShipStation recovers, queued orders flow in without re-processing or duplication. If ShipStation is down for hours, a manual dispatch path (printing labels locally, using a backup carrier) is documented and tested.

How do we handle split shipments or orders shipped from multiple locations?

iWeb designs order-routing rules in OMS or ERP that decide which lines go to which fulfilment location before the order reaches ShipStation. Each location sends its portion to its own ShipStation account or a ShipStation warehouse record. The integration stitches tracking back together so the customer sees all shipments in one order view.

Can multiple ecommerce platforms share the same ShipStation account?

Yes. iWeb designs a single ShipStation account that receives orders from multiple storefronts (Shopify Plus, Adobe Commerce, BigCommerce, Magento Open Source, others). Order metadata names the source platform so dispatch confirmations and tracking are routed back to the correct storefront.

How do we monitor dispatch SLAs and catch exceptions?

iWeb builds dashboards that track order-to-ship time by location and carrier, unshipped-order backlogs, tracking-update latency, and webhook failure rates. Alerts fire when unshipped orders exceed a threshold, carriers drop services, or tracking events are delayed. Exceptions route to the warehouse team, customer service and operations.

What is the difference between ShipStation managing dispatch and our ERP managing it?

ShipStation specialises in label generation, carrier integration and logistics coordination. ERP is better at order-routing rules, stock allocation and finance posting. iWeb designs the boundary: ERP owns routing decision and stock; ShipStation owns dispatch and tracking; the integration stitches them together with clear ownership of each step.

How do we migrate from a legacy shipping system to ShipStation?

iWeb designs a parallel-run period where orders flow to both systems, tracking is reconciled, and staff are trained on ShipStation workflows. Once confidence is high, the legacy system is switched off. In-flight orders from the legacy system are tracked separately until delivery. The integration is tested end-to-end before cutover.

What data does ShipStation need from commerce, and what must we suppress?

ShipStation needs recipient address, weight, dimensions, service-level preference and any handling instructions. Suppress customer payment details, internal warehouse codes, and any PII beyond what the carrier needs. iWeb maps the field list so commerce sends only what ShipStation needs and nothing extra.

Next step

Have a ShipStation integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →