Gareth Wilson
Shopify Next Generation Events: Devs react to the biggest webhook overhaul in years
Last week Shopify dropped its Next Generation Events developer preview. It's 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 a "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 mentioned that the math on Shopify webhooks is brutal:
“We looked at all our webhooks for the last while and the math came out to like 95% of webhooks are just discarded or no-op eventually... no matter what we do, we have to continue scaling up with the amount of webhooks that come in.”
Sandesh Kulai
Founder @ STOQ
That cost is concrete. For STOQ, webhook ingestion accounts for roughly half of their AWS bill:
“Out of our AWS bill, half of it is pretty much just consuming webhooks, queuing them, making sure we can manage it. And if Shopify is coming in and telling me, hey, you don't have to worry about that anymore, here's a thing to help you bring your bill down by 50%, 75%... that's like somebody giving me money for free.”
Sandesh Kulai
Founder @ STOQ
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. The opportunity here isn't just cost but correctness. Less noise means fewer downstream queues, fewer enrichment calls, fewer cascading failures during BFCM:
“Last BFCM we had an insane number of webhooks to the point where our dashboard would go down because we're running a monolith... the workers have to scale up but our database connections eventually end up running out. So everything ended up being a mess, even though we thought we scaled up for it really well.”
Sandesh Kulai
Founder @ STOQ
Throwing the kitchen sink at it: the consensus is good
Shopify could have shipped as a set of narrower fixes, like better filtering on products/update, a new topic for inventory, gradual cleanup, etc. But they didn't. Next Generation Events is a parallel system, which everyone agreed was the right call.
“Them throwing the kitchen sink is the right thing to do. I'm glad they did it... Managed pricing launched a couple of years ago and it shipped in such a beta feature set with no ability to charge usage pricing, for example. And that basically meant nobody could use it properly. But this time around, they've just given you the whole thing and been like, hey, go crazy.”
Sandesh Kulai
Founder @ STOQ
Jordan made the case from the other direction: incremental tweaks to the old webhooks weren't really an option.
“If the product update webhook had changed and dropped some of the fields, there would be outrage. People would be screaming because that webhook has been stable for years and years... Changing a webhook would cause so much outrage that there's very little options. You either introduce weird webhook topics like product update dot something — which becomes a strange syntax — or you go with this approach.”
Jordan Finners
Founder @ Pimsical
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 with these changes.
The complexity didn't disappear
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 take:
“You're just trading that complexity for complexity elsewhere. Otherwise with webhooks at the minute, you either have to scale up to handle all that load, you have to use a tool like Hookdeck to dedupe and evaluate those, or you have to build all your own logic. So you're just trading the complexity — it's a case of where you want to handle it.”
Jordan Finners
Founder @ Pimsical
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 need for polling for reconciliation isn't off the table.
“If there is guaranteed delivery, that would be incredible. It would solve a lot of headaches and reduce a lot of work in terms of doing that reconciliation loop... but the reconciliation loop does get a little bit easier because you've already written the query effectively in GraphQL. So hopefully you can migrate that over to a bulk job more easily.”
Jordan Finners
Founder @ Pimsical
Worth noting: GraphQL-based subscription management is also on Shopify's roadmap. Today, subscriptions are managed via the app's TOML so a change rolls out to all merchants at once. For app developers who like to test 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.
“It's a very easy yes, especially because the teams tried it out and the feedback is that it's ready to go... yeah, day one, we're in.”
Sandesh Kulai
Founder @ STOQ
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.
“I'm a bit of an event-driven architecture geek, admittedly... as more systems get more complex, polling just doesn't work as you scale. I'd be really interested in this as the start, because what Shopify does does leak out into other platforms, both e-commerce and not.”
Jordan Finners
Founder @ Pimsical
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:
“There's one specific provider that sends literally every single event that could possibly happen for loyalty and rewards and points. Points go up, points go down, scale to a different tier — literally. So for a Plus merchant with tons of customers, that was our big issue... I'm hoping that this kind of a thing is also a signal for other providers to make things easier.”
Taylor Page
Co-founder @ Shop Dev Alliance
The parallel is hard to miss: Stripe quietly stopped calling them webhooks two years ago. Shopify is doing the same with Next Generation Events, not webhooks. The category is shifting and the language is shifting with it.
Our take
This is a big change for Shopify developers and the ecosystem. It meaningfully reduces the cost of webhooks and makes them significantly more useful for most apps and developers. We expect that this will drive increase adoption for Shopify events as an integration point rather then fully relying on pooling as many developers do today.
However, it remains the responsibility of the developers to consider server processing failures, throughput capacity, observability, idempotency, security, ordering. Hookdeck's Event Gateway enables you to solve many of these problems today, for Shopify events but also any webhook you receive from other integrations and vendors.
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.