Changes to setting inventory levels at disconnected locations

[Daniel_Ablestar]

Previously, if we used the GraphQL API to try and set inventory at an unconnected location we would get a The specified inventory item is not stocked at the location error if the inventory item was not connected to the location. Now the API seems to allow it but the display in the admin is a little odd. Does any one know if this is an intentional change or something that will be reverted?

I saw some recent changelog posts about inventory levels but I couldn’t find an exact answer.

Setting inventory for unlinked locations

I’m not seeing the The specified inventory item is not stocked at the location error anymore, for example in this query the inventory is not connected to the location, however it succeeds:

mutation {
  inventorySetQuantities(input: {
    name: "available",
    reason: "correction",
    quantities: [{
      inventoryItemId: "gid://shopify/InventoryItem/47940391403706",
      locationId: "gid://shopify/Location/82014863546",
      quantity: 123,
      changeFromQuantity: null
    }]
  }) @idempotent(key: "be42e255c039") {
    inventoryAdjustmentGroup {
      id
      changes {
        location {
          id
          name
        }
      }
    }
    userErrors {
      field
      message
      code
    }
  }
}

{
  "data": {
    "inventorySetQuantities": {
      "inventoryAdjustmentGroup": {
        "id": "gid://shopify/InventoryAdjustmentGroup/40328111358138",
        "changes": [
          {
            "location": {
              "id": "gid://shopify/Location/82014863546",
              "name": "A Demo Warehouse"
            }
          },
          {
            "location": {
              "id": "gid://shopify/Location/82014863546",
              "name": "A Demo Warehouse"
            }
          }
        ]
      },
      "userErrors": []
    }
  }
}

Admin Display

Now, I will see the updated inventory in the admin for A Demo Warehouse, even though the location isn’t connected:

What’s odd to me is that if I run the query above again (with a new idempotent key), the amount gets added to the on-hand total:

However, if the variant is connected to the location, subsequent inventorySetQuantities replace the inventory level, they don’t add to it (which I think makes sense). Is the adding of inventory levels when a location is not connected intentional?

Thanks

[Alan_G]

Thanks for flagging @Daniel_Ablestar - we have made some changes to how inventory levels work, but I’m looking into this internally to confirm expected behaviour for you. Will loop back once I have more to share.

[Junior_Mendes]

Hello @Alan_G just wanted to follow up here as we’re seeing the exact same behavior across multiple stores.

Previously, attempting to set inventory on an unlinked location would return:

“The specified inventory item is not stocked at the location”

Now:

1. The mutation succeeds even if the inventory item is not connected to the location

2. The quantity is added to On Hand only (not properly activated/linked)

3. Re-running the same mutation adds to the quantity instead of replacing it

4. Once the location is actually connected, behavior switches back to expected (set vs add)

This creates a tricky state because:

• We can no longer rely on errors to trigger activation flows

• Inventory can accumulate in a “detached” state

• Ensuring correctness now seems to require additional activation checks or pre-connection logic, which increases API usage significantly at scale

From what we can tell, this looks like a shift toward allowing inventory levels to exist independently of an active location (possibly related to the new isActive field?), but without clear enforcement or visibility in the API response.

Questions:

• Is this behavior intentional and here to stay?

• Is there a recommended pattern to ensure inventory is only set on active/connected locations without adding extra read calls?

• Should apps now explicitly call inventoryActivate prior to setting quantities in all cases?

Would love to hear if anyone from Shopify or others have guidance, this has a pretty big impact on inventory sync strategies.

Thanks!

[Alan_G]

Hey @Junior_Mendes - thanks for following up here.

I checked back on this, and the behaviour where repeated inventorySetQuantities calls could add to the on-hand quantity instead of replacing it was not expected. A fix has been deployed on our end and is currently rolling out.

The broader inventory changes around inactive inventory levels are intentional, so you may still want to account for isActive / inactive inventory levels when deciding whether a location should be stocked. But inventorySetQuantities should not be compounding quantities like the examples above.

If you don’t see this improving over the next few days, please get in touch with us again and share the shop ID plus a recent request timestamp or x-request-id, and we can take another look on our end.

[Daniel_Ablestar]

Thanks @Alan_G, I did some tests today and everything works as you described. Really appreciate you tracking this down!

[Alan_G]

Hey @Daniel_Ablestar glad to hear and no worries at all, let me know if we can help out further!