September 29, 2026 · Muhammad Rehan · More by Muhammad Rehan
Shopify Cut Events Query Budgets to 100 Points — Redesign, Don't Trim
Shopify's Events system cut its query complexity limit from 250 to 100 points. The fix isn't a smaller query — it's splitting one subscription into several.
Shopify's Events subscription system — a developer-preview replacement for Classic Webhooks, available today on the unstable API version for a subset of topics — had two breaking changes land back to back in September 2026. Together they change how integration engineers should design subscriptions, not just how big they can be.
What changed
On September 16, the fields_changed payload stopped being a flat array of changed paths and became an object with three arrays: added, updated, and removed. Adding a variant to a product still reports the product's action as update, but the variant path now lands in fields_changed.added instead of being mixed in with everything else. Parent-level triggers also need an explicit terminal wildcard now — product.variants.* instead of product.variants — while leaf triggers like product.variants.price are unchanged. Two delivery headers, shopify-event-id and shopify-resource-id, were removed entirely.
The bigger change came on September 22: the query complexity limit per Events subscription dropped from 250 points to 100. Complexity is scored the same way as any GraphQL Admin API query — fields selected, the types of data returned, and connection sizes via first or last. None of this counts against your app's API rate limit; it's a separate budget, and it just got smaller. Classic Webhooks aren't touched by either change.
The fix is architectural, not cosmetic
Shopify's own migration guidance is specific about what doesn't work: shrinking a broad query until it fits under 100 points. A subscription on product.* that re-fetches a product's first 100 variants on every update will blow past the limit regardless of which fields you trim, because the connection itself is the expensive part.
The documented pattern instead splits one broad subscription into several narrow ones, each scoped to an exact trigger and querying the changed node directly by its deepest available ID. Shopify's worked example replaces a single product.* subscription with two: one on product.title and product.status that queries product(id:) for just those fields, and a second on product.variants.price and product.variants.barcode that queries productVariant(id: $variantsId) directly — using the variant ID the trigger itself provides, instead of paginating through the product's variant connection to find it.
What splitting actually costs
This isn't free. One write to a product can now trigger deliveries to multiple subscriptions instead of one, so any handler logic built around "one event per operation" needs to be revisited, and routing has to key off each subscription's unique handle. It also doesn't produce a complete snapshot: a capped first: N connection was already partial coverage, and Shopify's guidance is to page through a full collection in a separate reconciliation process rather than treat any single delivery as authoritative.
For teams building on Events today, the practical move is to inventory exactly which fields each handler reads, map each one to the deepest ID a trigger can provide, and design the subscription boundaries around that — before hitting the 100-point ceiling in production.