Rate limits

The API limits requests per minute so that a faulty loop cannot affect other merchants.

How requests are counted

• Per key. Every valid API key has its own budget. Several integrations behind the same IP address therefore do not share a budget.
• Additionally per IP address a higher ceiling applies across all keys from that source.
• Window: 60 seconds.

Currently the budget is 300 requests per minute per key. Shirtee can change this value without notice. Rely on the headers, not on the number.

Headers

Every response carries the rate-limit headers, including 401 and 429:

Header	Meaning	Example
RateLimit-Policy	Budget and window	300; w=60
RateLimit-Limit	Requests per window	300
RateLimit-Remaining	Remaining requests	298
RateLimit-Reset	Seconds until reset	48

On 429

You used up the budget. Wait at least RateLimit-Reset seconds, then retry. There is no Retry-After header.

when RateLimit-Remaining is low:  send more slowly
on 429:                           wait RateLimit-Reset seconds, then retry
on 429 despite waiting:           double the wait (backoff), set an upper bound

Needing fewer requests

• Use filters and page parameters of the lists instead of querying each resource individually.
• Do not poll status more often than needed, see Polling instead of webhooks.
• Cache catalog data that rarely changes.