SHOPIFY INVENTORY

Shopify Inventory Replenishment to Bin: What Assumptions Should Developers Change

Developers should reserve a Bin-level inventory model and treat the preview with caution.

Shopify’s inventory system has primarily operated around Locations: where a product inventory item is stored in a warehouse, store, or fulfillment center, how much is available for sale, in transit, committed, or in stock. For many merchants, this model has been sufficient to support front-end sales and basic fulfillment.

However, for ERP, WMS, 3PL, and inventory-related apps, this granularity has always been too coarse.

What happens in a warehouse is often not just “a certain SKU has 100 units in a certain warehouse.” More commonly, the situation is: this SKU has 40 units on shelf 3 in Warehouse A, 20 units in the replenishment area, and 5 units in the exception area. Different locations can affect picking paths, counting methods, replenishment actions, and exception handling.

Shopify is now adding this layer of capability.

According to the Shopify.dev 2026-07 unstable GraphQL Admin API documentation, Shopify provides a Physical inventory feature preview, covering capabilities such as bins, counts, and purchase orders. Here, a Bin is defined as a named storage within a location, which can be understood as shelves, shelf positions, or physical storage locations.

Developers can create or update a bin using inventoryBinUpsert, and can also set the on-hand quantity of a specific inventory item in a specific bin using inventoryCountCreate.

This indicates that Shopify’s inventory model is beginning to further subdivide from the Location level. It does not mean that Shopify has provided a complete WMS. A more accurate assessment is that Shopify is adding a layer to the inventory infrastructure that is closer to the warehouse floor.

Shopify Inventory Object Relationship: Location remains the inventory aggregation layer, while Bin supplements the expression of internal warehouse locations. Image source: Shopify.dev

Location Remains the Core Layer

To understand this change, we need to return to the existing inventory object relationships in Shopify.

In Shopify documentation, ProductVariant is responsible for customer-facing product variant information; InventoryItem represents the physical goods used for inventory, shipping, and fulfillment; InventoryLevel connects an InventoryItem to a Location to track the inventory status of that product at that location.

InventoryLevel involves states such as available, on-hand, incoming, and committed quantities. Location is the geographical or business site where merchants conduct business, such as a retail store or warehouse.

The core relationship of this model has always been:

An InventoryItem has a set of inventory statuses under a Location.

With the addition of Bin in the Physical inventory feature preview, this relationship has not been overturned. Bins are located within Locations, and Locations still play the role of inventory aggregation, sales availability, fulfillment locations, and business sites.

In the feature preview documentation, Shopify provides a key calculation relationship:

total on-hand at location = unbinnedQuantity + sum of all bin quantities.

This means that Bins allow for a finer physical distribution of on-hand quantities within a Location, but the total at the Location level still exists. The existing inventorySetQuantities continues to work; when developers set inventory at the location level, this quantity will enter the unbinned quantity.

This design is crucial for developers. Shopify has not replaced Location with Bin; rather, it has added a layer beneath Location that can express physical storage locations.

Bin Addresses the “In-Warehouse Location” Issue

Within the currently available documentation, Bins can be understood as named storage within a Location. Its value primarily lies in warehouse management, rather than front-end sales logic.

For WMS and ERP, Bins will at least affect three categories of system design.

First, inventory synchronization cannot only consider item + location.

In the past, many systems only maintained the correspondence between SKU, InventoryItem, Location, and quantity. With the addition of Bins, if an application wants to express real in-warehouse inventory, it will need to additionally maintain the quantity relationship of item + location + bin.

Second, counting will be closer to the warehouse floor.

The Physical inventory feature preview covers counts. The inventoryCountCreate provided in the documentation can set the on-hand quantity of a specific inventory item in a specific bin. This indicates that Shopify is reserving API semantics for “counting by storage location,” rather than just modifying a total for a Location.

Third, exception inventory has a clearer point of reference.

In a model without Bins, the quantities in multiple storage locations, temporary storage areas, return areas, and quality inspection areas within the warehouse often had to be recorded by external WMS, and the aggregated results synchronized back to Shopify. With the introduction of the Bin level, developers have the opportunity to express part of the physical location distribution on the Shopify side.

Expectations need to be controlled here. The current documentation refers to a feature preview and is located in an unstable API. It is suitable for developers to test, research, and adjust data models, but not suitable as the sole dependency for production systems.

This Is Not a Complete WMS Yet

The public page summary of Shopify Editions Winter ‘26 shows that Shopify supports assigning bin locations to SKUs through CSV or the Order Printer app bulk editor to improve picking efficiency.

When this information is viewed alongside the feature preview from Shopify.dev, a direction can be seen: Shopify is incorporating “storage locations” into more official capabilities.

However, based on verified information, it cannot be interpreted that Shopify has built-in a complete WMS.

