Starshipit WMS working alongside Starshipit (hybrid outbound & headless mode)

Starshipit WMS is designed to complement, not replace, your existing Starshipit workflows. You can continue to:

• Use Starshipit web to process and print labels
• Use Starshipit Mobile and other existing pick/pack flows
• Use your current shipping rules, automations and carrier setup

While you do that, Starshipit WMS:

• Subscribes to order events (created, changed, deleted, shipped)
• Tracks inventory and stock movements for those orders
• Optionally provides full inbound, stock management and WMS outbound flows

This guide explains how to run hybrid outbound workflows and headless setups, where you keep your current Starshipit processes but still gain WMS visibility and control over stock.

How Starshipit & WMS work together

Once the Starshipit WMS integration is enabled in your Starshipit account, the systems communicate via webhooks and APIs:

• Starshipit remains the system of record for:
  • Orders (created/updated/cancelled)
  • Shipments and labels
  • Courier configuration and routing rules
• Starshipit WMS becomes the system of record for:
  • Inventory (on hand, available, incoming, allocated)
  • Warehouse locations, putaway, replenishment
  • Stocktakes, adjustments and stock movement history

Key events sent from Starshipit to WMS:

• order_created – create/update order in WMS (status PENDING).
• order_changed – refresh order lines; WMS cancels old allocations/picks and resets to PENDING if needed.
• order_deleted – cancel allocations and jobs in WMS, free stock back to inventory.
• order_shipped – confirm shipment in WMS, write final stock movements and mark order as SHIPPED or PARTIALLY_SHIPPED.

You decide how much of the outbound process you want WMS to handle:

• Full WMS outbound (allocate, pick, pack & ship in WMS)
• Hybrid (some orders via WMS, some via existing Starshipit workflows)
• Headless (Starshipit handles outbound; WMS just mirrors orders & stock movements)

Common hybrid models

Model 1: Inventory & inbound in WMS, outbound in Starshipit

In this setup:

• All inbound stock (POs, receiving, putaway) is managed in WMS.
• WMS maintains accurate inventory and locations.
• Outbound orders are still picked and shipped using:
  • Starshipit web UI, or
  • Starshipit Mobile / existing pick & pack processes
• When labels are printed in Starshipit, WMS receives order_shipped events and:
  • Deducts stock
  • Writes shipment stock movements

This gives you full inventory control in WMS without changing how your team currently ships orders.

Model 2: WMS outbound for one warehouse, Starshipit outbound for others

For multi-location or multi-account setups, you can:

• Use WMS outbound (allocate, pick, pack) in one warehouse as a pilot.
• Keep other warehouses on existing Starshipit pick/pack flows.
• Use WMS Override in the integration to share one WMS across multiple child accounts if needed.

This lets you trial WMS outbound in a controlled environment while keeping other operations unchanged.

Model 3: Full WMS outbound with Starshipit for labels only

In this model:

• Orders are allocated, picked and packed in WMS.
• At the end of packing, WMS calls Starshipit to create shipments and print labels.
• Starshipit sends order_shipped events back to WMS to finalise stock.

This is the “end state” for many customers once they are ready to move all outbound flows into WMS.

Using WMS for inventory tracking only (headless)

If you are not ready to change any outbound workflows, you can still use WMS in a headless mode for orders.

What headless looks like

• Enable the WMS integration and send order events from Starshipit.
• Manage products, locations, inbound and stocktakes in WMS.
• Keep using:
  • Starshipit UI or Mobile for picking (if used today), and
  • Starshipit for shipping and labels.
• WMS:
  • Creates/updates orders in PENDING state.
  • Listens for order_shipped events and records stock leaving the warehouse.

In other words, WMS becomes your inventory ledger (especially when combined with proper POs, receiving and stocktakes), while Starshipit remains your operational shipping tool.

Using Starshipit Mobile & web pick/pack with WMS

Many customers already use:

• Starshipit Mobile to scan orders and print labels
• Starshipit pick & pack in the web UI

You do not need to stop using these when enabling WMS.

How this works in practice

1. Orders import into Starshipit from your ecommerce/ERP as usual.
2. Starshipit sends order_created to WMS so the order appears on the WMS orders dashboard.
3. Your team picks and ships using:
   • Starshipit Mobile (scanning orders and printing labels), or
   • Starshipit web pick/pack and label printing.
4. When a label is printed, Starshipit fires order_shipped to WMS.
5. WMS records stock movements and marks the order as shipped in the WMS view.

Over time, you can choose to move some or all orders to full WMS pick/pack while still keeping Starshipit Mobile for other workflows if you wish.

Data flow: orders, labels & stock movements

In a hybrid or headless setup, the data flow looks like this:

1. Orders in

• Ecommerce/WMS/ERP → Starshipit (order creation)
• Starshipit → WMS (order_created webhook)

2. Optional WMS activity

• You may choose not to release or pick these orders in WMS at all (headless).
• Or you may allocate and pick some orders in WMS while others are handled purely in Starshipit.

3. Shipping

• Label printed in Starshipit (web or mobile).
• Starshipit → WMS (order_shipped webhook).

4. Stock movement

• WMS converts the shipped quantity into a SHIPMENT stock movement.
• On hand decreases, committed and allocated (if used) are reconciled.
• Inventory dashboards and movement logs stay aligned to what was actually shipped.

Rollout strategies (pilot vs full WMS)

Because WMS can run alongside your existing workflows, you have flexibility in rollout:

Pilot WMS in a single area

• Start with:
  • Inbound only (POs & receiving), or
  • Inbound + stock management (stocktakes, adjustments), or
  • Full outbound in one small warehouse or channel.
• Leave all other orders running via existing Starshipit processes.

Gradual outbound migration

• Phase 1: Headless – WMS only logs orders and shipments, you ship everything via Starshipit.
• Phase 2: WMS outbound for low-risk SKUs or a small channel.
• Phase 3: Extend WMS outbound to more SKUs/channels once the team is comfortable.

Full WMS adoption

• All warehouses use WMS for inbound, inventory and outbound.
• Starshipit is used for label creation, carrier management and shipping automation.

Best-practice hybrid setups

• Keep one system as order “truth”.
  Make all order edits (items, quantities, addresses) in Starshipit, and let WMS follow via webhooks.
• Use WMS as stock “truth”.
  Perform all receiving, stocktakes and adjustments in WMS, and let it drive inventory reporting.
• Start simple with headless.
  If you’re unsure, first enable WMS purely to track stock leaving via order_shipped, then layer on WMS picking/packing later.
• Segment by warehouse or channel.
  Use WMS outbound for specific warehouses, brands or channels while leaving others on existing workflows.
• Communicate clearly to the team.
  Make it obvious which orders are “WMS orders” and which are “Starshipit-only”, especially during pilots.
• Use dashboards to reconcile.
  Periodically compare Starshipit shipped orders and WMS stock movements to confirm they line up.

FAQ