October 8, 2026 · Muhammad Rehan · More by Muhammad Rehan
Shopify Moves Draft Order Holds From Reserved to Committed
Shopify is consolidating draft order, transfer, and shipment inventory holds into the committed state — here's what integration code needs to check.
On August 5, 2026, Shopify began consolidating how it represents in-progress inventory holds: quantity previously tracked under the reserved state for draft orders, transfers, and shipments is moving into the committed state. Any integration that reads inventory quantities by name needs to understand exactly what that does, and doesn't, change.
What the migration actually moves
Shopify's stated reason for the change is alignment: committed already represented inventory that's spoken for but not yet fulfilled on orders, and this migration brings draft-order, transfer, and shipment holds into that same bucket rather than leaving them split out under reserved. It's a one-time data migration, and it only touches active draft orders and open transfers or shipments that are still holding inventory at the moment the migration runs. Completed, cancelled, or already-released holds are untouched, because they no longer hold any reserved inventory to move.
What it leaves untouched
Shopify is explicit about the boundaries of this change. available and on_hand quantities are unaffected, total inventory doesn't change, and nothing moves between a sellable and an unsellable bucket — the migration only shifts quantity between two states Shopify describes as both "unavailable" to sell. What a buyer can actually purchase is unchanged. Both reserved and committed also remain valid, independently queryable names on InventoryLevel.quantities(names: [...]) — no field is removed or renamed, so a query that asks for reserved keeps returning a number without erroring.
The integration risk: reserved no longer means what it used to
That last point is exactly what makes this change easy to miss. Because quantities(names: ["reserved"]) still works, there's no error to catch and no deprecation warning to trip a build. But the number it returns for affected shops will decrease, with a matching increase under committed, because the holds that used to live in reserved have moved. Any app, dashboard, or sync job that was using reserved specifically as a signal for "this is a draft order or transfer/shipment hold" — rather than "this is held by something, we don't know what" — will start under-reporting that signal and needs to read committed instead going forward.
What to check in your sync and reporting code
Concretely: audit any code path that filters or alerts on InventoryLevel.quantities(names: ["reserved"]) and ask whether it was using reserved as a proxy for draft-order and transfer/shipment activity specifically. If so, point it at committed. Inventory-adjustment reports that break out changes by state should also expect a one-time correction entry when the migration runs for a given shop, covering only the draft orders and transfers/shipments that were active at that moment — historical data before the migration isn't rewritten.