Integrations17 min readPublished October 2026

Shopify retired API 2025-10 on 16 October. Your export still returns 200

At 3 pm UTC on 16 October every request pinned to Shopify's 2025-10 API version started being answered by 2026-01 instead. The response code does not change and the only signal is a header nobody's automation platform shows. Bulk exports come back in a different shape, one deprecated field is gone, and merchants see an "Unsupported" badge the developer cannot see.

The status did not change. The header did

Shopify's versioning page, read on 12 September, listed 2025-10 as "Stable" and "Accessible until October 16, 2026 15:00 UTC". Since that moment, requests that name that version in the URL are handled the way the same page describes:

If your app targets an inaccessible version, Shopify falls forward and responds using the oldest accessible stable version.

The oldest accessible stable version is now 2026-01. So a script, a Make module, an n8n HTTP node or a data connector that has 2025-10 in its URL did not stop working on 16 October. It started getting 2026-01 answers to 2025-10 questions, with the same HTTP 200 it always got. The one signal is a response header, X-Shopify-API-Version, and the page says so. If the request is made by a platform - n8n, Make, Zapier - that header is received and discarded before anything you can see. So for most integrations "did anything change for us on 16 October" has no answer until something downstream shows it.

There are three things it does, and they look nothing like each other.

The bulk export comes back in a different order

The most consequential change between 2025-10 and 2026-01 is one Boolean's default. Bulk queries - the way anyone exports a whole catalogue, all orders, all customers - produce a JSONL file, and until 2026-01 that file put each child object directly after its parent. Shopify's guide to bulk queries still describes only that layout: "each product object is followed by each of its variant objects on a new line", with a __parentId on each child. On 12 September the guide did not contain the word groupObjects at all.

The changelog for 2026-01 does, flagged "Breaking API Change" and "Action required":

The groupObjects argument now defaults to false. Grouping objects can slow down operations and increase failure rates, especially with large datasets.

[...]

To maintain grouped output: Set groupObjects: true.

The reference pages confirm it: the 2025-10 page for bulkOperationRunQuery shows the argument with Default: true, the 2026-01 page with Default: false, and the two pages differ only in that default and in the wording of the argument's description. What the file looks like without grouping is not in the documentation anywhere. It is on the developer forum, from Shopify staff:

When it's true, two things happen that hurt you at scale. First, the query execution phase has additional retry logic with progressively smaller page sizes that can burn time. Second, and more importantly, the file assembly step has to download, parse, and re-sort the JSONL output line-by-line so child objects land directly after their parent. At 500k products with millions of variants, that sorting step is where timeouts happen. When groupObjects is false (the default on 2026-01+), file assembly is a straightforward concatenation without any content-level parsing.

"Straightforward concatenation." The __parentId field is still on every child line, so the data is all there. What is gone is the guarantee that a child sits under its parent - a Shopify staff member's answer in 2025, when the option was new, was that children should be "somewhere below the parent object", that "we can't guarantee that it will always happen that way", and that "if you're relying on a specific order, I'd recommend leaving grouping enabled".

Relying on that order is how bulk JSONL has been parsed for years, because it is the memory-efficient way. A partner asked exactly this on the forum in 2022: "when I reach a new top level parent object, does that mean I've gone through all children of the previous parent?" The guide's description said yes. A parser built on that assumption closes each product when it sees the next one, and any variant that arrives later in the file is attached to nothing.

How seriously the people who maintain bulk readers take this shows in one open-source data-integration platform's Shopify connector. In May a user reported a stream returning 100 records where the shop held about 190,000, with the sync completing "successfully without any error"; the maintainers' first move, merged on 10 June, was to add one line to the connector's bulk query template - groupObjects: true - on the theory that grouping was being lost. The truncation turned out to have another cause, settled in the same thread a day later, but the line stayed, and the pull request to move the connector off 2025-10 - opened on 3 August by an automated contributor, still open on 12 September - explains why in one sentence:

After that date Shopify silently falls forward to the oldest accessible stable version, so behavior would drift unversioned rather than hard-fail.

