Executive summary
- What: Shopify is cutting the Events subscription query complexity limit from 250 points to 100. Classic Webhooks are unaffected.
- Why: Subscriptions were being written as broad catch all queries. The lower ceiling forces each one to fetch only what its handler needs.
- Who: Anyone running Events subscriptions, in practice app developers and the integration teams maintaining order, inventory, and product sync.
What changed
Events subscriptions let an app receive a GraphQL payload when something changes, rather than a fixed webhook body. Shopify scores each query using the standard cost calculation: the fields selected, the types they return, and the number of items requested through first or last on connections. That score must now stay at or under 100 points, down from 250.
The limit applies per subscription query, not per app and not in aggregate. These queries still do not count against your app's API rate limits, so this is a shape constraint rather than a throughput one.
The guidance is to split subscriptions by the work they do. You can register multiple subscriptions on one topic, each with its own triggers and query, so price change and title change no longer share an oversized query. The other half is to query the changed resource directly: for a variant price change, fetch that variant's price, SKU, and parent product ID rather than the product's first 250 variants.
There is a second reason beyond the point budget. Fetching the first 250 variants refetches unchanged data and silently misses changed variants past the first page. Querying the changed resource is both cheaper and more correct.
Variables differ by trigger, which limits consolidation. A variant price trigger supplies a variants ID, a product title trigger does not, so subscriptions needing different variables must stay separate.
Why it matters
Most Plus merchants do not write subscriptions themselves, but they own the consequences. Events subscriptions keep an ERP, OMS, or PIM aware of catalog and inventory changes in near real time. A subscription over the new limit does not degrade gracefully, so the failure mode is a sync that quietly stops reflecting changes and surfaces days later as stale pricing or stock.
The pagination point is worth escalating with vendors. An integration fetching the first 250 variants on every product change already has a correctness bug on any product with more variants than that, regardless of the limit. Large catalog and configurable product merchants are the exposed population. This is a reasonable prompt to audit how your middleware layer subscribes to and processes change events.
Treat this as a maintenance item with a hard edge, not an optional optimisation. Splitting one broad subscription into three narrow ones is a few hours. Reconciling a week of missed inventory updates is not.
Role-specific impact
- Marketers: No direct action. Note that price and availability reaching downstream channels depends on these subscriptions working.
- Developers: Score every subscription query against the cost calculation and refactor anything above 100 points. Favour more subscriptions with narrower queries, and stop paginating connections inside subscription payloads.
- Store admins: Ask each integration vendor in writing whether their subscriptions are under 100 points. Treat a vague answer as a risk to track.
Use-case example
Real-world scenario
A Plus merchant with 4,000 configurable products syncs pricing to an ERP via an app subscribing to product updates. The subscription pulls the product plus its first 250 variants, scoring roughly 160 points, so under the new limit it stops. Rebuilt as two subscriptions, one on variant price change fetching only price, SKU, and parent ID, and one on title change, each lands near 15 points. Payload size drops by more than 90 percent, the ERP stops processing thousands of unchanged variant records per update, and variants beyond position 250 sync correctly for the first time.
Implementation checklist
- List every Events subscription your apps and integrations register, including third party ones.
- Score each query against the documented cost calculation and flag anything over 100 points.
- Split oversized subscriptions by trigger, giving each a query matched to the change it handles.
- Replace connection pagination inside subscription queries with direct lookups on the changed resource.
- Check each query only uses variables its trigger actually provides.
- Confirm downstream handlers still receive every field they depend on after the split. This is where refactors usually break.
- Ask third party vendors for written confirmation that their subscriptions comply.
FAQ
Q: Do our Classic Webhooks need changing?
A: No. The change applies only to Events subscriptions. Classic Webhooks are unchanged.
Q: What if a legitimate use case genuinely needs more than 100 points?
A: Splitting by trigger resolves nearly all of them. If yours survives that, Shopify is collecting cases in the community forums, but plan on complying rather than on an exception.
Resources
Optimizing your Events subscriptions
Need guidance? Talk to Makro.