Shopify Developer Changes in October 2026: Customer Account API Limits, Scope Downgrades and the 2027-01 To-Do List for Custom Apps

The Shopify developer changes in October 2026 that matter for stores with custom apps: a per-customer Customer Account API limit, appDowngradeAccessScopes, Next Gen Events and five 2027-01 deadlines.

The Shopify developer changes in October 2026 are mostly quiet ones, and that is exactly why stores with custom apps should read them. On 7 October, Shopify introduced a per-customer request limit on the Customer Account API and a new way for apps to downgrade their access scopes from write to read. In the same fortnight it made Next Gen Events generally available, announced that the Global Catalog REST API stops serving traffic on 2 November, and published several breaking changes that take effect in API version 2027-01. None of these will make headlines, but a custom app that ignores them can start returning errors on a date nobody wrote down.

We build and maintain Shopify apps, including our own collection-sorting app, SellRank, so we read Shopify's developer changelog every week. This post covers the changes from late September and October 2026 that we think matter most for a store that runs a custom or private app, or pays someone to maintain one. Every item links back to Shopify's own changelog entry, which is the source for each date and rule. If you are looking for the 2026-10 API version itself, or the expiring offline tokens deadline, we covered those in earlier posts; this one looks at what has arrived since and what is due next.

How to read this list

Shopify publishes a new API version every three months, at 5pm UTC on the first day of each quarter, according to its versioning documentation. Each stable version is supported for at least 12 months. If an app calls a version that is no longer supported, Shopify falls forward and answers with the oldest supported stable version, which is where breaking changes bite: the app keeps running, but against a newer version than the one it was written for. API version 2027-01 is therefore due on 1 January 2027. Anything marked 'in 2027-01' below matters when your app moves to that version, or when Shopify falls it forward to it.

We have grouped the changes into three kinds: changes already in effect, new capabilities you may want, and deadlines to plan for.

The Shopify developer changes already in effect

Four changes are live now. They need no version upgrade to take effect, so if your app is affected, it is affected today.

1. A per-customer limit on the Customer Account API (7 October)

The Customer Account API is what powers customer accounts: order history, addresses, profile details and anything a custom account page or extension shows a signed-in shopper. On 7 October 2026, Shopify's changelog announced a per-customer request limit, effective that day at 12:00 pm Eastern.

• The limit is 3,000 requests per minute per customer per store, shared across all apps that call the Customer Account API for that customer.
• It applies alongside the existing cost-based rate limits, not instead of them.
• When it is exceeded, the API returns HTTP 429 Too Many Requests with a THROTTLED error and a Retry-After header.
• Shopify says most apps need no changes, because normal buyer activity is far below the threshold.

Three thousand requests a minute for one customer is a lot, so a well-behaved app will not notice. The apps that might are ones with a bug: a component that refetches in a loop, an account page that polls every second, or several apps each making many calls for the same signed-in customer. Because the limit is shared across apps, one badly behaved app can throttle another for the same shopper.

1. 1Ask your developer, or check yourself, whether any custom code or extension calls the Customer Account API.
2. 2Confirm it handles HTTP 429: it should read the Retry-After header and wait that long before retrying, not retry immediately.
3. 3Look for polling or refetch loops in custom account pages and extensions, and replace them with fetching on demand.
4. 4If several apps touch customer accounts, note which ones, so a throttling report can be traced quickly.

2. Events subscription complexity cut from 250 to 100 points (22 September)

For apps already using Events subscriptions, Shopify's changelog of 22 September reduced the query complexity limit for Events subscriptions from 250 points to 100, effective that day, and marked it as a breaking change. It does not apply to classic webhooks. Shopify's advice is to split heavy subscriptions into several subscriptions for the same topic with different triggers and queries, and to query the specific changed resource rather than whole parent objects.

3. metafieldsSet now costs more when it touches many resources (15 September)

The metafieldsSet mutation used to cost a flat 10 points. Since 15 September it costs a base of 10 points plus a weight for each distinct resource it writes to: 10 per order, 4 per product, 2 per product variant, 1 per collection, customer or shop, and 0 for other owner types, up to a maximum of 260 points for a call touching 25 orders. Shopify said the change was needed because bursts of high fan-out metafieldsSet traffic were putting excessive pressure on its infrastructure.