[...] The connector already passes groupObjects: true explicitly in ShopifyBulkTemplates.prepare, so this is a no-op — but that explicit true is now load-bearing and must not be removed.

  • the connector's pull request for the version bump, opened 3 August 2026, read 12 September 2026

That connector is protected by a line that was added for the wrong reason. A bulk export written against the 2025-10 documentation, by someone who never needed the argument because the default did what they wanted, has no such line. Since 16 October it runs, completes, returns a file, and the file is assembled differently.

The changelog entry above was already visible on 14 October 2025 without the "Action required" flag. A developer pointed out that day that it "probably breaks a lot of applications"; one Shopify staff member agreed the same day, and another explained the next day that "the changelog post should not have been published yet". It carries a posting date of 29 October, with the flag. So the notice existed, correctly labelled, for almost a year before the version closed. Notice is not the problem with this change.

One field is simply gone

The second effect is loud, at least to anyone who reads the response body. 2026-01 removed the Shop.draftOrders connection, which had been deprecated for some time; the 2025-10 reference still lists it, marked "Deprecated (removal date set)", and the 2026-01 reference does not have it. A query that asks for it on 2025-10 is now validated against a schema in which it does not exist, and gets a GraphQL error inside a 200 response instead of data. The replacement is the top-level draftOrders query, and the changelog said so on 26 September 2025.

One other difference in 2026-01 changes behaviour without breaking anything, and matters if your code was written to the old limit: bulk operations can now run five at a time per app per shop instead of one, so code that expected an "operation already in progress" error as a signal will not see one until five are running.

The merchant finds out before you do

The third effect is the one that reaches a shop owner with no code involved. When 2025-07 closed on 16 July this year, a developer posted this the same evening:

We're seeing our app marked with an "Unsupported" badge under Settings → Apps and sales channels for a subset of merchants. The app detail page shows: "This app may not work as expected. [APP NAME] needs to be updated by the app developer. Contact them for support or uninstall the app." Reports started roughly after the 2025-07 API version reached its Accessible until date [...]

What's confusing us: our Partner Dashboard's own "API health" monitoring (Monitoring → API health) shows "OK, no calls with breaking changes detected in the last [14/30] days", which seems to directly contradict the Unsupported designation.

The same post confirms the mechanism from the other side: hitting the retired version directly, the response "comes back served by 2025-10 (x-shopify-api-version: 2025-10)". Another developer in the thread reported the badge disappearing after moving everything to 2026-01, and added: "our dashboard showed no deprecated API calls, no calls with breaking changes, and no related errors or emails from Shopify." No Shopify staff replied in that thread. The badge is a documented consequence - the versioning page says users "will see warnings in the Shopify admin" for apps using unsupported resources - but the thread is about apps with a listing, and the documentation does not say whether a custom app installed on one store gets the same badge.

And the closure before that one, on 16 July 2025, was not quiet either:

We also started seeing errors at 15:00 UTC exactly when calling the inventorySetQuantities mutation in the GraphQL API: "one or more errors returned from shopify set inventory level mutation: Field 'inventorySetQuantities' doesn't exist on type 'Mutation'" We are also on 2024-07, though we're in the process of migrating off of it

Two days later Shopify's reply was that the problem "is only impacting the 2024-07 API version which is just recently deprecated and unsupported. Our advice is to switch to a more recent version". That field existed in every later version, so this was a fault at the closure rather than the closure working as designed; a developer in the thread reports it also appeared as a public Shopify Status incident. What the versioning page guarantees is the fall-forward. What happened at the last two closures was, in one case, two days of errors on several mutations for those still on the retired version, and in the other, a warning on the merchant's screen that the developer's own dashboard contradicted.

The three platforms

n8n's Shopify node has been on fall-forward for fifteen months. Its requests go to a hard-coded URL - admin/api/2024-07/ on line 40 of the node's source, a version set in July 2024 and untouched since - and the node's own settings panel shows a notice reading "Shopify API Version: 2024-07". That version closed on 16 July 2025. Since then, by the versioning table, the version actually answering the node has changed on 16 October 2025, 16 January, 16 April and 16 July 2026, and again on 16 October: four times this calendar year, with the notice in the node saying 2024-07 throughout. The node only uses REST - orders, products, and the webhooks its trigger registers, which carry no version of their own and so fall forward too. The 2026-01 release notes contain no REST section at all, and nothing in their Orders or Products sections touches the REST endpoints the node calls, so there is no known break for the node on this date - which is also what was true of its last four version changes.

