Shopify Events changed shape on September 16, 2026, and the migration window closes on October 1. The field every integration reads to work out what happened was restructured, two delivery headers were deleted, and parent triggers now need an explicit wildcard. Existing subscriptions keep running on the old syntax, which is the trap. They break on your next deploy, not on the announcement date, so the release that ships the breakage is probably unrelated to any of this.
What changed in Shopify Events on September 16
Shopify rewrote the Events payload contract and the subscription config format in a single change, effective the day it landed. The changelog entry is tagged action required and covers four things: the fields_changed structure, parent trigger syntax, two removed delivery headers, and a new requirement that subscriptions using the update action declare at least one trigger. Classic webhook subscriptions are untouched. If you never adopted Events, none of this reaches you.
The hard date is October 1, 2026. Shopify's migration thread asks developers to move subscriptions onto Events API version 2026-10 by then. That is two weeks from now, which for most agencies means one sprint, not two.
Flat array vs three buckets
fields_changed is no longer a flat array of paths. It is now an object with three arrays inside it: added, updated and removed. The paths themselves keep their dot notation with embedded GIDs, so a variant still arrives as a path hanging off the product. What is new is that the delivery now tells you which of the three things happened to it.
That distinction used to cost a round trip. Under the old flat array you received a path and knew only that something about it was different. Whether the variant had just been created, had its price edited, or had been deleted was not in the payload, so the handler queried the Admin API to find out, or diffed against a cached copy to infer it. Both of those steps exist purely to recover information Shopify already had.
The concrete example Shopify gives is instructive. Add a variant to a product and the event action stays update, because the product is what changed. The variant path lands in fields_changed.added. Same topic, same action, and the only signal separating a creation from an edit is which bucket the path came in. Read the object as if it were still an array and you get no error. You get an object where you expected a list, and whatever your language does with that is your new bug.
Triggers, headers, and the update action
Parent triggers now require a terminal .*, and two headers are gone. In shopify.app.toml, a subscription that reads triggers = ["product.variants"] becomes triggers = ["product.variants.*"]. Leaf paths such as product.variants.price are unchanged. Shopify says matching behaviour and event volume are preserved for equivalent subscriptions, so this is syntax, not semantics. The wildcard was implicit before and is explicit now.
The deleted headers are shopify-event-id and shopify-resource-id. The current Events reference lists nine delivery headers and neither appears among them: Shopify-Topic, Shopify-Action, Shopify-Handle, Shopify-Api-Version, Shopify-Webhook-Id, Shopify-Triggered-At, Shopify-Shop-Domain, Shopify-Hmac-Sha256, and a User-Agent set to Shopify-Webhooks. If you built idempotency on shopify-event-id, your dedupe key no longer exists and every retry is now a fresh event as far as your worker is concerned. That is the quietest and most expensive of the four changes.
The fourth is narrower. Subscriptions with the update action must now carry at least one trigger, where a trigger was previously optional. A subscription that said only update me on this topic is no longer valid config.
What we would ship before October 1
Start with a grep, not a refactor. Search every handler for fields_changed and assert the shape at the top of the function rather than trusting it. An array-to-object swap fails differently in every runtime and most of those failure modes are silent: a length check returns undefined, a loop iterates nothing, and your worker reports success on an event it never processed. Make it throw. A loud failure on staging beats a quiet one in production for two weeks.
Then audit shopify.app.toml for any trigger path that is a parent without a terminal wildcard, and grep the codebase for both removed headers. Idempotency built on shopify-event-id moves to Shopify-Webhook-Id. Pin the Events API version to 2026-10 and update the Shopify API packages, which Shopify says already handle the header change.
The deploy timing is the part worth putting in writing for the client. Nothing breaks while you do nothing. The break is triggered by the next shopify app deploy, which means a routine release six weeks from now, shipped by someone who never read this changelog, is what takes the integration down. On back-office automation work this is the classic shape of a bad incident: a change with a long fuse, lit by an unrelated hand. Fix the config now so the fuse is already out.
There is a broader read here for anyone building on Events. It is still a developer preview, and this is what preview means in practice. The payload contract we wrote about when Events first appeared has now been rewritten once, with two weeks of notice and no dual-format grace period. That is a reasonable trade for getting field-level triggers early, but it is a trade, and it belongs in the risk column of any headless Shopify build that depends on Events for anything a merchant would notice within the hour.