Published
Partly, and the distinction matters more than a yes or no.
ShipStation’s internal inventory is more developed than people assume. Its Committed Inventory documentation defines a full set of stock states:
| Term | What it means |
|---|---|
| On Hand | Physical goods at a location |
| Committed | Quantity needed to fulfill all active orders |
| Allocated | On Hand goods reserved against particular orders |
| Available | On Hand minus Allocated |
| In Stock | On Hand minus Committed — what is left to sell |
Allocation is the reservation step. ShipStation describes it as “the process of reserving inventory units for your orders in the Awaiting Shipment status, so you are always certain you have enough available stock”.
So the data to answer “is this order covered” exists in the account.
Two things, and together they are the gap.
Allocation is manual. ShipStation states it plainly: “You are not required to allocate stock to ship orders. Stock will be deducted as you ship, whether you have allocated it or not.” Allocating is something a person does in the grid, not something that happens to every order at import.
Classic automation rules cannot see stock. The criteria list covers fields on the order — weight, destination, tags, totals, requested service. Stock level is not one of them, because a classic rule reads fields already on the order and cannot call out for anything else, and it only fires once at import anyway. Stock that runs out an hour later was never going to re-trigger it.
That second limit is the one that has moved. On accounts with the redesigned Automation Rules screen, a workflow can run on a schedule rather than only at import, and in the accounts I work in that is enough to hold an order when its stock reaches zero. The check runs on a cadence, finds orders whose items have gone out of stock since they landed, and moves them to On Hold.
That is a real answer to the first half of the problem and it is worth setting up if your account has it. The rollout is uneven and none of it is documented, so look in Settings → Automation → Automation Rules in your own account rather than assuming from this page.
The expensive case is not knowing you are short. It is sequencing.
A scheduled check answers “is there any stock left”. It does not answer “which of these orders should get it”, and those are different questions. Zero is a threshold anybody can test. Deciding between claimants is a priority decision, and it has to be made at the moment the orders are competing rather than on the next pass of a cron.
Two orders arrive an hour apart, each needing four units, and you have six. Both are in Awaiting Shipment, both look fine on the grid, and whichever gets packed first takes the stock. If the second one belonged to a wholesale account with a delivery commitment and the first was a single retail unit, you have just made an expensive decision by accident, in the order the picker happened to work.
ShipStation will let you allocate to prevent that, and a scheduled workflow will catch it once the shelf is empty. Neither decides, at the moment the orders land, which of them should have had the stock.
At low volume, allocation by hand is genuinely fine, and the grid is there for exactly this. Assign someone the job daily and it works.
It stops working when the number of short SKUs, the number of orders competing for them, or the number of rules about who gets priority grows past what one person can hold. At that point the decision needs the stock level and the order attributes read together at import, which is logic above ShipStation rather than a setting inside it. That is the kind of thing we build alongside a ShipStation account.
String builds and maintains logic like this inside existing ShipStation accounts — cartonization, rate selection, batching, inventory-aware holds, cold chain rules. No dashboard, nothing for your team to learn.
Typically for operations past 6,000 orders a month with a dedicated fulfillment team.
