The variants field is a top-level payload field. If you have more than one product variant, and even one variant that has a price greater than $10.00, when the product is updated (for example, title is changed) the webhook fires.
The search docs say this, and this works for any positive searches, however any negative (NOT) searches will not trigger the webhook if a single variant does not match.
Eg. 3 variants, sku “x” “y” “z”.
Search for y. Will trigger, because one is y.
Search for NOT y, and it should trigger because one is not y, yet it doesn’t.
This is important because we can’t search for null without a NOT statement ( -variants.sku:* ), and if any variants are not null, even when some are, the webhook will not trigger.
TLDR; ONE variant must match a positive (none-NOT) search, ALL variants must match a negative (NOT) search.
Is this intended or a bug?
Hey @pepsi_max2k, well spotted.
I had a look into this and found the webhook filters docs state that for array fields like variants, the filter matches if at least one element meets the condition. So variants.sku:y fires the webhook if any single variant has SKU “y”. The search syntax then defines NOT as a document-level exclusion, meaning it suppresses the webhook if any element matches. Based on how the docs describe these two rules, -variants.sku:y evaluates as “does any variant have SKU y? If so, suppress.” That gives you the ALL-must-match behavior you described, because it’s NOT(ANY match) rather than ANY(NOT match).
This behavior is consistent with how the search syntax is documented (and standard search engine semantics generally). I’ll flag this as a documentation improvement internally.
Unfortunately, there doesn’t appear to be a way to express “at least one element does NOT match” using the current filter syntax. For your null-SKU use case (-variants.sku:*), the filter will only fire if all variants have null SKUs. If you need to catch products where some variants have null SKUs, the workaround would be to subscribe without that filter condition and handle the check in your application code when you receive the webhook.
Thanks for clarifying this Donal. Does make filtering in null values (to operate on them) a little awkward - whole point of the filter was to not trigger a webhook on things that didn’t need it - but I guess I take what I can get 