In Starshipit WMS, orders originate from your core Starshipit account and flow into the WMS so the warehouse can allocate stock, pick, pack and ship. Starshipit remains the system of record for orders and shipping; the WMS manages stock and warehouse activity.
The typical sequence is:
- Order is created or updated in Starshipit.
- Starshipit sends an order webhook to WMS.
- WMS imports or updates the order and sets it to PENDING.
- You release the order in WMS when ready to fulfil it.
- WMS allocates stock, creates pick jobs and moves through picking and packing.
- Once shipped in Starshipit, a webhook updates WMS to mark the order as shipped and finalise stock movements.
How orders flow from Starshipit into WMS
Starshipit WMS listens to webhooks from your Starshipit account for key order events:
- order_created – a new order is created.
- order_changed – an existing order is updated (e.g. quantities, items, address).
- order_deleted – an order is cancelled before shipment.
- order_shipped – a shipment is created and a label is printed in Starshipit.
These webhooks are processed through a queue with periodic CRON-based processing, which improves reliability during high-volume periods. Orders may take a few seconds to appear after being created in Starshipit, as they are queued for processing. Duplicate webhook deliveries are automatically deduplicated, and terminal errors do not retry indefinitely.
Order creation
When Starshipit fires an order_created webhook:
- WMS upserts the order into its database (create or update if it already exists).
- All order lines, quantities and references are stored.
- The order appears in the WMS orders dashboard with status PENDING.
Order updates
When an order_changed webhook is received, WMS:
- Refreshes order details (lines, quantities, etc.).
- Cancels any now-invalid allocations or pick jobs for the old version of the order.
- Returns the order to PENDING so it can be re-evaluated and released again with the new details.
Order statuses in WMS
Orders in WMS move through a clear set of statuses:
- PENDING – order has been imported from Starshipit but not yet released to the warehouse.
- RELEASED – order has been released; stock is allocated and pick jobs are created.
- PARTIALLY_SHIPPED – some items have shipped; others remain outstanding.
- SHIPPED – order has shipped in full.
These statuses focus on the warehouse perspective. Internal pick and pack job statuses (e.g. Pending, In Progress, Completed) sit underneath this order-level status.
Orders dashboard
The orders dashboard provides tools to manage and filter your orders efficiently:
- Multi-select status filter — The Starshipit status filter is a multi-select dropdown, allowing you to filter by multiple statuses simultaneously (e.g. show both "Pending" and "Allocated" orders at once).
- Insufficient inventory warning — Orders where the required products have no stock on hand display an insufficient inventory icon, providing an immediate visual indicator of which orders cannot currently be fulfilled.
- Allocatable only filter — Shows only orders that have sufficient stock to be allocated, hiding orders that cannot currently be fulfilled.
- Select all applies to filtered results — The "Select All" checkbox applies only to the currently filtered/visible orders, not to all orders in the system. This prevents accidental bulk actions on unintended orders.
- Session state persistence — Filter selections, active tabs, page sizes and other UI state are persisted in your browser session. Navigating away and returning restores your previous view.
Order detail view
The order detail view shows:
- Process logs — a timeline of system events related to the order (import, allocation, shipment, errors).
- Stock movements — all inventory movements associated with the order.
Order tagging
An Order Tagging dialog allows bulk-tagging selected orders in Starshipit. You can search and select from existing Starshipit tags, enter a custom tag name to create a new tag, and apply tags to all selected orders at once.
Deleting and re-allocating orders
You can:
- Delete allocations for picking jobs from the allocations view.
- Re-allocate orders after deleting allocations, allowing the allocation engine to reassign stock based on current inventory.
- Bulk delete orders — select multiple orders and delete them in bulk. The delete operation is processed in the background, and orders disappear from the UI immediately.
Allocation basics
Allocation is the process of reserving specific stock for an order. It happens when you release an order to the warehouse.
When an order is allocated, WMS:
- Selects suitable inventory for each line (SKU) based on product rules.
- Reserves that stock so it cannot be used by other orders.
- Creates allocation records linking order lines to inventory in specific locations (and batches/serials where applicable).
- Generates one or more pick jobs using those allocations.
Allocation does not move stock physically. It is a reservation step that tells the warehouse what to pick.
Releasing orders to the warehouse
Orders start in PENDING. They are only allocated when you choose to release them.
Releasing a single order
- Open the orders dashboard in WMS.
- Select an order with status PENDING.
- Click Release.
WMS will then:
- Check inventory for each line item.
- Allocate stock according to the product’s allocation strategy and location rules.
- Create a pick job for that order.
- Update the order status to RELEASED.
Releasing orders in bulk
You can also release multiple orders at once. This is useful for:
- End-of-day waves
- Courier cut-off runs
- Store or channel batches (e.g. all orders for a marketplace)
When releasing in bulk, WMS repeats the allocation process for each order and may group items into batch pick jobs (depending on how you configure picking, covered in the next guide).
When an order cannot be fully allocated
If there is not enough stock to allocate the full order:
- WMS may still allocate what is available (based on your configuration) and flag shortfalls, or
- Prevent release and show that the order cannot be allocated due to insufficient stock.
Short orders are typically visible on the inventory dashboard as negative Available quantities or flagged with warnings. You can then decide whether to:
- Wait for incoming stock
- Partially ship
- Substitute products (by editing the order in Starshipit)
How allocation rules choose stock
Allocation rules determine which specific units are reserved when an order is released. They are configured per product (see the Products and Inventory Configuration guide).
Location preferences
WMS typically prefers to allocate from:
- Pick face locations for efficient picking.
- Bulk locations if pick faces do not have enough stock (often via replenishment).
This ensures pickers can work primarily from forward-picking locations instead of climbing into bulk storage for every order.
Product-level strategies
Once suitable locations are chosen, WMS uses the product’s allocation strategy to decide which units to reserve:
- FIFO – oldest stock first.
- LIFO – newest stock first.
- FEFO – earliest expiry date first (for batch-tracked products).
- LEFO – latest expiry date first (specialised scenarios).
For Batch or Serial tracked items, allocation works at the batch/serial level so the correct identifiers are reserved for the order. These are then validated during picking and packing.
Replenishment when pick faces are empty
If a product is configured to use pick faces, you may not keep all stock in the forward locations. Instead, a smaller quantity sits in pick faces and bulk holds the rest. When an order is released:
- WMS tries to allocate from the pick face first.
- If the pick face does not have enough but bulk does:
- WMS can create a Replenishment job to move stock from bulk to the pick face.
- The order’s release may be held until replenishment is completed.
Replenishment jobs are visible in the appropriate dashboard and typically have a status such as READY to indicate they are waiting to be processed. Once completed, you can retry releasing the order so allocation can use the newly topped-up pick face.
Batches and multi-order workflows
WMS supports multi-order and batch workflows that build on allocation. Examples include:
- Batch picking – combine items from multiple orders into a single pick job.
- Pack Now / Batch Pack Now – expedited flows that allocate and complete picking in one step and send orders directly to a packing bench.
When you create a batch:
- Orders are still individually allocated.
- WMS groups allocations into one or more batch pick jobs.
- The batch typically has a Batch Pick ID for reference.
These workflows help reduce walking time and speed up processing for waves of orders. Full details are covered in the Picking and Packing guide.
How order changes, shipments and cancellations sync
Shipments
When you print a label or ship an order in Starshipit, it triggers an order_shipped webhook to WMS. On receiving this, WMS:
- Marks the order as SHIPPED or PARTIALLY_SHIPPED, depending on what was sent.
- Finalises allocations and pick/pack jobs for the shipped items.
- Creates shipment stock movements to decrease on-hand inventory.
- Logs any package or carton usage, where applicable.
Cancellations
If an order is cancelled before shipping, Starshipit sends an order_deleted webhook. WMS will:
- Cancel allocations and return reserved stock to general availability.
- Cancel or adjust any pick and pack jobs related to the order.
- Attempt to remove the order from batch pick jobs if it was part of a group.
In complex batch scenarios, removal can sometimes cause conflicts (e.g. a JOB_CONFLICT), which may require manual clean-up, but the overall goal is to avoid picking or packing stock for cancelled orders.
Order changes
As noted earlier, order_changed webhooks ensure that:
- The WMS always reflects the current truth from Starshipit.
- Old allocations and pick jobs based on outdated data are cancelled.
- The order is returned to PENDING for re-release with the new details.
Best-practice order and allocation setup
- Keep Starshipit as the source of truth.
Make order edits (items, quantities, addresses) in Starshipit so changes flow cleanly into WMS. - Use clear release rules.
Decide when orders should move from PENDING to RELEASED (e.g. payment confirmed, stock available, carrier cut-off windows). - Align allocation strategies with product types.
Use FEFO for perishable goods, FIFO for most standard items, and Serial tracking for high-value or regulated stock. - Monitor failed or partial allocations.
Use inventory dashboards to spot orders that cannot allocate and address those SKUs (purchase more, substitute, or split shipments). - Plan replenishment around order volume.
Ensure pick faces are replenished before you release large waves of orders to minimise delays.
FAQ
You can keep shipping from Starshipit as you do today. If the WMS integration is enabled and order events are sent, WMS will still track allocations and stock movements, and still ship the orders. You may see this referred to as headless mode - this just means Starshipit WMS is running in the background tracking inventory while you continue to drive your operations from Starshipit**.** Releasing orders and using pick jobs is recommended when you want structured warehouse workflows, but it is not mandatory for every account.
The order will remain in RELEASED status with allocated stock. If the order is later cancelled in Starshipit, the order_deleted webhook will tell WMS to free that stock and cancel related jobs.
Yes. You can delete existing allocations from the allocations view and then re-release the order so WMS recomputes allocations based on the current inventory state.
No it does not - Starshipit WMS will allocate from PICK_FACE locations.
For exploding bundles, WMS allocates stock from the component SKUs rather than the bundle SKU itself. For require stock bundles, WMS allocates stock against the bundle SKU’s own inventory. Behaviour follows the bundle configuration you set in the product record.