Skip to content
TrustList
News

Shopify caps Customer Account API at 3,000 requests a minute per customer

Editorial

By TrustList Editorial

The limit is shared by every installed app on a store and sits on top of the existing cost-based limit; a scope-downgrade mutation arrives with API version 2027-01.

About Shopify caps Customer Account API at 3,000 requests a minute per customer

Shopify caps Customer Account API at 3,000 requests a minute per customer

7 October 2026: Shopify now enforces a limit of 3,000 requests per minute for each customer on a store when apps call the Customer Account API. The limit is shared across every app installed on that store, so one busy integration can use up the allowance that another needs for the same shopper.

Not yet independently verified. Both facts come from Shopify's own changelog and we have not tested them against a live store. We will update this when it can be confirmed, and remove this note.

It applies on top of the cost-based rate limit the API already had. An app that goes over gets an HTTP 429 Too Many Requests response with a THROTTLED error and a Retry-After header.

Shopify says most developers need to change nothing, because normal buyer traffic stays well under the figure. The company's advice is narrow: make sure retry logic detects a 429, reads Retry-After, waits that long and then tries again. Code that retries immediately, or that treats a 429 as a permanent failure, is the code that will misbehave if a store runs several apps against the same customer.

The shared allowance is the part worth checking on stores with a loyalty app, a returns portal, a subscription tool and a custom storefront all reading customer data. Each can look fine in isolation and still add up for one signed-in customer.

A second change published the same day concerns app permissions. From Admin GraphQL API version 2027-01, apps that use Shopify-managed installation can call a new appDowngradeAccessScopes mutation to swap optional write scopes for the matching read scopes. The scopes must be declared as optional, required scopes cannot be downgraded, and write scopes not currently granted are ignored. If any requested scope fails validation, the whole request is rejected and the installation's scopes stay as they were.

Shopify gives the example of changing write_products to read_products when an app no longer needs to create or update products. Revoking a write scope with the existing revoke mutation also removes read access that was only granted through it, which is why the downgrade call exists. No action is needed for existing apps.

Company profile on TrustList: Shopify

Related on TrustList:

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy