At 15:00 UTC on Friday, October 16, 2026, which is 11 a.m. in New York, version 2025-10 of Shopify's API stops being accessible. Shopify doesn't reject a request just for asking for it. Its documentation: "If your app targets an inaccessible version, Shopify falls forward and responds using the oldest accessible stable version." From that moment, that is 2026-01. Anything your app uses that changed between the two versions changes under it: a field or argument removed since 2025-10 comes back as a GraphQL error, and a query that is still valid can return its data in a different shape.
Two examples from the 2026-01 release notes. The deprecated Shop.draftOrders connection is removed, and apps that read several draft orders through it should use QueryRoot.draftOrders instead. And bulkOperationRunQuery now omits object grouping by default, so a bulk query that needs grouped output has to set groupObjects: true. The first fails with an error. The second changes the shape of the results without one.
This guide is for anyone who builds or maintains a Shopify app or integration, and its examples use the GraphQL Admin API. The same versions apply elsewhere. REST Admin calls name their version in the same place, as in /admin/api/2025-10/products.json, and return the same header; REST has been a legacy API since October 1, 2024, and a REST request with no version at all is answered by the oldest supported stable version. Storefront API calls (/api/2025-10/graphql.json, with their own access token) and the Customer Account API use the same version names. The Partner API is the one to watch: its documentation asks for a supported version in the URL and shows a 404 with "Invalid API version", not a fall-forward, so a reporting script pinned to an old version can simply stop. For App Store apps the stakes are higher still: "If your app continues to use unsupported resources after the upgrade deadline, it's delisted from the Shopify App Store."
If You Run the Store
None of the work below is yours, but the questions are. Ask whoever built or maintains each custom app or integration your store depends on: which API version do its requests and its webhooks actually use, which newer version has it been tested on, and will that release be live before 15:00 UTC on October 16? Then ask them to confirm that the workflows you rely on passed that testing.
What Changes on October 16
Shopify releases a new API version every quarter, "at 5pm UTC on the first day of the quarter", and "each stable version is supported for a minimum of 12 months." The release table then gives each version an accessible-until time: 15:00 UTC on the 16th of the month, a little over a year after release. Support and access are separate columns in that table: 2025-10 is already marked Unsupported, and it stays accessible until Friday. These are the dates Shopify publishes today:
| Version | Released | Accessible until |
|---|---|---|
| 2025-10 | October 1, 2025 | October 16, 2026, 15:00 UTC |
| 2026-01 | January 1, 2026 | January 16, 2027, 15:00 UTC |
| 2026-04 | April 1, 2026 | April 16, 2027, 15:00 UTC |
| 2026-07 | July 1, 2026 | July 16, 2027, 15:00 UTC |
| 2026-10 | October 1, 2026 | October 16, 2027, 15:00 UTC |
After Friday, 2026-01 is the oldest stable version still accessible, which makes it the version every request for 2025-10 is answered as.
Where Shopify API Versions Are Set
In an app built from Shopify's React Router or Remix template, start with the five places below. Then look further: independent clients, scheduled scripts, middleware, and anything else that calls Shopify on its own. Your app may have fewer of these, or more.
1. Request URLs
Every request names its version in the path: /admin/api/2025-10/graphql.json for GraphQL, /admin/api/2025-10/products.json for REST. Search your code and every integration for api/2025-10, then search separately for REST URLs that name no version, since those never contain the string. Look for calls that pass their own apiVersion option too: the template's clients accept one per request.
Why: the URL is the version you ask for. The settings below build most URLs, but code that writes its own, or passes its own version, skips them.
2. Both version lines in the app's server config
In app/shopify.server.ts, the template sets the version twice: apiVersion: ApiVersion.October25 in the options passed to shopifyApp(), and export const apiVersion = ApiVersion.October25 below it. ApiVersion.October25 is 2025-10; its successors are ApiVersion.January26, ApiVersion.April26, ApiVersion.July26 and ApiVersion.October26. If your installed package has no member for the version you want, update the Shopify packages first.
Why: this is the default version for the template's Admin API clients, so it is the one most of an app's requests use. Move both lines together.
3. Webhooks: the toml, and the subscriptions it doesn't hold
[webhooks] api_version = "2025-10" in shopify.app.toml sets the version Shopify uses to build the payloads of the subscriptions declared in that file. While shopify app dev runs, a change to it updates your development store; shopify app deploy releases it to production. Deploying your server does neither.
Why: two deploy commands means the code and the toml can disagree without anyone noticing. Subscriptions created through the Admin API are separate again: for those, "the version is determined by the request URL" that created them, and a custom app created in the Shopify admin sets up all of its webhooks that way, with no toml. Check those on their own. Every HTTPS delivery carries X-Shopify-API-Version, so a real delivery tells you which version built it.
4. The GraphQL codegen config
The templates generate typed queries from .graphqlrc.ts, which names an ApiVersion too: the schema your editor and the generated types are checked against. The template's build and typecheck scripts don't run codegen; its graphql-codegen script does.
Why: a green build says nothing about whether your queries were checked against the new schema. Run codegen yourself after you change the version.
5. Every extension's api_version
Each shopify.extension.toml with an api_version line is on the same calendar. Shopify Functions use it to pick their Function API schema, and Function APIs follow the same quarterly versions, so a function on 2025-10 is due too; Shopify's Function docs don't say what happens to one left on an inaccessible version. To move one: set its api_version, run shopify app function schema, run shopify app function typegen for a JavaScript function, then rebuild, test and deploy it.
Why: changing the app's Admin API version doesn't touch these. UI extensions carry an api_version as well, and for those Shopify CLI "prevents deploys targeting versions older than 12 months", so an old one can stop your next shopify app deploy.
Verify the Served Version With X-Shopify-API-Version
Shopify's documentation: "API responses include the X-Shopify-API-Version header reflecting the version used to fulfill the request." If it doesn't match the version in your URL, Shopify has already fallen forward. In a bash shell with curl, against a development store (replace your-store with its subdomain, and set SHOPIFY_TOKEN to your app's Admin API access token for it):
curl -sS -D - -o /dev/null \
-X POST "https://your-store.myshopify.com/admin/api/2025-10/graphql.json" \
-H "X-Shopify-Access-Token: $SHOPIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"query":"{ shop { name } }"}' | grep -i x-shopify-api-versionBefore 15:00 UTC on Friday this prints a header line whose value is 2025-10; after it, the same request prints 2026-01. The header's capitalization can vary, and no output at all means something else went wrong. Before you deploy, run it again with the version you plan to ship in the URL, and read the header. And log this header on every response your app receives, so a fall-forward shows up as data instead of as a bug report.
Two more places to look. The Dev Dashboard's logs show "the API version the call requested" for each entry, and its alerts flag deprecated calls with the date they must be fixed by. GraphiQL Explorer shows deprecation warnings for a query. Neither of those warnings tells you that your pin is still 2025-10; the logs and the header do.
Move to a Current Version
1. Pick the newest version you can test
2026-10 is the latest stable version and stays accessible until October 16, 2027; 2026-07 lasts until July 16, 2027. The newer the version, the longer the runway, and the more changes since 2025-10 there are to test. Pick the newest supported stable version you can validate before Friday.
2. Change every place in one commit
The request URLs and URL constants, both lines in app/shopify.server.ts, [webhooks] api_version, and the codegen config, in one commit, so none is left behind. Move extensions on their own, with their schema steps.
3. Regenerate, then read the release notes in between
Run the codegen script with its config pointed at the new version. With schema validation on, it rejects any query in its document patterns that uses a field or argument the new schema doesn't have, so check that those patterns cover all of your queries. It doesn't check REST calls, webhook handlers, or fields that still exist but behave differently, so read the release notes for every version between yours and the target.
Why: release notes list what changed; validating your own queries tells you which of those changes you use. When we moved our own Shopify apps up in September, this step caught a mutation argument that reading the release notes had missed.
4. Test on a development store
Run the queries, mutations, scheduled jobs and store workflows the upgrade touches, with realistic data. Test webhook handlers with shopify app webhook trigger --api-version=<version> --address=<destination> --topic=<topic>, then trigger real store events and check the deliveries.
5. Deploy both halves, then verify production
Deploy your app's server for the code, and run shopify app deploy for the toml. Then read X-Shopify-API-Version on each kind of production request and on real webhook deliveries, and check the response bodies for GraphQL errors and userErrors.
Why: the header names a version; it isn't a compatibility test.
Put the Next Dates on the Calendar
This happens every quarter. After October 16, the next version to go is 2026-01, on January 16, 2027, then 2026-04 on April 16, 2027. Review your versions and the deprecation alerts each quarter, and start a migration early enough to test the changes your app actually uses; how much work it is depends on the upgrade. For our own apps we run a daily check that compares the version each app deploys against Shopify's release table and alerts us a quarter ahead. Shopify does on its side what our guide to versioning your own API recommends to any provider: it publishes each version's end date well in advance. The client's half of that bargain is to read the date and own it.
A separate storefront change is coming too. Shopify stops injecting script tags into storefronts on March 1, 2027, and pinning an older API version doesn't postpone it; our guide to finding your storefront's script tags covers that audit.
The short version
The date: 2025-10 stops being accessible at 15:00 UTC on Friday, October 16, 2026, and requests for it are answered as 2026-01. Find it: request URLs (REST URLs with no version included), both version lines in app/shopify.server.ts, [webhooks] api_version and any webhook subscriptions created through the API, the codegen config, and every extension's api_version. Check it: read X-Shopify-API-Version on real responses and deliveries. Fix it: pick the newest supported version you can test, change every place in one commit, run codegen, read the release notes in between, test on a development store, deploy the server and the toml, and verify production. Then: the next date is January 16, 2027.