Also. Would like to know!!
I run a script that updates 500 metafields assigned to a product. And the shop has 5000 products for sale. Does Shopify send off to N product/update listeners two and a half million webhooks? Or just 5000?
Just trying to get my head around this...
Seems like a lot of webhook traffic that will need responses that wasn't there before.
If it is specific apps syncing between themselves, wouldn't these apps be better served doing this with other methods such as their own APIs than a universal webhook trigger for every app ever?
@Ryan. Excellent question! Imagine that. You are listening to product/update and next thing you know, your App gets hammered with a webhook containing 500 metafields worth of image data. Sweet baby Jesus! And that happens over and over and over... there goes the bandwidth neighborhood.
Hey everyone, thanks for continuing to contribute to this thread. I thought I'd post to give a little bit more context on the change, and why consistency (while certainly not always good) is good when it comes to our metafield webhooks.
A few points worth mentioning :
1) Webhooks were already sent on Metafield changes to Products, but only when the change was done through the Product endpoint rather than the Metafield endpoint. This change makes webhooks fire whenever updated_at is changed on a Product, which is what you'd expect.
2) If you want to recieve metadata in your webhooks, you can. You can also elect not to recieve this metadata.
3) We know that people hate wasting bandwidth on webhooks that have nothing to do with them. In the short term, this is admittedly going to be slightly worse (as a few of you have mentioned).
4) This is the first piece of a more expansive project, to help you recieve only relevant data from webhooks. We know you're tired of getting thousands of webhooks when some other app decides to blast every product with information that isn't relevant to what you do. First, we need to lay a good foundation, consistent behaviour across all resources on Shopify.
Thanks again for your continued involvement in our community. Questions to me - I'll be happy to answer.
Shayne thank you for the long term insight and communication. Please understand reactions here are part of a larger platform problem: feature release without any context of the future.
The older of us are used to platforms doing this while we can see the keystones these things makes providers uneasy and has created a very nasty cycle: feature-release-> obvious problems called out-> soothing message-> vitriol-> problems still exist-> future unknown. The whole playing it close to the vest is a habit that should be addressed before shopify hits 500,000. or 1mil if it already past that.
Shopify releases some great changes but the drum isn't banged unil the day it's released, if at all, or the info is buried in the numerous fragmented content channels.
If we can't plan for it we have to react to it and that is bad business that keeps people from devoting more space to shopify.
This is a problem that we're definitely aware of, and are actively working to resolve. We want you to be confident in our platform, to know that your voices will be heard, and that we're going to build Shopify in a way that makes it as frictionless as possible to build, deploy, and maintain applications within the ecosystem.
There's a fine line that we're treading, trying to show the context that's informing our decisions, without promising features that may be delayed or changed because of the impact on other parts of our constantly evolving platform. That being said, I understand where you're coming from, and I think you're right. From now on - we'll provide more context in feature release notifications. Thanks for your post.
My main concern is that since the body content of product webhook notifications cannot be guaranteed to include the information that changed which caused the webhook in the first place, my apps currently make an API call to get the real current state of the product. I've recently had issues with a massive increase of webhook requests (and this API calls), and I beleive this must be the reason why.
Please, please, PLEASE create some guarantee that the webhook body data represents the most recent changes to its respective product!