If a custom app writes metafields to many orders or products in one call, for example stamping fulfilment data on a batch of orders, it will now use up its rate limit faster. Shopify recommends grouping writes by resource, monitoring the cost reported in the response, and handling throttling gracefully.

4. More forgiving token migrations (29 September)

Apps migrating from non-expiring to expiring offline access tokens without a user session can now recover from a lost migration response. Shopify's changelog of 29 September says an app can retry the same exchange within seven days, using the original token and client credentials, and receive the same access and refresh token pair. The original non-expiring token stays invalid once migrated. If you are working through the expiring offline token deadline we wrote about earlier, this removes one of the ways a migration could force a merchant to reinstall.

New capabilities worth knowing about

Three additions are optional. None forces a change, but each solves a real problem for some custom apps, and one of them, scope downgrades, is worth asking any app developer about.

5. appDowngradeAccessScopes in API version 2027-01

On 7 October, Shopify announced that from Admin GraphQL API version 2027-01, apps using Shopify-managed installation can call a new mutation, appDowngradeAccessScopes, to replace optional write scopes with their matching read scopes. Until now, the only way for an app to give up a scope was appRevokeAccessScopes, which removes both write and read access.

• It affects only the calling app's own installation.
• The scopes must be declared as optional write scopes that have matching read scopes. Required scopes cannot be downgraded.
• Write scopes the app has not been granted are ignored.
• If any part of the request fails validation, the whole request is rejected and no scopes change.

For a store, this is a small but welcome security improvement. An app that needed write access for a one-off job, such as an initial import, can drop back to read access afterwards instead of holding write permission indefinitely. If you commission a custom app, it is reasonable to ask whether it will use this once 2027-01 is available. Note that changing scopes can have side effects; in our own work, a scope change has invalidated a stored offline token until the app was reopened in the admin, so test the flow on a development store first.

6. Next Gen Events are generally available (1 October)

Shopify's developer blog of 1 October announced that Events, its declarative successor to classic webhooks, is generally available across 18 topics, configured in an app's shopify.app.toml from API version 2026-10. An Events subscription combines a trigger (which changes matter), a GraphQL query (what data to send) and a query filter (which results to deliver), so the payload arrives with the data the app needs and no follow-up API call.

The 18 topics cover products and collections, customers and companies, orders, fulfilment orders, refunds and returns, inventory items, shipments, transfers and locations, articles, blogs and pages, and metafield definitions, metaobjects and metaobject definitions. Shopify says existing classic webhook integrations will continue to work, that both can be used in the same app, and that workflows can be moved one at a time. It has not announced a deprecation date for classic webhooks.

Our view: there is no need to rewrite a working webhook integration in peak season. For new integrations, or for webhook handlers that make several follow-up API calls per delivery, Events can reduce both deliveries and API usage, which makes it worth planning for the new year.

7. Variants can hold up to 20 barcodes (8 September)

From API version 2026-10, product variants support multiple barcodes, up to 20 per variant, each with an optional type such as UPC, EAN, ISBN, GTIN or ASIN. The single ProductVariant.barcode field is deprecated but still works and returns the first barcode. Shopify warns about silent truncation: an integration that reads only the old field will never see the other barcodes. If your store syncs identifiers to an ERP, warehouse or marketplace feed through a custom integration, plan to move it to the barcodes connection before you start storing more than one barcode per variant.

Deadlines to plan for

Finally, the dated items. One falls in three weeks; the rest arrive with API version 2027-01 on 1 January 2027.

8. Global Catalog REST API stops on 2 November 2026

Shopify's changelog of 9 October says the deprecated Global Catalog REST API stops serving traffic on 2 November 2026, after which all requests to it fail. The replacement is the Global Catalog MCP server, which uses the Universal Commerce Protocol and offers search_catalog, lookup_catalog and get_product tools. Most stores will never have used this API directly; it matters to developers building agent or discovery tools on Shopify's catalogue. If anything in your stack calls it, it has three weeks.

