Three primitives — bins (shelves and racks), counts (per-bin inventory count sets), and purchase orders (reading purchase order data) — are shipping early in the unstable version of the GraphQL Admin API. They can only be called once the feature preview is enabled on a development store.
It exists only in the unstable version of the GraphQL Admin API.still under active development, so the point is that you can send feedback on the schema and behavior before it reaches a stable version.
Turn on "Physical inventory feature preview" on a development store (or an existing store) and build and test against that.
Calls from a store that hasn't enabled the preview return an access error . This is not a feature that works uniformly across every store.
The post explicitly lists the following three under "What's included."
Named storage placesinside a location— like a "shelf" or a "rack". You can create and update them, andread the on-hand quantity held by each bin.
inventoryCountCreate With the mutation, youset the on-hand quantity of a specific inventory item in a specific bin. It is not an increment or decrement — it declares "this is the actual count on that shelf."
Purchase order data can be read read via the GraphQL Admin API. What is explicitly listed as retrievable is the purchase order itself / its line items / its supplier.
Create a new development store, or use an existing one.
Enable "Physical inventory feature preview" on that store.
Configure your app so thatall physical inventory queries / mutations are called against the unstable version.
| Item | What the post says | What we can infer |
|---|---|---|
| bins | Stated explicitly Create, update, and read on-hand | Bin master data can be built and synced from an external system |
| counts | Stated explicitly inventoryCountCreate sets the on-hand quantity for items in a bin |
Stocktake results can be written back |
| purchase orders | Stated explicitly (read only) PO itself / line items / supplier | You can read incoming shipments. Writing isnot stated |
| API version | unstable only | The timing of the stable release isnot stated. Assume breaking changes |
| Target stores | Preview-enabled stores only; stores without it get an access error | Whether it can be used on production stores isnot stated(the guidance assumes a development store) |
| Integrating bins with existing location inventory | Only says to refer to the guide | In the post itself,not stated. Check the guide |
| Bin hierarchy, capacity, and supported plans | — | not stated |
It is explicitly described as "under active development." Field names, arguments, and return values can change, so it is safer to puta thin adapter layer in your appin between, rather than wiring your domain model directly to the shape of the API.
Calls from stores without the preview enabled return an access error. If your app is distributed to multiple stores, a design thatdetermines at runtime whether the store can use the physical inventory features and switches the UI accordinglyis required.
inventoryCountCreate is described as "setting the on-hand of a specific item in a specific bin". Since it is not a delta-based API,accumulate scan results and send the final value— client-side aggregation is required.
The post only lists read.For now you cannot build a design that assumes purchase orders are created and updated on the Shopify side. Keep the master record for purchase orders in your external systems (ERP / WMS) and simply read it from Shopify.
The post explicitly frames the goal as being able to give feedbackbeforeit reaches stable — feedback on the schema and the behavior. If something is missing for Japanese 3PL / warehouse operations (location naming conventions, lots and expiration dates, bin-to-bin moves), thentesting it and sending feedback before the stable schema is locked in is the highest-leverage move. Conversely, it is too early to build production systems around the current schema.
inventoryCountCreate at the bin level: implement that stocktaking flow, keeping a per-bin history of committed counts.