Feature request for sales channel changes in collections to trigger an update webhook.
Customers of our app rely on webhooks to keep product and collection data in sync with Shopify.
Given the following scenario:
Store owner creates a collection with the “Online Store” sales channel disabled
Adds products to the collection and saves
At a later time, enables the “Online Store” sales channel to display it on the frontend
No webhook is fired when this occurs. In my opinion this should either be emitted by collections/update or collection_publications/update. Otherwise our application is under the impression that no publication has the collection enabled.
@Liam-Shopify This would be ideal, but from my testing and reading the Shopify docs, this won’t work in its current form. A third party app will not receive webhooks related to the “Online Store” sales channel publication.
Yes I have, and it does not. Disabling Online Store then saving the collection as well as enabling Online Store then saving the collection do not trigger any webhooks. Only after subsequent updates (like adding a product or changing collection description) do I get a collections/update webhook.
Thanks @Patrick_S1 - it does look like the collection_publications/update webhook only is triggered whenever a collection publication listing is updated, not if visibility for Online Store is changed.
It doesn’t seem that there is a dedicated webhook that fires only on “collection becomes visible in Online Store” - I’ll connect with the team that owns this area to see if this is on their roadmap to support and to register this as a feature request.
Hi, I’m pretty sure this used to work previously (at least I’ve seen it work in November 2025) that if you would create a collection and then publish it to Online store it would trigger a collections/update webhook.
It seems that possibly something has changed on Shopify side regarding this, or I have a mandela effect…
Hi @Liam-Shopify following up on this topic. From testing, it seems that scheduling the publishing date of a collection also does not trigger a collection_publications/update or collection_publications/create webhooks. If not these either, what action are these webhook topics actually reserved for? i.e. what does cause them to be triggered? Thank you.
We’re also relying on webhooks to keep the data of our shopify app up to date. Today a customer contacted us asking why a collection doesn’t show up in Depict, and it is because they’ve removed it from the online store sales channel and re-added, but we don’t receive any webhooks for it.
We have also tested all topics mentioned in this thread to no avail - and think this might have worked previously.
Please Shopify, if you want people to not hammer your servers with non-incremental ingestions, you have to fix this. As soon as incremental updates become leaky they stop being worth it. We have a weekly reconciliation job and really don’t want to run it hourly, or present a stupid “force sync” button in the UI.
It’s taken us months to handle automated collection updates in a non-leaky way, I’ve even held a talk about it at a Cloudflare conference: Cloudflare Edge Migration, Costly Lessons Learned | Loom
Now despite all work around existing limitations, the system is leaky due to this update missing
@Liam-Shopify I’m testing PRODUCT_PUBLICATIONS_CREATE, PRODUCT_PUBLICATIONS_UPDATE, PRODUCT_PUBLICATIONS_DELETE and also the new webhook in the unstable channel VARIANT_PUBLICATIONS_CREATE, VARIANT_PUBLICATIONS_DELETE Webhooks
I don’t get any webhook on publication changes for the product/variant.
Adding a measurement to this one, since the confirmation above covers collection_publications/update but I do not think collections/update itself was ever answered.
We subscribe to collections/create|update|delete as app-specific subscriptions on API 2026-07. On our staging store, publishing a collection to the Online Store delivered nothing — while the same collection’s updatedAt moved from 12:57:57Z to 15:25:31Z at the moment of the publish. Twelve minutes later a plain rename of that same collection delivered collections/update in 2.2 seconds, and a rename back delivered again in 2.4 seconds, so the subscription was live throughout.
So the publication change is recorded as a mutation of the collection — updated_at proves it — and collections/update is simply not emitted for it, despite firing for every other mutation of the same resource and despite carrying published_at in its payload.
Products do not have this gap: products/update fires for Online Store publish and unpublish alike (measured at ~2.4s, with a second delivery on unpublish). It is specifically collections.
Full write-up with controls, the twelve topics we probed, and a cheap polling workaround is in thread 36439.
