Rate limits

Per installation

Every app-callable operation shares one bucket per installation:

Burst	40 requests
Refill	2 requests per second
Queueing	none — over-limit requests are refused, not delayed

The bucket is yours alone: another app, or the same app on another store, neither affects nor is affected by it.

The limit is enforced on every app route. Every response — success or error — tells you where you stand:

Header	Meaning
RateLimit-Limit	The bucket size: 40.
RateLimit-Remaining	Requests you can still make right now.
RateLimit-Reset	Seconds until the bucket is full again.

When you exceed it you get the standard error envelope with the rate_limited code, plus Retry-After:

HTTP/1.1 429 Too Many Requests
Retry-After: 3
RateLimit-Limit: 40
RateLimit-Remaining: 0
RateLimit-Reset: 20

{"error":{"code":"rate_limited","message":"This installation exceeded its request rate. …","request_id":"…"}}

Retry-After is in whole seconds, at least 1. Watch RateLimit-Remaining and slow down before it reaches zero rather than reacting to the 429. For bulk work, prefer the batch routes — one bulk update of 100 products costs one request.

Token endpoint

POST /apps/token has its own limit: 20 requests per minute per IP address, fixed window. Over the limit you get 429 (do not parse its body). A correctly written app calls it about once an hour.