More control over commerce updates with Next Gen Events

With the 2026-10 API version Next Gen Events, Shopify's successor to classic webhooks, is now generally available. Events give you more customization than classic webhooks, letting you choose what changes your app receives, and what data comes with the payload.

If your app keeps track of collection memberships, for example, finding out that a collection changed is only part of the work. You still need to know which product joined or left. With classic webhooks, that can mean fetching the collection's products, comparing them with your saved list, and then updating your app. You're doing all of that work to identify one change.

We built Events to make this easier. Your subscription tells us which changes your app cares about and what data it needs to process them. We send you the change, the affected resource IDs, and the result of your GraphQL query together.

Anchor to Tell us what your app cares aboutTell us what your app cares about

You configure Events subscriptions right in your app's shopify.app.toml configuration file. An event has three components:

• triggers: Which changes matter to your app. For example, a product joining or leaving a collection, or a variant's price changing.
• query: What data you need when that happens. Write a GraphQL Admin API query, and we'll include its result in the payload. You can include related data and metafields too.
• query_filter: Which results your app needs to receive. For example, you can limit deliveries to only products with an ACTIVE status.

The trigger and query are independent. A change to one field can trigger a query that fetches the other data your app needs. The query filter then checks that result to decide whether to deliver it. For more on how triggers, queries, and query filters work together, see the Events overview.

Anchor to Receive the change and the data you need togetherReceive the change and the data you need together

Let's continue to use collection memberships as an example. Your app maintains a search index, and you need to update it whenever a product joins or leaves a collection.

You can subscribe to collection.products and use the collection and product IDs directly in your query:

[events]
api_version = "2026-10"

[[events.subscription]]
handle = "collection-membership"
topic = "Collection"
actions = ["update"]
triggers = ["collection.products"]
uri = "/api/events/collections"

query = """
  query CollectionMembership($collectionId: ID!, $productsId: ID!) {
    collection(id: $collectionId) {
      id
      hasProduct(id: $productsId)
    }
  }
"""

When product 456 is added to collection 123, you receive a payload like this:

{
  "topic": "Collection",
  "action": "update",
  "handle": "collection-membership",
  "data": {
    "collection": {
      "id": "gid://shopify/Collection/123",
      "hasProduct": true
    }
  },
  "fields_changed": {
    "added": [
      "collection[id: 'gid://shopify/Collection/123'].products[id: 'gid://shopify/Product/456']"
    ],
    "updated": [],
    "removed": []
  },
  "query_variables": {
    "collectionId": "gid://shopify/Collection/123",
    "productsId": "gid://shopify/Product/456"
  }
}

Your app now knows which product joined which collection:

• The action is update because adding a product changes the collection's membership.
• The query tells you that hasProduct is true. That query runs as part of your subscription, so you don't need to make another API call after receiving the delivery or fetch the collection's full product list.
• fields_changed.added tells you what changed.
• query_variables gives you both IDs.

The query result reflects the state when the query runs, so use fields_changed to understand the change and data for the current context. The delivery structure guide has more examples.

Anchor to More topics to build withMore topics to build with

We started the developer preview with Product and Customer. We've expanded our coverage to many more key types across Admin GraphQL:

• Merchandising: Product and Collection
• Customers and companies: Customer and Company
• Orders, fulfillment, and returns: Order, FulfillmentOrder, Refund, and Return
• Inventory and locations: InventoryItem, InventoryShipment, InventoryTransfer, and Location
• Content: Article, Blog, and Page
• Custom data: MetafieldDefinition, Metaobject, and MetaobjectDefinition

Each topic has its own supported triggers, query variables, and access scopes. Check the Events API reference for the changes you want to subscribe to.

Anchor to Get more out of your subscriptionsGet more out of your subscriptions

It can be tempting to copy your existing payload into a GraphQL query and subscribe to every change. That gets you familiar data, but it also carries over a lot of the work your app was already doing.

Start with what your app needs to do when something changes, then shape the subscription around that. In the collection example, we only need the affected membership. Loading every product in the collection on each delivery adds work without helping us process that change.

The Events optimization guide walks through choosing specific triggers, querying the affected resource, and splitting subscriptions while keeping the data your app needs. It also explains the complexity limit Shopify places on your queries and how to check that your queries stay within that limit before releasing your configuration.

As you move over to Events from classic webhooks, measure the deliveries your app receives, the size of each payload, and the follow-up API calls it makes. Those will tell you where the change is helping and where there's more work to do.

Anchor to Get startedGet started

Your existing classic webhook integrations will continue to work. You can use both in the same app and move workflows over one at a time. For topics or subscription patterns Events doesn't support yet, keep using classic webhooks.

• Moving from Webhooks to Events?: We recommend starting with identifying a workflow where your app is receiving a lot of updates and discarding most of them, or making another API call on every delivery. Look at what your handler actually does, which changes it needs, and what data it reads. That gives you the starting point for your subscription. Check out the migration guide to get started.
• Brand new to both classic webhooks and Events?: To get started, use Shopify CLI version 4.83 or later and follow the getting started guide. Set your events API version to 2026-10 and choose the topic and triggers your app needs from the reference.
• Already using the Events developer preview? Just update your events API version from unstable to 2026-10, including any subscription-level overrides. Review the versioned topic reference, then test and deploy the updated configuration.

We'd love to hear what you build with events, and where you're getting stuck. If a missing topic or trigger is blocking your migration, tell us which workflow you're trying to move over in the developer community.