Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Shopify will make a one-time move of inventory held by active draft orders, open transfers and shipments from reserved to committed, so committed represents all allocated but unfulfilled inventory.
- available, on_hand and total inventory remain unchanged, as does the quantity buyers can purchase. The move is between two unavailable states.
- reserved and committed remain queryable, with no field removal or rename, but logic identifying particular allocations through reserved needs adjustment.
- Migration affects only active records still holding inventory at runtime. Completed, cancelled or released allocations are not rewritten, and historical data remains unchanged.
- Read both states before and after rollout, reconcile by location and SKU, and establish a migration window for one-time correction records and alert jumps.
This changes classification, not sellable inventory
If your app reads InventoryLevel reserved or committed quantities, reports inventory by state or triggers replenishment alerts from them, this change needs handling. At its core, an allocation moves from one unavailable-state bucket to another.
available, on_hand and total inventory do not change. A drop in reserved or increase in committed therefore does not by itself indicate lost, released or newly added stock. Systems concerned only with sellable inventory and not allocation sources generally need no business-rule change.
Which records change and which do not
Inventory still held by active draft orders, open transfers and shipments at migration time moves from reserved to committed. Order inventory was already in committed, so the new definition brings all allocated but unfulfilled stock into one state.
Completed, cancelled or released allocations do not change because they no longer hold stock. This is a one-time migration, not a recomputation of all historical time series; reports may show a state jump at the migration point.
The API and fields are not being removed
InventoryLevel.quantities(names: [...]) still queries reserved and committed; neither field is removed or renamed. Existing queries will not fail solely from a schema change, but the business meaning of returned values changes.
If a system uses reserved specifically to identify draft-order or transfer allocations, it should read committed after migration and distinguish origins through business objects or other evidence. Do not assume committed represents only ordinary orders.
Inventory four dependency types first
Search code, SQL, dashboards and alerts for reserved, committed, available and on_hand. Mark which uses are presentation only and which participate in sellable-stock calculations, replenishment, risk controls or financial reconciliation.
Pay special attention to logic that adds reserved and committed and subtracts them from available again. Official guidance says available is unaffected, so duplicate subtraction creates false shortages. Validate every custom formula against conservation across the full set of inventory states first.
Reconciliation before and after migration
Before migration, save reserved, committed, available, on_hand and timestamps by store, location and SKU, then retrieve the same dimensions afterward. For affected records, reserved should fall and committed rise correspondingly, while available, on_hand and total quantities stay constant.
Sample active draft orders, open transfers and shipments to confirm allocations still exist. Mark the report’s one-time correction separately rather than counting it as real replenishment, sales or loss.
Canary rollout, alerts and stop conditions
Run old and new definitions in parallel first rather than immediately dropping reserved. Reduce noise from state-bucket jumps during the migration window, while continuing to monitor available, on_hand and totals. Anomalies in these invariant quantities cannot be explained away by the official migration.
If available changes, totals fail to reconcile, an allocation is counted twice or many objects cannot be identified, immediately stop deployment and automatic adjustments. Preserve InventoryLevel responses, object IDs, locations, SKUs and times, then verify with Shopify support.
Separate API errors from network errors
For GraphQL field or permission errors, first check API version, scopes, query and response errors. Move to the proxy connection failure checklist only with clear DNS, TLS, connection timeout or proxy-authentication evidence.
Teams needing stable access to Shopify documentation and admin can visit the PuppyIP website to learn about fixed network egress. The network path cannot change inventory states, migration batches or merchant permissions.
Sources
Frequently Asked Questions
Will this migration reduce available inventory?
No. Shopify explicitly says available and on_hand are unaffected. Quantities move only between the unavailable reserved and committed states.
Will the reserved field be removed?
No. Both reserved and committed remain queryable; the classification of affected allocations changes.
Which records will migrate?
Active draft orders, open transfers and shipments still holding inventory at migration time are affected. Completed, cancelled or released records are unchanged.
Will all historical reports be recalculated?
No. Official guidance describes a one-time migration with historical data unchanged. Inventory-adjustment reports will contain one correction record.
Must existing queries change immediately?
Query syntax generally continues to work, but business logic using reserved to identify these allocations must read committed and revalidate its definitions.
Which migration anomalies require stopping?
Stop automatic adjustments and preserve evidence if available or on_hand changes, totals do not reconcile, allocations are counted twice or cannot be matched to business objects.