Rate limits

Your plan gives each key a budget of units per minute:

GET /v1/me shows yours as limits.per_minute.

What a request costs#

Most requests cost 1 unit. Comparison sets cost more when you ask for more of them at once:

A nightly sync of 3,000 sets at limit=100 costs 30 units. Looking up 3,000 SKUs, 100 at a time, costs 120 units. On a 60-unit plan that takes about a minute: the first 60 units go at once, and the retry code waits for the rest to come back.

Read the headers#

Every response tells you where you stand:

RateLimit-Policy: "sustained";q=120;w=60
RateLimit: "sustained";r=117;t=12
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 117
X-RateLimit-Reset: 12

That reads: 120 units per 60 seconds, 117 left, full again in 12 seconds. The remaining count drops by each request's cost. X-RateLimit-Reset counts seconds; it isn't a timestamp.

When a request costs more units than you have left, you get 429 rate_limited, and the request costs nothing. Retry-After says how many seconds until enough units are back for that request:

{
  "type": "https://api.getprice.ai/errors/rate-limited",
  "title": "Rate limit exceeded",
  "status": 429,
  "detail": "Sustained limit of 120 requests per minute reached for this API key.",
  "code": "rate_limited",
  "request_id": "req_01JBX4Q8ZJ7M2K",
  "limit": "sustained",
  "retry_after": 21
}

Retry safely#

GET, PUT and DELETE are all safe to retry. Make requests one at a time: parallel loops are the usual cause of 429. The Nightly ERP sync guide has a retry helper you can copy.