Shopify’s Next-Generation Events: A First Look From Developer Preview

If you’ve built more than one Shopify app, you’ve hit this problem: you subscribe to products/update because you need to know when a price changes, and now your handler fires for every update to that product: title edits, tag changes, description tweaks, all of it. You either refetch the whole object and diff it yourself, or you process a pile of events you don’t actually care about. There’s never been a way to tell Shopify “only tell me when this specific field changes.”

Shopify just started fixing that. Next Generation Events is now in developer preview, and we got a close look at it from the inside: Harshdeep Singh Hura, Shopify’s Senior Product Manager for Webhooks, ran a hands-on workshop on it at dotdev 2026. Here’s what it actually does, how it works under the hood, and where it still has rough edges.

What’s Actually New

Today’s webhooks are entity-and-action level: products/update, orders/create, and so on. You get a payload, and figuring out what changed (or whether you even care) is on you.

Next Generation Events moves that filtering to subscription time instead of after delivery. You declare, per subscription:

• A topic: maps to a GraphQL type, like Product or Customer.
• Actions: standardized to create, update, delete at the entity level.
• Triggers: a pre-filter on specific fields (e.g. product.variants.price), so the event doesn’t even fire unless one of those exact fields changed.
• A query filter: a further filter on the returned data itself (e.g. only ACTIVE products), so irrelevant events get skipped entirely rather than delivered and discarded.
• A custom query: a standard Admin GraphQL query you write yourself, so the payload contains exactly the data your app needs and nothing else.

That last point is the part that changes how you build integrations. Instead of a generic payload plus a follow-up API call to get the fields you actually need, the subscription is the query. One round trip, shaped by you.

How It’s Configured

Subscriptions currently live in shopify.app.toml:

[[events.subscription]]
handle = "price_sync"
topic = "Product"
actions = ["update"]
triggers = ["product.variants.price", "product.variants.compareAtPrice"]
uri = "/api/events/price_tracker"
query_filter = "product.status:'ACTIVE'"
query = """
query priceSync($productId: ID!, $variantsId: ID!) {
  productVariant(id: $variantsId) {
    id
    price
    compareAtPrice
    sku
  }
  product(id: $productId) {
    id
    title
    status
  }
}
"""

Read that top to bottom and it’s basically self-documenting: fire on Product updates, but only when a variant’s price or compareAtPrice actually changes, only for active products, and hand back exactly the fields this handler needs: nothing about tags, descriptions, or images ever shows up.

One constraint worth knowing before you design your triggers: only source-of-truth fields qualify. Calculated or derived fields (Shopify’s own example is product.description) and auto-updated timestamps (product.updatedAt) aren’t valid trigger paths, since they change as a side effect of something else rather than being the thing that actually changed.

Every delivery includes some standard metadata alongside your custom query result: fields_changed (the exact paths that triggered the event), topic, action, handle, and query_variables (the IDs available for any follow-up queries you still need). If a payload gets too large, Shopify sends a download URL instead of the full body, the same pattern Bulk Operations already uses, so if you’ve built against that, this will feel familiar.

Delivery isn’t limited to plain HTTP endpoints either: Google Cloud Pub/Sub and Amazon EventBridge are both supported, which matters if your event processing already lives in one of those pipelines rather than behind a public webhook URL. For HTTP deliveries, verify the Shopify-Hmac-Sha256 header before trusting a payload, same as classic webhooks. For idempotency, use Shopify-Webhook-Id as your dedup key (it’s unique per delivery) while Shopify-Event-Id identifies the underlying event and can appear across more than one subscription if you have several watching the same change.

What Harshdeep Showed Us at dotdev 2026

The workshop made this a lot more concrete than reading the announcement did. Harshdeep walked through configuring a subscription live, from an empty events.subscription block to a working triggers + query_filter combo, and it was genuinely satisfying to watch a noisy Product topic collapse down to only the handful of events an app actually cared about.

The detail that stood out most: metafields can already be used as triggers today, in preview, across Product, ProductVariant, Order, Customer, Collection, and Location. That’s a real gap in the classic webhook model closed: until now, there was no way to fire only when a specific metafield changed without diffing the whole object yourself.

[[events.subscription]]
handle = "product-handle"

topic = "Product"
actions = ["update"]
triggers = [
  "product.variants.metafield(namespace:'custom', key:'workshops').value",
  "product.metafield(namespace:'$app', key:'workshops').value"
]

That’s a metafield on the product itself and one on a variant, both usable as precise triggers in the same subscription (namespace and key included), so you’re not limited to your own app’s metafields either.

The Q&A afterward mostly circled the same question every attendee had: is this ready for production yet? The honest answer, consistent with the preview status, was no: not yet, but soon. On the roadmap side, there were clear signals that topic coverage is the near-term priority (as of today, Collection, Customer, InventoryItem, InventoryShipment, Location, Order, and Product are already supported, with more entities landing through the rest of 2026), followed by pull-based delivery and GraphQL-managed subscriptions instead of TOML-only. Nothing was promised with hard dates, but the direction was unambiguous: this is meant to eventually replace the classic webhook surface entirely, not sit alongside it as a niche option.

Where It’s Still Rough

This is a developer preview on the unstable API version, and it shows:

• Topic coverage today spans Collection, Customer, InventoryItem, InventoryShipment, Location, Order, and Product, with more entities expanding through 2026. Metafield triggers specifically cover a slightly different set for now: Product, ProductVariant, Order, Customer, Collection, and Location.
• 250 query complexity points is the current cap during preview: enough for a focused subscription query, not for anything sprawling.
• TOML-only configuration. Subscriptions can’t be managed via GraphQL mutations yet, and queries have to be inlined in the TOML file rather than referenced from a separate file.
• No dedicated testing tooling yet: you’re validating subscriptions against a real store for now.
• Shopify CLI 3.92 or higher required to deploy events.subscription config: an easy thing to trip on if your app’s tooling is pinned to an older CLI version.

None of that is disqualifying for experimentation, but it does mean this isn’t something to wire into a production integration today.

Why This Matters Beyond the API Surface

For anyone building sync services, price trackers, inventory automations, or AI-driven workflows on top of Shopify data, the current webhook model has always meant paying a tax in extra API calls and filtering logic just to figure out if an event mattered. Next Generation Events removes that tax at the source: less noise in, less filtering code to maintain, and a payload shaped around what your app actually does with it.

That’s exactly the kind of platform shift worth tracking closely if Shopify integrations are part of your stack: it’s easy to build against today’s webhook model and then have to rework it once the new one becomes the default. If you’d rather have a team already watching Shopify’s platform changes and architecting around them than discover this on your own timeline, that’s what our Dev Retainer is built for, particularly the Growth Engine and Integrated Partner tiers, where this kind of platform-level work lives.

If you’re already experimenting with Next Generation Events and want a second set of eyes on your subscription design, or want help thinking through the migration once it’s production-ready, contact our team: we’re happy to help.