Some explanation of the field "sellableOnlineQuantity" and obeserved delay

Hi,

I noticed that variants have a field sellableOnlineQuantity but the documentation around it is not totally clear to me and I’d be happy to get more information about it.

The doc mentions:

The total sellable quantity of the variant for online channels. This doesn’t represent the total available inventory or capture limitations based on customer location.

Does it mean that locations for which “Fulfillment” is disabled won’t be counted in the sellableOnlineQuantity? Is there any other condition involved?

Also it seems that the value for sellableOnlineQuantity is not updated immediately after inventory update. I updated the inventory of a product, then checked multiple over the course of multiple minutes and nothing changed (inventoryQuantity was updated correctly) when I check one day later, the value changed correctly. Is there a known delay you can communicate?

My goal is to find the total inventory for fulfillable locations, and I want to add that this field is doing that, it’s extremely valuable, it helps not having to pull all inventory at all locations, which is expensive in terms of API points and query complexity (for large catalogs it’s way faster to pull just this value).

Thank you!

Hi @Soufiane_Ghzal,

The sellableOnlineQuantity field could be used to find the total inventory across all fulfillable locations, however it’s not always guaranteed to return that exact value, depending on how it’s calculated on the store, with various store settings and variables being considered in it’s calculation.

More specifically, the sellableOnlineQuantity field is calculated to return the MINIMUM value of the following:

  • the total sum of all quantities across all locations (the same as inventoryQuantity

or

  • the MAXIMUM value of:
    • the highest available inventory at any one local pickup location (If local pickup is enabled on the store)
    • the total sum of available inventory across all online fulfillable locations not included in the local pickup calculation above.

Essentially if the store has local pickup enabled, and a single pickup location has more quantity than the rest of the online store fulfillable locations combined, then sellableOnlineQuantity will return the single pickup location quantity, otherwise If the combined online store fulfillable location quantity is greater than the single largest local pickup location quantity, then sellableOnlineQuantity will return the combined online store fulfillable location quantity. It shouldn’t typically return the inventoryQuantity value as that should always be greater than the combined online store fulfillable locations, but will return that in case of unexpected behaviour as a fallback.

Additionally the delay you’re experiencing is expected with this field.

1 Like

Hi @Kellan-Shopify

Thank you for all the explanation. That’s really helpful, and I think it would be valuable to put that down in the actual documentation in case other developers need to understand it.

I tried to stretch my mind a bit more than necessary to understand in which case inventoryQuantity would be less than other values, until I read your final note about it :slight_smile:

Regarding the delay, would you be able to give a rough idea of how long it is usually? Also, this is a computed value from other values, that is updated later. So would it trigger a product update webhook when the sellableOnlineQuantityis eventually computed?

Hi @Soufiane_Ghzal,

So the products/update webhook does get triggered on inventory changes for products, but like the inventory_levels/update webhook, they’re specifically triggered when an inventory level on a specific location is updated, they don’t get triggered when the sellableOnlineQuantity field is updated, since it’s already accounted for with the actual individual inventory level update.

Additionally, we are unable to share any specifics on the expected delay for this field, though testing this on my own store, I can confirm it is being updated within a few seconds of the inventory level update.

If you have any specific examples of products or stores where the sellableOnlineQuantity field is taking longer than a few minutes to update, I may recommend reaching out to our Shopify Support team via the Shopify Help Center with examples, and we can look into it in further detail in an authenticated support interaction to determine if the delay you’re experiencing is expected behaviour or if there’s any jobs we can run our end to force the update if the delay is unexpected.

1 Like

@Kellan-Shopify thanks for the extra details. It seems the delay I observed initially was unusual as now it takes seconds rather than minutes.

Couple of things on this:

It’s a bit of an issue that the webhook product/update does not fire when this field is computed, we cannot use it reliably if that’s the case.

Thanks for recommending going through the help center. However that’s always a last resort. They genuinely do an excellent job for most issues, but for technical problems it’s difficult, they’re not technical staff and we always have to spend a lot of time to convince them that there is an actual technical problem and maybe sometimes it gets escalated. In practice it’s really hard to get things escalated and time consuming. Shopify truly needs a real issue tracking system.

Thank you for your help!

Hi @Soufiane_Ghzal,

I completely understand your concerns with reaching out via the Help Center, though for issues such as these we would need to look into specific store data internally, which requires a fully authenticated support interaction for merchant security, and that’s not something we can do through the Community Forums yet unfortunately.

We do have technically capable escalated support teams available for authenticated support interactions initiated through the Help Center, for example I’m in the Developer Support team myself and my teammates and I would be able to help you look into this in more detail there.

When you reach out to the Support Team via the Help Center, I would recommend including as much context and details as possible to help ensure the frontline Support Advisors know the correct technical team to reach out to, to ensure you can get the support needed for this issue.

In this case, when you reach out be sure to provide us with a specific example of this behaviour occurring, with the following details.

  • product that has the delay on sellableOnlineQuantity updated
  • as exact a timeframe as possible, of when the adjustment was made, and when the field was updated
  • full HTTP details from any API calls adjusting the quantity, and any webhooks received from the initial inventory level update that lead to the sellableOnlineQuantity delay
    • The full plain text HTTP Request, including URL, Body, and Headers (no access tokens)
    • The full plain text HTTP Response, including Body and Headers
  • also you can link this community thread as well, so the frontline Support Advisor knows what we’ve looked at, and knows to reach out to Developer Support for more assistance.

It’s a bit of an issue that the webhook product/update does not fire when this field is computed, we cannot use it reliably if that’s the case.

Regarding the product/update webhook not triggering when the sellableOnlineQuantity field is updated. As mentioned it does trigger when individual inventory levels are updated for products, so you can use those webhooks to see when the inventory on a product is changed to know that you could expect an update to the sellableOnlineQuantity field, then you can calculate the available inventory manually with the inventoryLevel data, or wait a couple seconds for it to update and poll the sellableOnlineQuantity field in an API call to confirm.

I do understand this is not ideal, and I will be submitting some feedback on your behalf internally that we should trigger the webhook for this field update as well. I can see an argument however for why we wouldn’t trigger the webhook for this update, since the actual inventory update is already triggering the webook, and sending a new webook for the sellableOnlineQuantity would add additional noise since the actual inventory adjustment was already accounted for in the previous webhook.

While I can’t guarantee if this will be added or not, I can assure you that our developers and product managers do take all of our merchant and partner feedback with great value when determining future features and platform updates.

1 Like

@Kellan-Shopify I tested the webhook inventory_levels/update and I couldnt find a way to get the variant affected by the inventory update without using an extra graphql request. Is that possible?

Unfortunately it is not possible to get the specific variant information from the inventory_levels/update webhook directly.

The payload for this webhook, looks like this:

{
  "inventory_item_id": 48365093355682,
  "location_id": 69128716450,
  "available": 32,
  "updated_at": "2026-03-13T14:36:11-04:00",
  "admin_graphql_api_id": "gid://shopify/InventoryLevel/103507198114?inventory_item_id=48365093355682"
}

As you can see it returns info about the actual inventory level object, so you’d need to make a GraphQL request querying the inventory level object if you want to get information on any of the variants connected to it.

Specifically, you can use the inventoryLevel query, and retrieve the info from the returned InventoryLevel.item.variants connector, like so:

{
  inventoryLevel(id:"gid://shopify/InventoryLevel/103507198114?inventory_item_id=48365093355682"){
    item{
      variants(first:20){
        nodes{
	      id
          displayName
          title
        }
      }
    }
  }
}

Hi @Kellan-Shopify Thanks for confirming, I’ll open a feature request for this.

On a side note, I was never able to find a list of available include_fields we can add to webhooks, and I always try and see to figure out what’s available.

Is that documented somewhere?

Hi @Soufiane_Ghzal,

There’s no specific list of available fields for webhook customizations with include_fields, as this modification is used to narrow down what is already returned in the webhook payload.

For example with the inventory_levels/update webhook discussed above, if you only wanted to retrieve the inventory_item_id and updated_at fields in the webhook payload, you subscribe the webhook with:

include_fields = ["inventory_item_id", "updated_at"]

More specifically, the include_fields customization does not allow you to request other fields that are not already returned in the base webhook payload.

Here’s a Shopify.dev doc with more information: