ShipOS
Most 3PLs license a third-party WMS. We wrote our own. ShipOS is the warehouse and order management system that powers every order Warpspeed ships, and it is the reason our brands experience a 3PL that behaves like a modern software product.
TL;DR
The third-party WMS market in e-commerce 3PL is concentrated around a small set of products. Extensiv runs Warehouse Manager (the former 3PL Central) for a large share of small and mid-size operators[1]. Mintsoft, owned by The Access Group, serves a similar segment with a focus on UK-headquartered operators expanding into the US[2]. SkuVault, now part of Linnworks, sits in the inventory management niche. Each is a serviceable product. None of them were written by the people running the floor for the specific brand on the box.
That distinction is the entire reason ShipOS exists. When a 3PL licenses a WMS, the path from operational insight to product change runs through a vendor support ticket, a roadmap meeting six quarters out, and a contract renewal. When a 3PL writes its own, the path runs through the engineer sitting next to the supervisor. The brand benefits from a system that adapts to their business inside a sprint, not inside a sales cycle.
Section 01
The phrase WMS is accurate for the inventory and picking layer but it sells short the rest of what a 3PL platform needs to do. ShipOS handles inbound receipts, slot management, wave planning, pick paths, packing, multi-carrier label generation, manifest, returns processing, billing, and analytics in a single product. Calling it a warehouse management system would suggest it stops at the dock door. It does not.
We chose the operating system framing because the platform sits between the physical warehouse and every other system the brand cares about. ShipOS schedules the floor, talks to the carrier APIs, exposes the public REST surface, signs the webhooks, and keeps the audit log that finance and compliance teams rely on. The analogy is the same one a developer uses for an actual OS: the kernel that makes hardware useful for the applications sitting on top of it.
“A WMS manages a warehouse. ShipOS runs the business that ships out of one.”
Section 02
ShipOS is built as a set of services that share a common identity layer, a single event bus, and a common database for transactional inventory state. Each module owns its workflows, its UI surfaces in the dashboard, and its section of the API.
Core modules in ShipOS
| Module | What it owns |
|---|---|
| Receiving | ASN ingestion, inbound appointments, dock scheduling, unit-level receipt scans, lot and expiration capture |
| Putaway and slotting | Bin assignment rules, velocity-driven slot moves, replenishment to forward pick faces |
| Order management | Order intake from API and connectors, validation rules, allocation, channel reservations, ship-method selection |
| Picking | Wave planning, pick path optimization, batch and zone picks, scanner-driven exception handling |
| Packing and shipping | Pack station workflows, multi-carrier rate shopping, label generation, manifest, end-of-day reports |
| Returns | RMA generation, inbound disposition, restock or repair routing, customer reason capture, refund triggers |
| Billing | Per-event cost capture, monthly invoicing, custom rate cards, surcharge attribution |
| Analytics | P&L per SKU, freight by zone, peak forecasting, returns insights, dashboard tiles, scheduled exports |
Section 03
ShipOS is event-driven by design. Every state change in the warehouse, from a unit scan during receiving to a label print at the pack bench, emits an event on an internal bus. Downstream consumers in the platform subscribe to those events and update the corresponding state. The same events are filtered and re-emitted on the public webhook channel, so brand systems get the same ground truth the dashboard does.
That choice has practical consequences. There is no nightly sync between modules because there is no separation between modules to sync across. The order board, the inventory page, and the analytics tiles all read from the same materialized views, so a question asked in one surface and answered in another lands on the same number. Brands moving from a legacy platform often cite this as the most surprising change in their first month.
“One bus, one truth. The pack bench and the boardroom report on the same event.”
Behind the scenes, the platform runs on managed cloud infrastructure with multi-region failover for the API and asynchronous workers for the heavier background jobs like rate shopping, slotting recalculations, and forecast model runs. Industry coverage of modern WMS architecture has consistently highlighted event-driven design as the differentiator between platforms that scale into multiple facilities and those that hit a wall[3].
Section 04
The point of this comparison is not to attack the third-party vendors. They run real businesses serving thousands of operators. The point is to make the tradeoffs explicit so a brand evaluating partners can ask informed questions of any 3PL, including us.
| Capability | Third-party WMS | ShipOS |
|---|---|---|
| Ownership | Licensed by the 3PL from a vendor (Extensiv, Mintsoft, SkuVault) | Built and operated in-house at Warpspeed |
| Customization | Vendor-controlled roadmap, multi-tenant constraints | Internal engineers ship workflow changes within a sprint |
| Data freshness | Often batched per module sync interval | Single event bus, sub-minute end-to-end propagation |
| API maturity | Generally adequate for read, weaker for writes and webhooks | Full read and write coverage, signed webhooks, idempotent writes |
| Brand-specific workflows | Limited to vendor configuration options | Built directly into the relevant module when justified |
| Carrier integration speed | Depends on vendor's connector roadmap | Built and shipped by Warpspeed when the carrier launches |
| Pricing exposure | Vendor seat or transaction fees passed to the 3PL | No third-party software pricing to pass through to the brand |
Industry research from the annual Third-Party Logistics Study has documented the growing gap between technology-leading 3PLs and the rest of the field[4]. Brands consistently report higher satisfaction and lower switching intent with operators who run modern, in-house technology. The financial cost of building software is not trivial, but the alternative is paying it in slower integrations and lower retention.
Section 05
Real-time visibility is one of the most overused phrases in 3PL marketing. Most operators that claim it actually mean a status board that refreshes every 15 minutes against a sync job. ShipOS targets sub-minute end-to-end latency from a floor scan to the dashboard tile and to the brand's registered webhook endpoint. The architecture, with one event bus and materialized views shared across modules, is what makes that achievable.
For a brand the practical effect is that a customer service agent searching for an order minutes after it was packed sees the manifest scan, not a stale status. A finance analyst running a freight report at 4pm sees the shipments that left the dock at 3:30pm. The numbers are not fresher because we report them faster, they are fresher because the underlying system was designed for that cadence from the first commit.
Section 06
Building a WMS from scratch is not a casual decision. We made it because the licensed alternatives could not move fast enough for the kinds of brands we wanted to serve. The history below is a short version of how the platform grew into its current shape.
Phase 1
Pick and pack on a custom data model
We started with the order, allocation, and pick workflow because that is where the most operational variation lives. Building those three modules in-house gave us ground truth on data structures the rest of the platform would inherit.
Phase 2
Carrier integrations and label generation
We replaced our reliance on a third-party label vendor with direct carrier integrations. Every label print became an event on the bus, which made the freight analytics layer possible.
Phase 3
Receiving, slotting, and the inventory layer
Inventory accuracy is the foundation of every other report. We built the inbound and slot modules to capture lot, expiration, and bin position at the unit level, with cycle-count workflows tied to the same data.
Phase 4
Public API, webhooks, and the dashboard
Once the operational modules were stable, we exposed the API and built the dashboard on top of it. The dashboard is a customer of the same API our integrated brands use, which keeps the surface honest.
Phase 5
Analytics, returns, and billing
The most recent investments cover the financial layer: per-SKU P&L, the returns workflow with reason-code analytics, and the billing engine that turns the event log into invoices.
Section 07
We do not publish a public feature roadmap because warehouse priorities shift with the seasons. We do publish three commitments. First, the dashboard and the API stay in lockstep, so anything an account manager can show, a developer can fetch. Second, every endpoint we ship gets at least 12 months of support after deprecation is announced. Third, the cost of integrating with ShipOS stays close to zero, because the platform is meant to be the cheapest part of a brand's switch to Warpspeed.
On the operational side, the investments most relevant to brands are data-driven slotting, smarter wave planning, and replenishment forecasting tied to live sales. Industry coverage of warehouse productivity has noted that slotting and labor planning are usually better early investments than physical robotics for 3PLs at our scale[5]. That is the order in which we sequence our own work.
“The fastest robot on the floor is still slower than a clean event bus.”
Section 08
ShipOS is built so a brand engineer can be productive in an afternoon. The sandbox tenant ships with seeded inventory and an order generator. The API documentation includes a runnable Postman collection. The webhook receiver scaffolds for Node, Python, Ruby, Go, and PHP are open to download. None of this is gated behind a sales conversation.
Once the sandbox loop closes, the production tenant inherits the same API surface, the same dashboard, the same data model. There is no separate enterprise tier with a different schema. We have learned that brands who integrate deeply during the first month grow faster on the platform, because they automate the parts of fulfillment their team should not be touching by hand.
Try ShipOS
We will load a sandbox with sample data, walk your team through the dashboard and API, and answer the engineering questions your stack will raise during evaluation.