Our client describes themselves as the world’s number one provider of unique, high-quality custom corporate apparel and accessories, selling through two storefronts and shipping from a single warehouse operation. [Referred to as the client or the company]
The Challenge
Shopify orders already reached NetSuite through an iPaaS platform. What was missing was the shipping leg: getting packed item fulfillments into ShipStation, and getting shipment results back out again.
Until then, that gap was closed by hand. Warehouse staff worked from two systems, tracking numbers were keyed back into NetSuite manually, and the actual cost of each shipment stayed in ShipStation rather than landing against the order in NetSuite where it could be reported on.
The obvious answer was to build the shipping flow on the iPaaS platform the company already ran. The client asked us not to. Their direction is to retire that platform, consolidating integration logic inside NetSuite where their team already works. Adding a new flow to a system they intend to decommission would have meant building it twice.
The build also had to serve more than one storefront, each with its own ShipStation configuration and its own rules, without turning into a separate integration to maintain per brand. The company expects that list to grow.
The Solution
The integration was built entirely as native SuiteScript, running inside the client’s NetSuite account with no external platform in the path: a User Event script on the item fulfillment, a scheduled Map/Reduce for tracking retrieval, and a shared module owning configuration and the ShipStation client.
Connection details live on a configuration record rather than in code, so credentials never touch the codebase and administrators can change endpoints, behavior flags, and which customers and locations are in scope without a deployment. The same record is what makes the integration multi-store: the correct ShipStation configuration is resolved from the storefront stamped on each fulfillment, so one codebase serves both brands.
When a fulfillment reaches Packed status, the order is pushed to ShipStation immediately, with addresses, line items, packages, ship-by date and reconciliation references included. Duplicate protection is built in, so retries and re-saves update the existing ShipStation order instead of creating a second one. The scheduled job then retrieves shipment data, writes tracking, weight, dimensions, carrier, service and actual shipping cost back onto the fulfillment, and moves it to Shipped.
The Outcome
The integration is storefront-agnostic by design. Storefronts are configuration records, not code branches, so onboarding a new brand means creating a record and filling in its ShipStation credentials, scope and rules. There is no ceiling built into the design, and no development work in the path. Two storefronts are live on it today, with no iPaaS platform involved in the shipping flow.
Manual tracking entry has been eliminated. Fulfillments close themselves once a label is bought, and nobody copies data between the two systems. Actual shipping cost is reconciled automatically into NetSuite, which makes per-shipment margin reporting possible where the books already live. Customer service, finance and operations all read the same shipping data, because there is now only one copy of it.
No fulfillment save has been blocked by an integration failure. Errors are logged and isolated so that a problem with the API, or with one record, never stands between a packer and a saved fulfillment.
Shipping became the first flow moved off the client’s iPaaS platform, on a pattern that transfers directly to the flows that follow it.
Read the technical walkthrough of how this integration was built →