reserved to committed in a one-time migrationA one-time data migration that consolidates "inventory that is held but not yet fulfilled" into committed. available and on_hand are unchanged, and there is no impact on how much can be purchased. No fields are removed or renamed.
reserved , but they are moving to committed instead.committed , so everything converges on a single meaning:"held but not yet fulfilled" = committed across the board.
Holds from orders were committed, while holds from draft orders, transfers, and shipments were reserved. The same "set-aside inventory" had to be read in two different places.
committed now represents all inventory that has been sold but not yet fulfilled. Holds from draft orders, transfers, and shipments merge into it as well.
Both are limited to those that are still holding inventory at the time the migration runs .
These no longer hold reserved inventory, so there is nothing to move in the first place.
| Item | Impact | Details |
|---|---|---|
| available / on_hand | No impact | Quantities don't change at all. Total inventory is unchanged too — the only movement is between the two "unavailable" buckets. |
| quantity name | Both stay valid | reserved and committed both remain valid, queryable names going forward. |
| Field definitions | No removals or renames | No API field is removed or renamed. There is no breaking schema change. |
| Available inventory | No impact | The quantity buyers can purchase doesn't change. Nothing looks different on the storefront. |
| Behavior of existing queries | No code changes needed | No code changes are required to keep your queries running.only the returned values shift between the two states. |
| Historical data before the migration | Left as is | Historical data from before the migration is preserved as-is. |
InventoryLevel.quantities(names: ["reserved"]) — list every place your code reads it.
The ones that matter are those reading reserved to detect draft orders or transfer/shipment holds.
Those places should now read committed instead. Everything else needs no code changes.
| What your app does today | What happens after the migration | What to do |
|---|---|---|
quantities(names: ["reserved"]) is what you read |
In affected shops, reserved values go down, and by that same amount, committed goes up | Check required Revisit your logic assuming these values will shift |
| You use reserved to identify draft orders and transfer/shipment holds | that information disappears from reserved | Change required From now on, read committed |
| You're worried whether your queries will keep working | the queries themselves won't break | No action needed code changes are not required |
| You sync inventory based on available / on_hand | nothing changes | No action needed |
For merchants using inventory adjustment reports (the type that breaks adjustments down by inventory state),reserved values moving into committedshows up directly in the report.
At the moment the migration runs, one-time correction entry is recorded. This covers only draft orders that are active and transfers/shipments that are open at the time of migration.
No fields are removed or renamed; both reserved and committed remain queryable. What breaks isn't the type, but the implicit assumption that "reserved = draft order holds" .
Only the breakdown of unavailable changes; on_hand stays the same.If your aggregation looks at reserved + committed combined, the impact is zero. Conversely, only the places that read it on its own will change.
Only inventory that is on hold at the time of execution is affected. Completed, canceled, and released holds are out of scope.No explicit migration date or time has been statedso factor in that daily batch diff detection may spike temporarily.
A one-time correction entry appears in the inventory adjustment report.It is easy to misread this as "an unexplained adjustment showed up"so if you have anomaly detection rules on the BI side, give your team a heads-up in advance.
The impact centers on the InventoryLevel 's quantities(names: [...]) field, plus the per-name InventoryQuantity object.No mention of which API version this applies from, or how affected shops are determined — verify whether you are affected by measuring it on your own store.
quantities(names: ["reserved"]) , and after the migration the value silently drops. No error is raised, so nobody notices."reserved" , then sort each usage into "hold detection" and "just displaying a total," and switch only the former to committed references.names: ["reserved","committed"] lets you fetch both and migrate in stages while comparing them.committed alone can express "spoken for but not yet fulfilled," so the aggregation logic collapses into a single path.