From the verified information, Shopify publicly mentions bins, counts, purchase orders, and assigning bin locations to SKUs to enhance picking efficiency. This information is sufficient to indicate that Shopify is enhancing its foundational capabilities related to inventory and in-warehouse locations, but it is not enough to support the conclusion that “Shopify has provided a complete WMS.”

A more prudent judgment currently is that Shopify is enhancing its inventory infrastructure to provide a more standardized foundation for ERP, WMS, 3PL, and apps. It will reduce some custom mappings of “in-warehouse locations” between systems, but it cannot yet replace the complete process capabilities of a professional WMS.

Impact on ERP, WMS, and App Developers

What developers should focus on now is not to immediately launch the Bin feature, but to correct model assumptions in advance.

If the system still defaults to “an item in a location has only one inventory quantity,” it will easily get stuck later. A safer design is to break inventory into two layers:

• For external synchronization and fulfillment judgment, still primarily use item + location;

• For in-warehouse distribution and counting records, reserve item + location + bin.

There should be a clear boundary between these two layers. The on-hand quantity at the Location level is an aggregated result; the quantity at the Bin level is a physical distribution. The unbinnedQuantity means that there is still a portion of the inventory within the Location that has not been allocated to a specific Bin.

This will bring a practical issue: when synchronizing between systems, who is the master system for location data?

If WMS is the master system, Shopify’s Bin data may only be the result of synchronization. If the Shopify backend or Shopify app allows editing of Bins, WMS must also handle write-backs, conflicts, and audits. Developers need to design several types of boundaries in advance:

• Who controls the creation and naming rules of Bins;

• How Bin IDs under the same Location map to external warehouse location codes;

• How external systems handle inventory adjustments at the location level entering unbinnedQuantity;

• Whether counting covers a specific Bin or the entire Location;

• Whether the production environment needs a feature switch when the API is still in unstable/feature preview.

These questions are more important than “can a mutation be successfully executed.”

Especially since the fact that inventorySetQuantities is still available means that the new and old inventory writing methods will coexist. Developers cannot assume that all inventory will naturally fall into Bins. Many historical data, third-party apps, manual operations, and old processes may still only write quantities at the Location level.

Impact on Merchants and Service Providers

For merchants, the most direct value of Bin capabilities is to make picking and counting clearer.

If a warehouse has a small number of SKUs and simple picking paths, Location-level inventory may still be sufficient. Introducing Bins will increase the cost of maintaining basic data, including location codes, SKU bindings, counting rules, and employee operation specifications.

If merchants already have multiple warehouses, multiple picking areas, or the same SKU scattered across multiple shelves, Bins will be more meaningful. They can help the system express “where the goods are,” rather than just “whether there is stock in this warehouse.”

Service providers need to avoid over-promising when creating solutions for merchants. Bins can be included in planning as a direction for inventory refinement, but do not package the unstable feature preview as a stable delivery capability. Whether it is actually usable will depend on the merchant’s store backend, API version, application permissions, and Shopify’s subsequent official documentation.

The Spring ‘26 Editions public page summary also mentions that the permitsSkuSharing field has been removed, allowing any fulfillment service to stock inventory across multiple locations. This direction relates to the flexible fulfillment at the Location level, indicating that Shopify is also continuing to adjust the boundaries of fulfillment services and multi-location inventory. Specific API changes should still be based on the corresponding version documentation.

What Can Be Done Now

For developers, a more prudent preparation approach involves three steps.

First, modify the data model to accommodate Bins. Even if not enabled temporarily, do not hard-code the unique inventory assumption of item + location in the core table structure and synchronization logic.

Next, create an adapter. Handle Shopify’s Location-level inventory, Bin-level inventory, unbinnedQuantity, and external WMS location inventory separately to avoid directly binding the preview API deeply into the production main link.

Finally, establish feature switches and version isolation. The Physical inventory is currently a feature preview/unstable, suitable for sandbox stores, test stores, and internal research. Production systems can first retain a compatible entry and expand usage once Shopify advances to a more stable version.

For merchants, the current stage can involve organizing basic warehouse data: Is the Location clear? Is the SKU stable? Is the location naming consistent? Is it really necessary to pick and count by storage location? When basic data is chaotic, enabling Bins in advance will only transfer the chaos into the system.

Shopify is advancing its inventory system towards finer granularity. Location remains the core of inventory aggregation and fulfillment judgment, while Bins supplement the expression of physical storage locations within Locations. For developers, this is not a small field to overlook, but a signal that the boundaries of the inventory system will become finer.

The most appropriate action now is not to rush ahead, but to keep the model flexible, clarify synchronization boundaries, and treat the preview as a research object. Once the API status stabilizes, the real changes will not be to the entire underlying inventory system.