Your Shopify Events subscriptions break on your next deploy, not today

Two changelog entries a week apart in September 2026 changed how Shopify Events work: updates to Events payloads and subscription configuration on the 16th, and the subscription query complexity limit dropping to 100 points on the 22nd. Four separate things changed. None of them broke your app.

That is the problem. Existing subscriptions keep running exactly as they are, and the new rules apply the next time you deploy your shopify.app.toml. So this does not fail on a date Shopify picked. It fails during whatever unrelated change you ship next, which might be a Friday hotfix, and the error will be about your Events config rather than the thing you were actually doing.

Run the cheap check first

Before reading the rest of this, run the command that turns a vague worry into a number. --no-release validates your configuration and creates an app version without releasing it to anyone.

1shopify app deploy --no-release

If a subscription query exceeds 100 points, this returns a validation error that reports both the calculated value and the maximum allowed. That is a precise, actionable number, produced without touching production, and it is the difference between "we should look at Events at some point" and "this one subscription is at 180 and needs splitting".

Change 1: the complexity ceiling halved

Shopify computes a subscription's complexity from the Admin API fields you select and the connection sizes you request, for the API version configured for Events. Some fields carry custom costs, so counting fields by hand does not give you the total. The ceiling moved from 250 points to 100 on September 22.

The fix is almost never to trim a field here and there until you scrape under the line. It is to notice that an expensive subscription is usually one subscription doing several jobs. Shopify's optimization guide lists four techniques, and they are worth reading in order of how much they typically save:

• Use exact triggers instead of wildcards. product.title and product.status instead of product.*. A wildcard makes you pay for a query broad enough to serve every possible trigger.
• Query the changed node directly. When the trigger hands you the child's ID, fetch that node rather than paginating the parent's connection to go find it.
• Delete the connections you were only using to search. variants(first: 100) is expensive and usually exists because someone needed one variant.
• Target metafields by namespace and key. Rather than loading the whole metafield collection and filtering in your handler.

Change 2: fields_changed has a new shape

This one requires a code change in your handler, not just config. fields_changed used to be a flat array of names. It is now an object with three arrays.

1{2  "fields_changed": ["title", "variants", "tags"]3}

1{2  "fields_changed": {3    "added": ["tags"],4    "updated": ["title"],5    "removed": ["variants"]6  }7}

This is a genuine improvement rather than churn. The old array told you a field was involved; it could not tell you whether a relationship had been attached, changed or detached, so handlers queried the resource again just to find out which. Now that distinction arrives in the payload. A handler that only cares about removals can stop doing a round trip on every event.

The migration hazard is quiet: code that did fields_changed.includes('title') does not throw against an object, it just returns false forever. Grep for every read of fields_changed rather than trusting your tests to catch it, because a handler that silently stops matching is not a test failure, it is a feature that quietly stops firing.

Change 3: parent triggers need a terminal wildcard

A parent trigger must now end in an explicit wildcard. Leaf triggers are untouched.

Separately, an event subscription using the update action now requires at least one trigger. A subscription that listened to every update on a topic is no longer expressible, which is deliberate: that subscription was almost always both the most expensive one an app had and the one whose handler started with a large conditional.

Change 4: two delivery headers are gone

shopify-event-id and shopify-resource-id are no longer included in event deliveries. Unlike the other three, this one is not waiting for your next deploy. It affects traffic now.

Shopify's guidance is to update your API packages to their latest versions, which handle it. Do that, and then check whether anything of your own read those headers directly. Idempotency keys are the usual culprit: a handler that deduplicated on shopify-event-id is now deduplicating on undefined, which in most implementations means either everything is a duplicate or nothing is. Both are bad in different directions, and neither raises an error.

The audit, in order

1. Run shopify app deploy --no-release. Numbers before opinions. It tells you which subscriptions are over 100 points and by how much.
2. Grep for fields_changed in your handlers. Every array method on it is now wrong and none of them will throw.
3. Grep for shopify-event-id and shopify-resource-id. Check your idempotency and logging paths first; that is where they live.
4. Add terminal wildcards to parent triggers and give every update subscription at least one trigger.
5. Split before you trim. If a subscription is over the ceiling, the question is which jobs it is doing, not which field to sacrifice.
6. Bump your Shopify API packages. The header removal is handled for you there, and it is the one change already live.

The professional habit worth taking from this is smaller than the changelog. When a platform says existing configuration keeps working but new rules apply on your next deploy, that is not reassurance, it is a warning with the timing left blank. The right response is to schedule the deploy yourself, on a quiet afternoon, rather than discover the config error in the middle of shipping something else.