Rate limits

Request limits per app and store, or shared by Store Admin tokens, set by the store's plan and store type.

The Store API allows a steady rate of requests plus short bursts. Each limit is a bucket: the burst capacity is how many requests it can accept at once, and the sustained rate is how quickly capacity comes back. The connected store's plan and store type decide the limits.

Limits by plan#

Plan	Sustained rate	Burst capacity
Spark	1 request/second	20 requests
Lite	1.5 requests/second	30 requests
Starter	2 requests/second	40 requests
Pro	2 requests/second	40 requests
Advanced	3 requests/second	60 requests
Plus	4 requests/second	80 requests

These limits apply to live stores. A plan that is not listed uses the Starter limits.

Development and transfer stores#

Development stores and transfer stores, which partners build for clients, use a smaller limit whatever plan they show: a burst of 10 requests, refilling at 0.5 requests/second. They are for building and testing, not for serving traffic. The store_type field of Token and store details tells you which limits apply: dev and transfer use this limit, and live uses the plan limits above. See Development and transfer stores for what else differs.

An app has one bucket for each store where it is installed; its tpat_ and tast_ tokens use that same app-and-store bucket. All tsat_ Store Admin tokens for a store share one Store Admin bucket. Two apps installed on the same store never share a bucket.

App Bridge exchanges#

Three App Bridge exchange endpoints run before Store API token authentication and never use an app-and-store or Store Admin bucket. POST /api/2025-01/app-bridge/session/exchange and POST /api/2025-01/app-bridge/fulfillment-artifact-context/exchange share one bucket per client IP address: a burst of 30 requests, refilling at 0.5 requests/second.

POST /api/2025-01/app-bridge/line-artifact-access/exchange is called once for each artifact image, so a request carrying a valid Tringify-signed access token gets its own bucket for that token, with the same 30-request burst and 0.5 requests/second rate. A request whose token cannot be verified counts against the per-IP bucket above and is then rejected with INVALID_TOKEN.

Response headers#

Header	Meaning
`X-RateLimit-Limit`	Burst capacity for the current bucket.
`X-RateLimit-Remaining`	Requests currently available without waiting.
`X-RateLimit-Reset`	Unix timestamp when already accepted requests have drained from the bucket.
`Retry-After`	Whole seconds to wait after a `429`; present only when throttled.

Authenticated Store API routes receive rate-limit headers only after token and subscription checks pass. Authentication failures and subscription rejections do not carry them. The three App Bridge exchange endpoints use the same header names for their own buckets; other public endpoints do not carry rate-limit headers.

Rate-limit response#

http

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 40
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1778796300
Retry-After: 1

{"success":false,"error":{"code":"RATE_LIMITED","message":"Rate limit exceeded. Retry after 1 second."}}

Wait at least Retry-After seconds before retrying, and spread bulk work over time instead of sending it in bursts.

Bulk work#

Every request costs one, whatever it carries. A bulk endpoint that changes 500 products uses the same capacity as reading one product, so batch whenever an endpoint allows it rather than sending one call per item.

Products: the bulk endpoints (status, tags, categories, sales channels, vendor, brand, delete) take up to bulk_max products per call; read it from the product limits endpoint on Products.
Sales channel apps: report feedback for up to 500 products with Set publication feedback in bulk on Channel publications instead of one call per product, and page through publications with limit up to 200.
Pace with the headers: when X-RateLimit-Remaining is low, slow down before you reach a 429.
Keep background work from crowding out the merchant: one bucket serves your whole app for the store, so leave headroom for requests your admin page makes while a sync runs.