For years now we’ve subscribed to the INVENTORY_LEVELS_CONNECT webhook topic for all of our client shops. The behavior we’ve always seen in the past was:
When a client assigns our inventory location on an existing product variant, an inventory_levels/connect webhook gets fired off with our location ID in it
When a client removes our inventory location from an existing product variant, then later re-adds our location on that variant, an inventory_levels/connect webhook gets fired off with our location ID in it
However, today it was brought to our attention that a client assigned several variants to our location but no inventory_levels/connect webhooks were sent to us. I have already verified that we have an active webhook subscription for that topic/client.
I have also reproduced this on a Dev Store to an extent:
Let’s say I have 3 locations in my shop. When I create a new product variant assigned to 2 of those locations the variant creation process fires off inventory_levels/connect webhooks for the 2 locations initially assigned on the variant. But when I add the 3rd location to the variant after the fact, no inventory_levels/connect webhook is sent out.
Has there been some change to the behavior of the INVENTORY_LEVELS_CONNECT topic that we’ve overlooked, or is this a bug?
I’m seeing the same behavior. It seems like the webhook only fires during product/variant creation, but not on location updates after being created. I’ve also checked that neither products/update nor inventory_items/update fires, too.
I’m able to replicate this behaviour on my test store as well. At this time I’m currently discussing this with our developers internally to confirm the expected behaviour and any issues heres, and we’ll keep you updated in this thread as soon as we have any further information to share.
I just wanted to keep you updated here and let you know that we have confirmed this is not expected behaviour, and our developers are continuing to look into this further and work towards a fix for this.
Has there been any update on this issue or any kind of expected resolution date? We’ve had more and more clients reaching out to us about this being broken.
@Kellan-Shopify while this bug is being investigated I’d like to add another question to this:
In looking for a workaround we tried making use of the fetch_stock callback that Shopify sends to us any time a variant is assigned to our Fulfillment Service location. When a client adds a single variant to our location from the Product Variant page in the UI this seems to work as expected: we receive a callback with that 1 sku explicitly mentioned in the URL params, and we’re able to make use of that.
However, we’ve noticed that the fetch_stock callbacks don’t seem to fire when a client assigns our Fulfillment Service location to multiple Variants from the Inventory → Bulk Edit page. This limits the effectiveness of that callback, as our primary use case for this is when a new client is onboarding and wants to add our location to all/many of their variants at once. Is this also a bug, or is it expected that Shopify won’t fire the callbacks in this scenario?
Confirming this is still happening as of April 2026. We first noticed it in mid-March. The webhook does not fire when assigning an existing location to a product variant. Any visibility on a timeline for a fix would be really appreciated. Thank you!
I’m sure you have plenty going on day-to-day so I hate to sit here and constantly create more notifications for you, but since I haven’t received a response I need to ask again: has there been any movement at all or any timeline set in terms of a fix for this issue?
As I described in a follow-up above, the fetch_stock callbacks are also proving to have limitations that prevents them from being a true replacement for inventory_levels/connect functionality, so we still have clients pushing us for answers on this.
At this time there are no updates to this we can share, though I can confirm that our developers are aware of this behaviour and looking into this further. However unfortunately we are unable to provide any estimated timeframes for when this will be resolved. Though we will be sure to keep you updated here when we have any more information to share or when a fix is released!
Regarding the fetch_stock callback, the scenario you described I believe should trigger this HTTP Request, as described in the Shopify.dev documentation:
If fulfillment_service.inventory_management is set to true , then Shopify makes a request to the /fetch_stock endpoint for the inventory of an individual SKU when the product is set up initially, when its SKU is changed in the Shopify admin, or when its inventory management is set to use the fulfillment service. Please note that SKU strings are case-sensitive at Shopify, and the SKUs returned from the /fetch_stock endpoint will be matched to the Shopify product SKUs respecting the case.
I’ve tested this on my own test store, and I can confirm that I’m receiving the fetch_stock requests when assigning inventory management on variants individually, but I’m not receiving the requests when adding multiple sku’s via the Inventory Bulk Editor in the admin.
I’ll discuss this with our developers as well to confirm if this is expected behaviour, or if this is related to the inventory_levels/connect issue as well, or if this requires a separate issue investigation.
We are seeing this issue resolved on our end now. The inventory_levels/connect webhooks are firing as expected for our app. Thank you to everyone for the updates throughout this thread.
I can confirm after discussing with our developers today, that the inventory_levels/connect webhook issue has been resolved on our end, and you should be receiving new webhooks whenever a product variant is connected to the fulfillment service location in the admin.
Regarding the fetch_stock request not being sent when connecting locations in the Bulk Editor. We can confirm that this issue is still occurring at this time, and that we are continuing to look into this issue further with our developers. We’ll keep you updated here when we have more information to share.