Skip to main content

​
The limit

Every API key gets a sliding-window rate limit of 60 requests per minute. The counter resets one request at a time as older requests fall out of the trailing 60-second window. Bursts up to 60 in the same second are allowed; the 61st in the same 60-second window is rejected. The per-minute cap is a burst shaper. Your monthly quota (see Authentication) is the primary volume control.

​
Rate-limit response

When the limit trips, the API returns HTTP 429 with the standard error envelope and a Retry-After header in seconds:
The value in Retry-After and retry_after is the number of seconds until the oldest in-window request expires and a fresh slot opens.

​
Rate-limit headers on every response

Every successful response also carries usage telemetry: Cache the last-seen X-RateLimit-Remaining in your client and pace outbound calls when it drops below your safety threshold. The official SDKs already implement this. If you are building your own client:
  1. On 429, sleep for Retry-After seconds plus a small jitter (100 to 500 ms).
  2. Retry once. If the second attempt also returns 429, back off exponentially (2, 4, 8 seconds capped at 60).
  3. Never retry 4xx responses other than 429 or 408.
  4. Retry 5xx at most twice.

​
Bulk instead of loops

If you find yourself firing dozens of /v1/calc requests in a tight loop, switch to /v1/calc/bulk. One bulk call with 500 rows counts as one request against the rate limit and consumes one entry against the monthly quota, versus 500 rows sent one at a time (500 requests, 500 quota entries, guaranteed rate-limit trips). /v1/compare fans out up to 6 origins in parallel server-side and counts as one call. Prefer it over 6 sequential /v1/rates lookups.

​
Higher limits

The 60 rpm cap is per key, not per organization. Mint a second key for a second workload before asking for a higher ceiling. If you have a genuine sustained throughput requirement above 60 rpm per key, Enterprise contracts include custom rate ceilings. Contact sales.