9. Five breaking changes in API version 2027-01

• metafieldInteger collection conditions are removed (changelog, 1 October). Smart collection conditions that use metafieldInteger must move to metafieldInt, whose value field is a String rather than an Int. In 2027-01, mutations that send metafieldInteger fail validation and queries selecting its type return errors.
• The automaticDiscounts query is removed (18 September). Use discountNodes with the filter method:automatic instead; queries that include automaticDiscounts fail validation in 2027-01.
• owner_type becomes required on metafield declarations in Checkout and Customer Account UI extensions (8 October). Add it to each declaration in shopify.extension.toml, such as PRODUCT or CUSTOMER; from 2027-01, deployments without it are blocked.
• Discounts can now be included in Rollouts, and Shopify marked the change as action required (1 October). If your app creates or edits discounts, read the entry to see how it affects you.
• Tax webhook summary and calculation requests now use Global IDs (1 October, marked breaking). Apps that parse those payloads need to handle the new identifier format.

The first item deserves a note for anyone using metafield-based smart collections, because it touches collections directly. If a custom app or script creates smart collections with integer metafield conditions, for example 'carat weight greater than 1', it must be updated before it moves to 2027-01. Shopify suggests testing the change on API version 2026-10 first.

A two-hour audit for a store with a custom app

If you are a store owner rather than a developer, this is the checklist we would hand to whoever maintains your app. It should take an experienced developer about two hours to answer.

1. 1Which API version does each custom app request today, and when does that version leave support? Write down the date.
2. 2Does any code call the Customer Account API? If so, does it handle HTTP 429 with Retry-After, and is there any polling?
3. 3Does any code use metafieldInteger collection conditions, the automaticDiscounts query, or Checkout and Customer Account UI extensions with metafield declarations? Each needs a change before 2027-01.
4. 4Does any integration read ProductVariant.barcode for syncing to another system?
5. 5Does any job call metafieldsSet across many orders or products at once? Check its cost and throttling behaviour.
6. 6Has every app migrated to expiring offline tokens, and is the migration response stored safely?
7. 7Does anything call the Global Catalog REST API? If so, it must move before 2 November.
8. 8Which apps hold write scopes they only needed once? Note them as candidates for appDowngradeAccessScopes in 2027-01.

Questions to ask whoever maintains your app

Many store owners do not know who would notice if Shopify changed something their app relies on. If that is you, these questions, put to your developer or agency, will tell you quickly whether anyone is watching.

• Who reads Shopify's developer changelog for our apps, and how often?
• Which API version does each of our apps use, and when will you move it to the next one?
• How do you test an API upgrade before it reaches our live store?
• How would we find out if an app started failing, before a customer told us?
• Which of the October 2026 changes affect our apps, and what is the plan and date for each?

A good answer is specific: a named person, a date, a development store, an alert. A vague answer is not a reason to panic, but it is a reason to arrange a short review before the new year.

Why this matters more than it looks

Platform maintenance is the least visible cost of a custom app and the most common reason one fails. The app worked when it was delivered; then Shopify moved on, quarterly, and nobody was watching the changelog. Most of the changes above are one-line fixes if caught in time and a confusing outage if caught by a customer. That is why, when we scope a custom app for a client, we include who will track API versions and how upgrades will be tested, and why we ask the same of any agency or freelancer a client is considering.

It is also one of the arguments for an off-the-shelf app where one fits. With SellRank, for example, keeping up with Shopify's API changes is our job, not the merchant's. SellRank ranks collections by measured performance and writes the order into Shopify's own manual collection sort, with no theme edits, and every release runs through the same verification suite before it ships. Where a store's needs are genuinely specific, a custom app is the right answer, but it needs an owner.

Talk to us about your custom app

If you are not sure whether your store's custom apps are affected by any of these changes, or nobody has looked at their API version in a while, tell us about them on our contact page and we will give you a straight assessment, including when the answer is that nothing needs to change. If your collection sorting runs on a homemade script that worries you, see how SellRank handles it on its product page.