Make moved its inventory modules to 2026-04 on 11 September - the change we wrote about on 15 October - and its note says the Shopify app was updated "to align with" that version, while describing only the two inventory modules. What the other modules target is not published. The "Make a GraphQL API call" module sends whatever version is in the URL you gave it, so a hand-written bulk query in that module is exactly the script case above.

Zapier states no API version for its integration on its Shopify page or in the help-centre articles a search for one returns, beyond noting that some actions use the GraphQL API. A Zap has no field that would show it.

Meanwhile, 2026-10 went stable on 1 October

Nobody falls forward onto 2026-10; it is where you land if you move deliberately, and if you are moving off 2025-10 now, the newest version is the obvious target. As of 12 September its release notes carried six "Action required" items, and by the time you read this there may be more. The two that matter for ordinary shops:

  • Metafield filters now error instead of being ignored. "You're affected only when a query filters by a metafield that isn't valid for filtering" - which is the silent version of the problem we covered in the metafield filter that returned everything, now surfaced as an error. Queries on valid filters behave as before.
  • Changing the shipping address on an unfulfilled order recalculates its taxes. Only unfulfilled and editable orders; partially or fully fulfilled orders keep their tax lines. The changelog adds that "an already-paid order can be left with an outstanding refundable or payable balance" - can, not will - and describes marking as paid, invoicing or refunding the difference: three code paths an address-sync integration did not need before.

Also on 2026-10: the legacy PriceRule types are removed from the schema, and Order.displayFulfillmentStatus can now return FULFILLMENT_NOT_REQUIRED, a new value that any exhaustive mapping of fulfillment statuses will not know.

Which version is answering you

The version string is a date somebody typed once, and it belongs to whoever typed it. A platform that hard-codes it, as n8n's node does, has taken that decision away from you and with it the ability to know when it stopped applying. A script that carries it is yours to move. Neither is a crisis; not knowing which of your integrations is which is, and Shopify's only signal for it is a header your tools throw away. If you would rather not run the checks below, establishing that list and moving what needs moving before the sales peak has a fixed price - it is the integration repair we see most often.

  1. Find every place a version is written down. In n8n it is the notice in the Shopify node's settings, and the URL of any HTTP Request node that talks to Shopify. In Make it is the URL in "Make a GraphQL API call" or a generic HTTP module. In scripts and connectors it is a string that looks like 2025-10 in the URL or a config file. Anything that says 2025-10 or earlier is on fall-forward as of 16 October.
  2. Make one request and read the header. A GET to /admin/api/2025-10/shop.json with your token, looking only at the response headers, returns X-Shopify-API-Version: 2026-01 now. Shopify's versioning page: "If it differs from what you requested, your app is targeting an inaccessible version and Shopify has fallen forward to the default." If it returns the version you asked for, you are not on fall-forward. This is a read-only request and is safe to run against a live store; if your app has no REST access, a { shop { name } } query against /admin/api/2025-10/graphql.json is the same test.
  3. If you run bulk queries, look for groupObjects in the mutation. If it is absent and the code that reads the file assumes children follow their parent, you have two options: add groupObjects: true, which restores the old layout and the old timeouts, or rewrite the reader to collect by __parentId, which is present either way. Shopify's staff reply above goes further and recommends splitting into flat root-level queries joined by the product id, which is the better long-term shape. Then check the output of the last few runs since 16 October for row counts that dropped, on the child objects specifically.
  4. Search for draftOrders under shop. A query that nests it there fails now, with the message in the errors array of an otherwise successful response, so look at the body, not the status.
  5. Open the store's admin and look at Settings → Apps and sales channels. A warning there about an app needing an update is Shopify's signal to the merchant, and it arrives whether or not the developer's dashboard agrees.

Black Friday is 27 November, 41 days from the day this article appears. An export that has been assembling its file differently since 16 October will have done so for six weeks by then, and whatever consumes that file - a feed, a marketplace listing, a warehouse system - has been receiving the result.

Sources

  • Shopify API versioning - Shopify developer documentation, read 12 September 2026. The version table with 2025-10 accessible until 16 October 2026 15:00 UTC and 2026-10 as release candidate until 1 October 2026, the fall-forward rule, the X-Shopify-API-Version header, and the admin warnings for apps using unsupported resources.
  • Bulk operations group objects default changed to false - Shopify developer changelog, posted 29 October 2025, effective 2026-01, flagged "Breaking API Change" and "Action required", read 12 September 2026. The default change and the instruction to set groupObjects: true.
  • bulkOperationRunQuery - Shopify GraphQL Admin API reference for 2026-01 and for 2025-10, read 12 September 2026. The groupObjects argument with Default: false and Default: true respectively; the pages otherwise differ only in the argument's description.
  • Perform bulk operations with the GraphQL Admin API - Shopify developer documentation, read 12 September 2026. The JSONL format description, the __parentId field, the five-concurrent-operations rule from 2026-01, and the absence of any mention of groupObjects.
  • Bulk operation performance - nested groupObjects vs 2 flat queries - Shopify developer community, April 2026, read 12 September 2026. The staff description of file assembly with grouping on and off. The 2025 staff statements on ordering without grouping are from this thread of June and July 2025, and the 2022 partner question from this one.
  • Should the bulk operations group objects default changed to false be marked "Action Required" - Shopify developer community, 14 and 15 October 2025, read 12 September 2026. The early publication of the changelog entry and the staff replies.
  • One open-source data-integration platform's Shopify connector: the truncation issue, its fix and the pull request for the version bump, read 12 September 2026 through the GitHub API. The truncation report of 29 May 2026, the change of 10 June adding groupObjects: true to the bulk template, the reporter's and maintainer's follow-ups of 1 and 11 June establishing that nested connections were the actual cause, and the pull request of 3 August, opened by an automated contributor and still open on 12 September, with the quoted rationale for leaving the line in place. Given without the project's name.
  • Removal of deprecated Shop.draftOrders connection - Shopify developer changelog, 26 September 2025, together with the Shop object reference for 2025-10 and for 2026-01, read 12 September 2026. The field marked for removal on one page and absent from the other.
  • Shopify API release notes, version 2026-01 and version 2026-10 - Shopify developer documentation, read 12 September 2026. The action-required items in each, and the absence of a REST section in 2026-01. The tax recalculation scope and the balance wording are from the changelog entry of 30 July 2026; the metafield filter scope from the entry of 24 July 2026. The 2026-10 notes were read while that version was a release candidate and may have gained entries since.
  • App shows "Unsupported" badge in Shopify admin despite clean API health report - Shopify developer community, 16 to 24 July 2026, read 12 September 2026. The badge text, the API health contradiction, the observed fall-forward header, and the follow-up after moving to 2026-01. No staff reply in the thread.
  • Urgent: Product GraphQL API bug? - Shopify developer community, 16 to 18 July 2025, read 12 September 2026. The errors at 15:00 UTC on the day 2024-07 closed, the staff reply, and a developer's reference to a Shopify Status incident, which no staff member in the thread confirms.
  • n8n source, GenericFunctions.ts, Shopify.node.ts and ShopifyTrigger.node.ts - read 12 September 2026 from the raw files on master, with the file history through the GitHub API. The admin/api/2024-07/ base URL on line 40, set by pull request #10155 merged 29 July 2024, the version notice in the node settings, the Order and Product resources, and the webhook registration without an api_version field.
  • Shopify: Action required for the 'Update an Inventory Level' module - Make Help Center, 11 September 2026, and the Shopify app page, read 12 September 2026. The 2026-04 statement scoped to the inventory modules, and the absence of any version on the app page.
  • Shopify integrations on Zapier and the Zapier help centre, searched 12 September 2026 through its API. No API version published.

Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.