Shopify Events vs webhooks: field-level triggers and custom GraphQL payloads

Every Shopify app that reacts to store data eventually writes the same unhappy function. You subscribe to products/update, you receive the entire product on every change, and because the payload does not tell you what changed, you diff it against a copy you stored last time to work out whether the one field you actually care about moved. On a catalog of any size, the overwhelming majority of those deliveries are noise you paid to receive, parse, store, and discard.

Shopify's next-generation Events are built to delete that function. On July 21, 2026, at DotDev, they gained metafield triggers and a batch of new topics, which is the point at which they start covering real production use cases. This post is about what actually changes in your app, and how to decide when to move.

The core difference in one sentence

A webhook subscription says "tell me when a product changes" and gets a fixed payload. An Event subscription says "tell me when this specific field on a product changes, and when you do, run this GraphQL query and send me the result".

That moves three responsibilities from your handler to the platform: deciding whether a delivery is relevant, deciding what data to include, and telling you which field moved.

The row that matters most is the third one. include_fields on a webhook makes the payload smaller; it does not stop the delivery. triggers on an Event is pre-qualification at the source: if the field did not change, nothing is sent, and your endpoint never wakes up.

What a subscription looks like

Events are declared in shopify.app.toml, and only there. A price-tracking subscription reads roughly like this:

1[events]2api_version = "unstable"3 4[[events.subscription]]5handle = "price_sync"6topic = "Product"7actions = ["update"]8triggers = ["product.variants.price", "product.variants.compareAtPrice"]9uri = "/api/events/price_tracker"10 11query = """12query priceSync($productId: ID!, $variantsId: ID!) {13  productVariant(id: $variantsId) {14    id15    price16    compareAtPrice17    sku18  }19  product(id: $productId) {20    id21    title22    status23  }24}25"""26query_filter = "product.status:'ACTIVE'"

Each field is doing a specific job:

• handle is a unique identifier scoped to your app, which means you can have several subscriptions on the same topic for different purposes instead of one overloaded endpoint that switches on payload contents.
• topic maps to a GraphQL type from the Admin API (Product, Customer), not to a slash-separated string. actions are standardised to create, update, and delete.
• triggers is the field-level pre-qualification, written in dot notation. Omit it and you get every change to the topic, which is webhook behaviour.
• query is standard GraphQL defining the payload you want back, subject to complexity limits. This is where you stop receiving 40KB of product you did not ask for.
• query_filter runs after the query and suppresses the delivery conditionally. Fields referenced here have to appear in the query, which is why product { status } is selected above even though the app mostly cares about price.

The payload tells you what changed

This is the part that removes stored state from your app. The delivery carries your query result, the variables that were resolved, and an explicit list of the fields that triggered it:

1{2  "data": {3    "productVariant": { "id": "gid://shopify/ProductVariant/456", "price": "24.99" },4    "product": { "status": "ACTIVE" }5  },6  "fields_changed": [7    "product[id: 'gid://shopify/Product/123'].variants[id: 'gid://shopify/ProductVariant/456'].price"8  ],9  "query_variables": {10    "productId": "gid://shopify/Product/123",11    "variantsId": "gid://shopify/ProductVariant/456"12  }13}

Look at fields_changed. It is not a field name, it is a path with IDs resolved along it, so on a nested change you know which variant of which product moved without walking the payload to find out. The shadow copy of every product you were keeping purely to compute diffs stops earning its keep.

What July 21 actually added

Two things, and the second is the reason to pay attention now.

More topics. Apps can now subscribe to Order, Collection, InventoryItem, InventoryShipment, and Location, alongside the existing Product, Customer, and ProductVariant coverage. Inventory and location coverage in particular is what makes Events viable for the fulfilment and ERP-sync category of app.

Metafield change triggers. You can now trigger on changes to specific metafields, by namespace and key, across Product, Order, Customer, Collection, and Location. ProductVariant metafields come through the Product topic. Both $app metafields and regular metafields work, and normal access control applies: your app has to have access to a metafield to subscribe to it or receive it in a query.

How to decide what to do

Events is preview software, so the honest recommendation is not "migrate." It is "find out what you would migrate, and stop building things that Events will make obsolete." Three concrete moves:

1. Audit your subscriptions for diff-only topics. For every webhook topic your app subscribes to, ask what fraction of deliveries lead to an actual action. Any topic where the answer is under a few percent is a subscription that exists only to detect a change, and it is a direct Events candidate.
2. Stop building payload-diffing infrastructure. If you are about to add a stored-snapshot table so you can compute what changed, that table has a defined shelf life now. Weigh a simpler interim approach against it.
3. Prototype one subscription on the unstable version. Pick the noisiest topic you have, write the equivalent Event subscription, and measure the delivery volume difference on a development store. That number is your migration business case, and you will want it written down before you argue for the engineering time.

Keep both mechanisms in mind for the long run, too. Webhooks still cover every Shopify resource and support flexible delivery destinations; Events cover a preview subset with far more precision. They coexist in the same shopify.app.toml, and Shopify's own docs frame them as complementary rather than as a straight replacement. The realistic end state for most apps is Events for the high-volume topics where precision pays, and webhooks for the long tail.

The through-line worth taking from this release is not the TOML syntax, which will change. It is that Shopify is moving app integration from "receive everything, sort it out downstream" to "declare precisely what you need." Declarative subscriptions are cheaper to run, easier to reason about, and considerably easier for an AI agent to generate correctly, because the intent is in the configuration instead of buried in a handler. That pattern is going to keep showing up.