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

Webhooks and Events
1

A regular (non-sales-channel) app can subscribe to COLLECTION_PUBLICATIONS_* and PRODUCT_PUBLICATIONS_* with zero errors, and then never receive a delivery for anything published or unpublished to the Online Store. The subscription looks healthy in every API response, so nothing tells you your coverage is imaginary.

I ran a positive control so this isn’t a “your endpoint is broken” or “delivery was slow” report.

Setup (dev store, 2026-07): an app holding read_publications + read_product_listings (no write_publications, not a sales channel). Five subscriptions created via webhookSubscriptionCreate, every one returning userErrors: []:

  • COLLECTION_PUBLICATIONS_CREATE / UPDATE / DELETE
  • PRODUCT_PUBLICATIONS_CREATE / DELETE

Eight real publication transitions, one delivery:

# Action Object Publication Delivery
1 publish collection Online Store — none
2 unpublish collection Online Store — none
3 re-publish collection Online Store — none
4 publish collection the subscribing app’s own publication :white_check_mark: collection_publications/create
5 auto-publish on create product Microsoft Copilot (a different app’s publication) — none
6 publish product Online Store — none
7 unpublish product Online Store — none
8 re-publish product Online Store — none

The one delivery arrived 1.4 seconds after the change (x-shopify-triggered-at: 2026-07-29T16:06:15.845Z, received 16:06:17), carrying publication_id = the app’s own publication. So the topic, the subscription and the delivery path all work — they are simply scoped to the subscribing app’s own publication.

Confounds ruled out:

  • Not latency: the successful delivery took 1.4s; the Online Store transitions were given 20+ minutes.
  • Not a missing topic in the pinned version: these topics exist in both 2025-10 (what webhookSubscriptionCreate pins subscriptions to) and 2026-07.
  • Not a dead subscription: all five verified still present, with the correct callback URL, after the test.
  • Not scope-related: the app holds read_publications, and no scope change was made during the experiment.
  • All transitions were made through the Admin UI and confirmed server-side via resourcePublications (isPublished + publishDate).

What I’d like to ask:

  1. If own-publication scoping is intentional, please reject the subscription for apps that don’t own a publication — or document it prominently on the topic reference. Silently accepting a subscription that can never fire is the worst of both worlds: an app ships believing it has coverage, and only discovers otherwise when merchant data quietly goes stale.
  2. If it is not intentional, then Online Store publication changes are missing deliveries.
  3. Either way: is there any supported way for a non-sales-channel app to learn that a product or collection was published to / unpublished from the Online Store, without polling? For a merchandising app such as Depict this is a real gap — an unpublished collection has to disappear from our UI and a re-published one has to come back, and today the only mechanism we have is periodic reconciliation plus inferring publish state from products/update payloads. I’d be glad to be told I’ve missed the obvious topic.

Happy to share the store, the subscription ids and the raw capture with staff.

2

Hey @depict_daniel - thanks for reaching out. This looks like it may be the same issue discussed here: Changing sales channel does not trigger webhook

Beyond keeping Depict synchronized when Online Store availability changes, are there any other workflows or use cases this blocks for you?

We already have this documented as a feature request, and we’ll add your context and pass the feedback along on our end for sure - hope to hear from you soon.

3

Thanks Alan — and yes, 27906 looks like the same underlying gap seen
from the product side.

To answer your question, here is what it actually blocks for us. Some
context first: we are a collection merchandising app. Merchants curate
and order their collection pages in our app, and we write the
resulting order back to Shopify, so our view of “what is live on the
storefront” has to match theirs.

1. Collections disappearing and reappearing in the merchant’s UI.
When a collection is unpublished from the Online Store we stop
offering it as merchandisable; when it is republished it has to come
back. With no publication event, our only incremental signal is a
publishedOnPublication field we piggyback onto the product webhook
payloads. So a republished collection reappears only if some product
in it happens to change; otherwise it waits for our next full
reconcile, which runs weekly. A merchant who republishes a collection
and opens our app right after can find it simply missing, with nothing
to explain why.

2. Unpublished products lingering in merchandised output. A
product that leaves the Online Store should leave the grid we compute
and write back. Because a pure publication change never reaches us, it
stays in the ordering, and since we aggregate over the members we
believe are live it also skews the per-collection numbers we compute:
in-stock counts, out-of-stock badges and sell-out ordering. Those are
merchant-visible numbers that drift quietly, which is worse than an
obvious error.

3. It forces polling we would otherwise not run. Detecting
publication changes is one of the main reasons we do periodic full
reconciliation for every shop. Event-driven publication changes would
let us cut a meaningful amount of scheduled bulk-operation load, on
our side and on yours.

There is also a knock-on effect for merchants who use publication
state as a workflow: staging a seasonal collection unpublished, then
publishing it at launch. From our side that launch is invisible until
a product changes or the weekly sync lands, so the merchandising they
set up may not be reflected at the moment they actually need it.

One thing I would separate from the feature request itself: today’s
behaviour is not only a missing capability, it is a silent one.
webhookSubscriptionCreate accepts COLLECTION_PUBLICATIONS_* and
PRODUCT_PUBLICATIONS_* without error for an app that can never
receive them, and the subscription then reads back as perfectly
healthy. Whatever happens with the broader feature, rejecting those
subscriptions — or documenting the own-publication scoping on the
topic reference — would stop other apps shipping with coverage they do
not have. That part looks independent of the harder work.

Happy to go into more detail on any of it.

4

Hey @depict_daniel this is exactly the context I needed, really appreciate it! Could you DM me the dev store, app/subscription IDs, timestamps from the test, and the raw capture you mentioned? If you have a rough sense of how many shops encounter this, that would also help quantify the impact, but it isn’t required.

I’ll set up the DM on my end here in just a sec and speak with you there.