Hi,
I wanted to share a challenge we’re running into with product update webhooks and get some input from the team.
Context:
we have an app that reacts to product changes. We need to track product data, variant data, inventory, and metafields on both products and variants. Because of that, we can’t use the built-in de-duplication. We have to listen to every update by subscribing to the update date.
The problem
The problem is that the webhook doesn’t tell us what actually changed. So every time we receive one, we have to pull the full product data from the GraphQL API to figure out if anything relevant happened. For merchants with complex catalogs: many metafields, or some with 2000+ variants on a single product, this gets slow and expensive. Even for simpler catalog, the volume makes it difficult to sustain. We end up fetching a lot of data just to find out nothing meaningful changed.
The thing is, everyone ends up paying for those no-op cycles:
- Us as an app provider: extra server cost fetching data we didn’t need
- Shopify: unnecessary API requests that could have been avoided
- The merchant: slower updates, even when nothing actually changed for them
Our estimate is that if we knew what triggered the update (even just which fields changed), we could skip more than 90% of those API calls.
This also connects to pricing. Webhook volume ends up being our biggest infrastructure cost, but it’s not something merchants control directly. Other apps they install can trigger a constant stream of updates. So we can’t (and don’t want to) bill based on that, and we also can’t predict it upfront for a new merchant.
Is there any ongoing work or discussion around including change context in the webhook payload (e.g. which fields were updated)? Or any recommended pattern for filtering no-op webhooks without having to call the API every time that would work when we need nested data from variants, metafields, inventory, etc..?
Thanks in advance