Shopify Next Generation Events: Devs react to the biggest webhook overhaul in years

Last week Shopify dropped its Next Generation Events developer preview — a wholesale rethink of how Shopify pushes data to apps. Webhook topics are being replaced with filterable, GraphQL-defined event subscriptions. Instead of subscribing to products/update and receiving the entire product payload, you declare the event you actually care about, the conditions that should trigger it, and the exact GraphQL shape you want delivered.

It's the most consequential change to Shopify webhooks in years.

To unpack it, we hosted a livestream with three developers who live inside this stuff every day: Taylor Page (co-founder of Shop Dev Alliance and host of Liquid Weekly), Jordan Finneran (founder of Pimsical and organizer of Shopify North), and Sandesh Kulai (founder of STOQ, a Shopify Dev Awards-winning app).

This is a lightly edited write-up of where they land on the news. The tl;dr: It's an overdue, "kitchen sink" approach that's going to ripple well past Shopify in its impact. Let's get into it.

What's changing

Shopify's webhook architecture has carried the same shape for the better part of a decade — subscribe to a topic, receive a fixed payload tied to the old REST API, and deal with the consequences. The biggest consequence is volume, particularly on products/update, where any change to any field (most often inventory) fires the same fat payload to every subscriber.

Next Generation Events flips this. You declare an action (what happened), a trigger (the conditions you want to be notified under), and a query (the GraphQL shape of the payload you want delivered). Coverage starts with products and customers. More topics are coming.

"95% of webhooks are just discarded"

The cost story dominated the first half of the conversation. Sandesh has been telling anyone who'll listen that the math on Shopify webhooks is brutal:

That cost is concrete. For STOQ, webhook ingestion accounts for roughly half of their AWS bill:

The pattern repeats across the ecosystem. Jordan described running pipelines at a previous role that pulled in hundreds of thousands of webhooks a day, the vast majority of which were inventory updates dressed up as product updates. And the opportunity here isn't just cost — it's correctness. Less noise means fewer downstream queues, fewer enrichment calls, fewer cascading failures during BFCM:

Throwing the kitchen sink at it — the consensus: good

There's a version of this change where Shopify ships narrower fixes — better filtering on products/update, a new topic for inventory, gradual cleanup. They didn't. Next Generation Events is a parallel system with a different shape. The room agreed that was the right call.

Jordan made the case from the other direction: incremental tweaks to the old webhooks weren't really an option.

The bigger architectural payoff is that webhook payloads now live in the same schema universe as the rest of the Shopify API. Jordan, who spoke at last year's Editions on REST-to-GraphQL migration, called out that the historical drift between webhook payloads and the GraphQL Admin API has cost the ecosystem real engineering time. Apps have been writing translation layers between two shapes of the same data for years. That goes away.

The complexity doesn't disappear — it moves

Configuring a Next Generation Event isn't free. You define triggers in TOML, you author a GraphQL query, you check the payload, you iterate. For developers used to ticking a checkbox in a settings page, the surface area is bigger.

Jordan's framing of this was:

He also flagged the practical DX gap: types. Being able to generate TypeScript types from the GraphQL queries you write in TOML would change how this feels to use day to day. As of the developer preview, that's not there yet, but it's the kind of thing the ecosystem (or Shopify) should close fast.

His other suggestion is one we think is genuinely useful: a community library of patterns. The number of apps that need "products/update but only when price changes" or "inventory updates for a single location" probably runs into the thousands. Solving that in parallel across the ecosystem is a waste.

Reliability is still the open question

What Next Generation Events does not appear to change (at least not yet, it's just in preview afterall) is delivery guarantees. The mechanics of polling-as-reconciliation aren't off the table.

Sandesh, who met the Shopify team behind the work in the Shopify office, came away with the sense that more is on the way:

Worth noting: GraphQL-based subscription management is also on Shopify's roadmap. Today, subscriptions are managed via the app's TOML — meaning a change rolls out to all merchants at once. For app developers who like to dark-launch a feature on a handful of stores, that's a real constraint until the API lands. Taylor surfaced this from Shopify's own FAQ, and it should reduce some of the "ship to everyone, fix for everyone" pressure that the current model creates.

Until then, Jordan offered a clever workaround for staged rollouts: filter by shop ID in the trigger or return it in the GraphQL query and gate downstream.

When to migrate? Day 1

Everyone on the call put themselves in the "as soon as possible" camp.

Webhooks aren't going away. Both Jordan and Taylor stressed there's been no indication of deprecation, and running the two systems in parallel is a legitimate transition plan. For most apps, the right move looks like picking the high-volume, low-relevance topics first (products/update, customers/update), defining narrow event subscriptions that match how the app actually uses the data, and letting the old webhooks keep flowing until the new path is hardened.

What this means for everyone else

The most interesting question for us at Hookdeck is how much of this propagates. Shopify is influential enough to set patterns the rest of the ecosystem ends up copying.

Taylor came at it from the services side — the everyday reality of loyalty platforms, points systems, and third-party services dumping every state change into a single webhook firehose:

The parallel is hard to miss: Stripe quietly stopped calling them webhooks two years ago. Shopify is doing the same — Next Generation Events, not webhooks. The category is shifting, and the language is shifting with it.

Our take

A few patterns are worth pulling out. The cost story is the loudest, but it's not the most interesting one. The real change is that Shopify is moving from a topic-based push model to a query-based one — closer to a subscription against the GraphQL API than to a classic webhook. That's a bigger conceptual shift than the announcement implies, and it's why the same pattern keeps showing up across other platforms.

Complexity hasn't been removed, it's been relocated. The TOML config and GraphQL queries are real work. Tooling matters here: type generation, query libraries, sane defaults for common patterns. There's room for the community to make this feel as good as it should.

Reliability is the unfinished business. Filtering reduces volume, but it doesn't change the underlying delivery guarantees. Until guaranteed delivery and replay land (and the team seems to be working on it) reconciliation loops aren't going anywhere.

And finally: this is going to spread. The platforms developers spend their days integrating with are watching Shopify, and the move from "webhooks" to "events" (both the architecture and the vocabulary) is a meaningful tell about where the industry is going. It's the same direction we've been pointing at with Event Destinations and the reason we built Outpost the way we did: events delivered straight to message queues and event buses, not just HTTP endpoints.

If you're a Shopify app developer who wants to start filtering, transforming, and routing events into queues today, that's what Hookdeck's Event Gateway does. And if you're building a platform that emits webhooks to your own customers, Outpost is the open-source delivery engine modeled on exactly this shift.

Massive thanks to Taylor, Jordan, and Sandesh for joining us.