--- title: >- More control over commerce updates with Next Gen Events - Shopify developer blog description: >- Fewer deliveries, richer payloads, no follow-up queries: Events is a declarative replacement for classic webhooks, now generally available across 18 topics. source_url: html: >- https://shopify.dev/changelog/blog/next-generation-events-are-now-generally-available md: >- https://shopify.dev/changelog/blog/next-generation-events-are-now-generally-available.md metadata: effectiveApiVersion: 2026-10 affectedApi: - displayName: Events & webhooks handle: webhook primaryTag: displayName: API handle: api secondaryTag: displayName: New handle: new indicatesActionRequired: false createdAt: '2026-09-09T17:28:31-04:00' postedAt: '2026-10-01T13:30:00-04:00' updatedAt: '2026-10-01T12:59:30-04:00' effectiveAt: '2026-10-01T13:00:00-04:00' --- October 1, 2026 # More control over commerce updates with Next Gen Events Fewer deliveries, richer payloads, no follow-up queries: Events is a declarative replacement for classic webhooks, now generally available across 18 topics. [Join the discussion](https://community.shopify.dev/c/webhooks-and-events/18) [Share your feedback in the forum](https://community.shopify.dev/c/webhooks-and-events/18) DateOctober 1, 2026 Version[2026-10](https://shopify.dev/changelog?api_version=2026-10) FlagsNew SurfacesAPI Affected APIs[Events & webhooks](https://shopify.dev/changelog?api_type=webhook) 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. ## Tell us what your app cares about You configure Events subscriptions right in your app's `shopify.app.toml` [configuration file](https://shopify.dev/docs/apps/build/cli-for-apps/app-configuration#events). 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](https://shopify.dev/docs/apps/build/events). ## Receive 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`](https://shopify.dev/docs/api/events/latest/collection) and use the collection and product IDs directly in your query: ```toml [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: ```json { "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](https://shopify.dev/docs/apps/build/events/delivery-structure) has more examples. ## More 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`](https://shopify.dev/docs/api/events/latest/product) and [`Collection`](https://shopify.dev/docs/api/events/latest/collection) * **Customers and companies:** [`Customer`](https://shopify.dev/docs/api/events/latest/customer) and [`Company`](https://shopify.dev/docs/api/events/latest/company) * **Orders, fulfillment, and returns:** [`Order`](https://shopify.dev/docs/api/events/latest/order), [`FulfillmentOrder`](https://shopify.dev/docs/api/events/latest/fulfillment-order), [`Refund`](https://shopify.dev/docs/api/events/latest/refund), and [`Return`](https://shopify.dev/docs/api/events/latest/return) * **Inventory and locations:** [`InventoryItem`](https://shopify.dev/docs/api/events/latest/inventory-item), [`InventoryShipment`](https://shopify.dev/docs/api/events/latest/inventory-shipment), [`InventoryTransfer`](https://shopify.dev/docs/api/events/latest/inventory-transfer), and [`Location`](https://shopify.dev/docs/api/events/latest/location) * **Content:** [`Article`](https://shopify.dev/docs/api/events/latest/article), [`Blog`](https://shopify.dev/docs/api/events/latest/blog), and [`Page`](https://shopify.dev/docs/api/events/latest/page) * **Custom data:** [`MetafieldDefinition`](https://shopify.dev/docs/api/events/latest/metafield-definition), [`Metaobject`](https://shopify.dev/docs/api/events/latest/metaobject), and [`MetaobjectDefinition`](https://shopify.dev/docs/api/events/latest/metaobject-definition) Each topic has its own supported triggers, query variables, and access scopes. Check the [Events API reference](https://shopify.dev/docs/api/events/latest) for the changes you want to subscribe to. ## Get 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](https://shopify.dev/docs/apps/build/events/optimizing-your-subscriptions) 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. ## Get 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](https://shopify.dev/docs/apps/build/events/migrate-from-webhooks) 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](https://shopify.dev/docs/apps/build/events/get-started). Set your events API version to `2026-10` and choose the topic and triggers your app needs from the [reference](https://shopify.dev/docs/api/events/2026-10). * **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](https://community.shopify.dev/c/webhooks-and-events).