Shopify API changes: scope downgrades and request limits
Separate a live Customer Account API request limit from a permission downgrade feature in the 2027-01 release candidate.
Two Shopify API announcements from 7 October need different release decisions. The Customer Account API already enforces a shared request ceiling for each customer. A new way to reduce an app’s write permissions to read access belongs to Admin GraphQL API 2027-01, which is still a release candidate.
Prepare permission reductions in development
The scope downgrade announcement introduces appDowngradeAccessScopes for apps using Shopify managed installation. It replaces eligible optional write permissions with their matching read permissions, for example write_products with read_products.
Required permissions cannot be downgraded. Requested scopes must be declared as optional, and any validation failure rejects the whole request without changing the installation. Ungranted write scopes are ignored. The mutation affects only the calling app.
That differs from appRevokeAccessScopes: revoking a write scope also removes read access when that access was inherited solely from the write scope. A downgrade preserves the reading capability.
Shopify’s version schedule lists 2026-10 as latest stable and 1 January 2027 as the release date for 2027-01. Test the permission change in development and plan adoption around the stable release; the announcement requires no change from existing apps.
Handle the customer request limit now
The Customer Account API change caps traffic at 3,000 requests per customer, per store, per minute across all apps. This is an additional limit alongside the existing cost based limit.
Exceeding it returns HTTP 429 with a THROTTLED error and a Retry-After header. Shopify instructs developers to detect that response, read the header and wait for its specified duration before retrying. Normal buyer traffic should stay well below the ceiling, so most apps do not need changes.
A practical release review
Our recommendation is to keep these as separate engineering tasks. First, check that account integrations handle throttling rather than immediately repeating failed calls. Because the allowance is shared, measuring only one app’s traffic does not establish the customer’s total usage.
For permissions, map each write scope to the feature that needs it before deciding it can be reduced. A one time import and an ongoing product sync have different needs. Test what happens after the downgrade, including background jobs, before promising merchants that an app can operate with read access alone.
Merchants commissioning custom integrations can ask their developers for both checks at the next handover. Neither announcement is a reason to remove permissions blindly or assume ordinary shoppers are about to hit a limit.
More from News
See all →

