Shopify Next Generation Events: granular webhooks with GraphQL

The problem with traditional Shopify webhooks

Anyone who has built an ERP or PIM integration on Shopify knows the problem: every time a product is updated, the webhook fires the entire payload, even if only an irrelevant tag or metafield changed.

This creates three concrete inefficiencies:

• High volume of non-actionable deliveries, consuming network and processing resources
• Structural over-fetching, with unnecessary fields carried in every event
• Application-side diff logic, required to determine what actually changed compared to the previous state

Next Generation Events, now available in developer preview on the Shopify Admin GraphQL API, address all three problems directly.

Three dimensions of granular control

The new system introduces control at three distinct levels: what triggers a delivery, what the payload contains, and what changed.

1. Field-level triggers

With Next Generation Events you can define a subscription on a specific path such as product.variants.price. A subscription configured this way does not fire for changes to the title, tags or other fields: it activates exclusively when the variant price changes.

This eliminates spurious deliveries at the root, without requiring any application-side filtering.

2. Custom payload via GraphQL query

Instead of receiving a fixed payload determined by Shopify, the new system lets you define directly the GraphQL query that populates each delivery. The result is that every event contains exactly the fields needed for processing, with no superfluous fields and no additional API call to retrieve missing data.

For integrations that currently follow the webhook + enrichment API call pattern, this represents a net reduction in the number of requests made to the Shopify API.

3. The fields_changed field

Every delivery now includes a fields_changed field with the explicit list of modified paths, including full path and entity ID. This makes any comparison logic against a previous state in application code obsolete.

Instead of maintaining a local snapshot of the entity and computing a diff on every event, the receiving system can read directly which fields changed and act accordingly.

query_filter: reducing non-actionable deliveries

An additional control mechanism is query_filter, which allows deliveries to be filtered based on the current state of the entity at the time of the event. A typical example: deliver events only for products with status ACTIVE, ignoring drafts and archived products.

Combined with field-level triggers, query_filter makes it possible to build highly precise subscriptions, reducing traffic to receiving endpoints to a fraction of current levels.

Config as code with shopify.app.toml

Next Generation Events subscriptions are configured directly in the shopify.app.toml file, alongside the rest of the application configuration. This means event definitions are:

• Versionable in the project repository
• Reviewable in the code review process
• Reproducible across different environments without manual configuration

For teams managing multiple environments (development, staging, production) or following GitOps practices, this approach removes the dependency on configurations managed manually in the Shopify dashboard.

Practical impact for ERP and PIM integrations

For high-volume catalogs, the combined effect of these changes has a measurable impact on performance and costs:

• Fewer deliveries received thanks to precise triggers and query_filter
• Smaller average payload size thanks to custom GraphQL queries
• Elimination of post-delivery enrichment API calls
• Simpler application code thanks to fields_changed

Integrations that currently process thousands of events per day with a low actionability rate are the ones that benefit most from this architecture.

Recommendations for getting started today

The system is currently in developer preview on the Shopify unstable API, with support for the Product and Customer topics. Before evaluating adoption:

• Audit your current traffic: identify webhooks with high volume and low payload utility — these are the priority candidates for migration
• Test in preview: use the Product and Customer topics available today to validate expected behavior
• Replace diff logic: refactor existing consumers guided by fields_changed
• Configure query_filter: define filtering criteria based on current entity state to eliminate non-actionable deliveries
• Plan the migration: the API is on unstable and is not suitable for production without a migration plan toward a stable version

If you are building or evolving custom integrations on Shopify Plus and want to assess the architecture best suited to your volume and requirements, you can find details about our development services on the Shopify developers pricing page.

Conclusion

Next Generation Events are not just a webhook performance improvement: they redefine the integration model with Shopify, shifting granular control to the developer side. For teams building serious integrations on high-volume catalogs, it is worth exploring this pattern now, before it reaches stability and becomes the expected standard.