The Shopify Events 100-point limit replaced the old 250-point ceiling on September 22, 2026, and it forces a design decision most Events integrations deferred: one fat subscription that fetches everything, or several narrow ones that fetch only what moved. We think the split is the right answer, and not only because the new budget pushes that way. The fat query was always the expensive, fragile option. The new budget just makes that visible at deploy time.
What the Shopify Events 100-point limit changes
Every Events subscription query must now fit inside 100 complexity points, down from 250. Shopify's changelog entry tags it as a breaking change, dates it September 22, 2026, and states that classic webhook subscriptions are not affected. Only next-generation Events are in scope, and Events itself is still a developer preview on the unstable API version.
The enforcement point matters more than the number. According to Shopify's guide to optimizing subscriptions, each query is validated when you deploy an app version, without being executed. A query over budget blocks the deploy, and the error reports the calculated complexity next to the maximum. Nothing fails silently at delivery. What fails is your release pipeline, on whatever day someone next ships.
How Events complexity is counted
Events complexity uses the same cost rules as the GraphQL Admin API, calculated against the API version configured for Events. Shopify's rate limit documentation gives the base values: scalar and enum fields cost 0, object fields cost 1, connections are sized by their first or last argument, and interfaces or unions cost the maximum of their possible selections. For comparison, an ordinary Admin API query is capped at 1,000 points, so Events runs on a tenth of that ceiling.
The number is less brutal than it sounds. In the community announcement, Shopify staff show a single product query that fits in exactly 100 points while pulling product details, SEO fields, options, up to 250 variants and ten metafields. Scalars being free is what makes that possible. Adding a price or a SKU costs nothing. Adding another nested object or a wider connection is what eats budget. So the practical rule is simple: count objects and connection sizes, not fields, and let the deploy validator give you the exact figure rather than estimating by hand.
One fat subscription vs split subscriptions
Split subscriptions win on cost, correctness and debuggability, and the fat subscription wins only on the number of config blocks. That is the whole comparison, but the correctness point deserves detail because it is the one teams underestimate.
A broad query such as variants(first: 100) hanging off a product does two bad things at once. It reloads every unchanged sibling on each delivery, and if the product has more variants than the page size, the variant that actually changed may not be in the result at all. Shopify's guide calls this out directly. A merchant with a size and colour matrix across several markets can exceed 100 variants on a single product without trying, and at that point the fat query is not just wasteful. It can deliver the wrong data.
The split version subscribes to product-level triggers such as product.title and product.status with a query rooted on product(id:), and to variant triggers such as product.variants.price with a separate query rooted on productVariant(id:). The variant trigger exposes both productId and variantsId as query variables, so the second query fetches exactly the variant that moved plus its parent ID. Each subscription is cheap, each payload is small, and each handler has one job. Shopify's rule of thumb is to split whenever triggers expose different variables or need different query roots.
The cost of splitting is operational. You maintain more entries in shopify.app.toml, and deliveries for one product can now arrive through two channels. Shopify already warns that concurrent deliveries can land out of order, so handlers should compare a timestamp such as updatedAt before writing. That discipline was needed with one subscription anyway. With two, skipping it produces visible bugs.
Why it matters for multi-market catalogues in Asia
Catalogues selling across several Asian markets are exactly the shape that hits the new ceiling first. Regional sizing, market-specific metafields for compliance text and translated content, and bundles modelled as variants all widen the connections a fat query pulls. The integrations we see downstream of these stores push data into ERPs, marketplace connectors and search indexes, and each of those consumers usually cares about a narrow slice: price and stock for the marketplace, content for search, status for the ERP.
That is the argument for designing subscriptions around consumers rather than around topics. One subscription per downstream system, each querying only the fields that system reads, stays far under 100 points and maps cleanly onto the queues and retries in an automation layer. It also means a slow search reindex never holds up a stock update. On the storefront side of our e-commerce work, the same principle keeps cache invalidation targeted: a price change purges one variant, not a whole product tree.
What we would do this sprint
Deploy every app that uses Events to a staging app version now, because the validator is the fastest audit available. The error tells you the calculated complexity of each failing query, which gives you a ranked list of what to fix. Then work through it in order.
First, split any subscription whose triggers mix product-level and variant-level paths, rooting each query on the deepest ID its trigger provides. Second, remove connections the handler never reads. Nested metafield connections on every variant are the usual culprit. Third, where a consumer genuinely needs a large payload, have the handler fetch it from the Admin API on receipt instead of carrying it in the subscription. That moves the cost onto the regular rate limit, where Shopify Plus stores restore at 1,000 points per second, instead of the fixed Events ceiling. Finally, if a real use case still needs more than 100 points, Shopify says it will discuss exceptions case by case in the community thread. We would treat that as a last resort, not a plan.
This is the second Events change in a week. The 2026-10 payload changes reshaped what a delivery contains. This one caps what a subscription may ask for. Both reward the same habit: small, targeted subscriptions with strict handlers.