Collection_publications/* and product_publications/* never fire for Online Store — the subscription is accepted without error

Webhooks and Events
6

TL;DR of my previous post, which ran long:

Publishing a collection to the Online Store emits no webhook on any topic. The same action on a product emits products/update.

That asymmetry decides what workaround is available for each:

  • Products need nothing special. Skip product_publications/* entirely — subscribe to products/update and read the publication status off the resource. It fires for publish and unpublish alike, in about two seconds.
  • Collections have no event-driven option at all. Every workaround I could find is polling. We ship one: diff the set of published collections against what the index holds, on a timer.

Worth pulling across from the sibling thread — in 27906, @Ilja_Ganulevics recalls this working before:

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…

That is an explicitly hedged recollection rather than a measurement, and it describes create-then-publish rather than a toggle on an existing collection. But it is checkable against Shopify’s own change history, and it lines up with what the API still shows today: a publication change moves the collection’s updatedAt. Shopify records it as a mutation of the collection and simply does not emit collections/update for it.

My recommendation: emit collections/update for Online Store publication changes.

It looks like the smallest change that resolves this:

  • it matches what products/update already does, so the two resources stop behaving differently;
  • it leaves collection_publications/* and collection_listings/* scoped to the subscribing app’s own sales channel — the documented convention, which nothing here needs to disturb;
  • the mutation is already recorded, so this is about emitting an event that already has a trigger, not modelling a new one.

The alternatives look larger: widening the publications topics to cover the Online Store, or granting read_product_listings to non-sales-channel apps, both touch the permission model.

One note on Next Generation Events, in case it comes up as the answer here. Long-term it does look like the better home for this — field-level triggers over resourcePublications would express exactly what is wanted. But as of the 27 May 2026 developer preview it covers Product and Customer on unstable only; collections are not in scope, with more “rolling out through 2026”. So I don’t think it is a reason to leave this open in the meantime — if anything it argues for restoring collections/update now and letting Events supersede it whenever collections land.