May 21, 2026 · 4 min read · Kilat Labs

Shopify Next Gen Events end the webhook glue era

Shopify's Next Gen Events bring field-level triggers, GraphQL payloads and edge filters. The middleware tax on Plus integrations is finally going away.

Shopify just put Next Gen Events into developer preview, and it quietly rewires how every serious Shopify Plus integration should be built from this quarter forward. Field-level triggers, custom GraphQL payloads, edge filters: the webhook glue layer most agencies have been carrying for years is now optional.

What changed

On May 19, 2026, Shopify shipped a developer preview of Next Generation Events. The headline is that event subscriptions stop being "tell me when a product changes and I will figure out what changed and what to do." Subscriptions now declare three things up front: the fields you care about, a GraphQL query that defines the delivery payload, and a query filter that decides whether to deliver at all.

The preview currently covers Product and Customer topics on the unstable API version. Every delivery includes a fields_changed list with full entity paths and IDs, plus the query variables Shopify used to render the payload. Subscriptions are written in shopify.app.toml, version controlled alongside the rest of the app config. The matching May entries on the Shopify developer changelog for customer accounts and the unified branding API both lean on this same delivery model.

Why it matters for premium studios in Asia

Most Shopify Plus integrations we inherit have the same shape. A webhook arrives. A worker fetches the full object back from the Admin API because the webhook payload is missing half the data. The worker diffs against a cached copy in Redis or Postgres to figure out what actually changed. Then it decides whether the change is relevant or whether it should drop the job on the floor. Half the code, half the latency, half the bugs in this layer exist solely because the webhook does not know what we care about.

Next Gen Events deletes most of that. A subscription is now a declarative contract. You say "deliver only when these fields change on active products, with this exact payload shape." The over-fetching round trip is gone. The diff-against-cache step is gone. The throw-it-away-after-inspection step is gone. For a premium e-commerce build, that is one less Redis cluster, one less worker pool, one less class of subtle data race during catalogue migrations.

The other quiet win is the toml-based configuration. Webhook subscriptions have historically been spaghetti. Some apps created them via the Admin API during install, others through dashboards, others manually after merchant calls. Diffing what was subscribed across staging and production was painful. Putting subscriptions in the same file as app config means a code review now covers the entire integration surface. For agencies that ship work to merchants in different markets, with different compliance constraints, that is a real audit story.

The catch

Two topics in preview is not a production stance. Order events, fulfillment events, inventory events: none of the integrations that actually drive revenue are covered yet. The unstable API version means the schema for payloads, filters and changed-field lists can move under your feet without notice. Anyone wiring this into a live integration before it leaves preview is making a bet that the shape will not change in ways that need a rewrite.

The right play is to pilot Next Gen Events on a non-critical pipeline. Catalogue enrichment that mirrors Shopify products to an external PIM is a good candidate. So is customer segmentation that watches Customer fields for the marketing stack. Run it in parallel to your existing webhook for a quarter. Measure the delivery accuracy of the query filter against the false-positive rate of the current pipeline. That number alone will sell the migration to whoever signs off on it.

What we would actually change this quarter

For studios shipping new Shopify Plus integrations between now and Q4 2026, three concrete moves.

First, stop building new event handlers that assume the webhook payload is incomplete. Design the contract on the producer side. Write the GraphQL query that defines exactly what the consumer needs, then make the subscription deliver that. The handler becomes a pure function of the payload. No more "fetch and reconcile" preamble.

Second, audit your existing webhook subscriptions. Most stores have stale ones. Some were created by past app installs that have been removed. Some fire for fields no one reads anymore. The toml-based model is a forcing function to clean this up before you migrate, not after. We typically find 30 to 40 percent of webhook traffic on a mature Plus store is doing nothing useful.

Third, push back when a client asks for "real-time" sync between Shopify and a downstream system. Real time usually means a five-figure budget for a queue, a worker pool, idempotency keys, and on-call coverage. With query filters and field-level triggers, the volume of events you actually need to handle drops by an order of magnitude. Pair that with the kind of AI-native dashboards a merchant ops team actually reads, and the honest answer in many cases is "you do not need real-time, you need filtered events with a one-minute SLA," and Next Gen Events finally makes that the easy path.

Where to dig deeper

Related reading

Want this done right on your store?

We engineer premium e-commerce end-to-end, Magento Hyvä, Shopify Plus, mobile and automation. A two-week store audit turns ideas like the one above into real numbers and a prioritised roadmap for your store.

Get new posts in your inbox

Two a month at most. Hyvä, automation, motion budgets and the boring parts of shipping. No filler, no spam.

We use your address only to send new posts. Unsubscribe any time.