ShipStation’s job is straightforward on paper: take orders from wherever they come in, apply the right carrier and rate, print a label, and hand off tracking. Connecting it to NetSuite is equally straightforward in the simple case — an approved sales order pushes to ShipStation, a label gets created, tracking comes back. Where it gets genuinely complicated is everything that isn’t the simple case: split shipments, partial fulfillments, and carrier logic that doesn’t match ShipStation’s defaults.
The core workflow, and why it’s worth automating
Without an integration, someone is manually creating shipments in ShipStation for orders that already exist in NetSuite — re-keying order details, customer addresses, and line items that NetSuite already has. That’s slow and it’s an obvious source of transcription errors. The integration removes the re-entry entirely: an approved NetSuite sales order pushes to ShipStation as a shipment request, and once a label prints, the tracking number and fulfillment status flow back into NetSuite automatically. From NetSuite’s perspective, the order is fulfilled the moment ShipStation says it is — no one has to check a separate dashboard to confirm.
What flows in each direction
- Orders converting into ShipStation shipments
- Tracking numbers, synced back the moment a label is generated
- Shipping costs, for accurate landed-cost or margin reporting
- Carrier selection, whether automatic or rule-based
- Delivery status updates as a package moves
Split shipments are the real test of whether this was built right
An order that ships complete in one box is the easy case, and it’s the case most demos and basic integrations are built around. Real fulfillment doesn’t work that way. An order with five line items might ship in two or three packages, on different days, sometimes from different sources if you’re running more than one fulfillment location. Each of those partial shipments needs to sync back to NetSuite as its own event, with its own tracking number, rather than the integration waiting for “the order” to be fully shipped before updating anything.
Build this wrong and you get a NetSuite order sitting in a pending-fulfillment state for days after the customer has already received the first two of three packages — which is confusing for customer service, and worse if it’s feeding automated customer communications that are now telling someone their order hasn’t shipped when part of it already has.
Carrier and packing rules need to reflect how you actually ship, not ShipStation’s defaults
ShipStation ships with sensible default logic for carrier selection and packing, but very few merchants actually operate on the defaults once they’ve been shipping for a while. Weight breaks that favor one carrier over another, packaging rules tied to product categories, regional carrier preferences — these are usually the product of real operational experience, and the integration needs to respect that logic rather than assume ShipStation’s out-of-the-box rules are good enough. Part of scoping this integration is documenting your actual shipping rules before assuming the default configuration will hold up.
How we build it
We start by mapping your actual fulfillment patterns — how often orders split across multiple packages, whether you run multiple warehouses or fulfillment sources through ShipStation, and what carrier/packing rules already exist. From there, the sync is built to handle partial fulfillment as a normal case rather than an edge case, tracking data flows back per package rather than per order, and the whole thing gets tested against orders that actually split — not just clean, single-package test orders — before go-live.
If your ShipStation and NetSuite setup currently loses accuracy on anything beyond a single-package order, that’s worth fixing before it becomes a customer service problem. See the full ShipStation integration guide for more, or contact us about your current fulfillment setup.