Rate Limits

All conversion endpoints are rate-limited per API key. Limits are enforced on a fixed per-minute window aligned to the clock.

Policy

Requests per window10

Window duration60 seconds

Window alignmentFixed, clock-aligned

Limit scopePer user account

info

The window is fixed and aligned to the clock minute — it resets at the top of each minute, not 60 seconds after your first request.

Every allowed request includes the following headers so you can track consumption without waiting for a 429.

X-RateLimit-Limit

Maximum number of requests allowed in the current window.

X-RateLimit-Remaining

Number of requests remaining in the current window.

X-RateLimit-Reset

Unix timestamp (UTC) when the current window resets and the count returns to the limit.

Requests beyond the limit receive a 429 Too Many Requests response with the following body and headers.

429 Too Many Requests

{
  "message": "rate limit exceeded, please retry after the window resets"
}

Response headers

Retry-Afterseconds until the window resets

X-RateLimit-Limit10

X-RateLimit-Remaining0

X-RateLimit-Resetunix timestamp of next reset

1Read the Retry-After header from the response to know exactly how many seconds to wait before retrying.
2Monitor X-RateLimit-Remaining on every successful response to detect when you are close to the limit before it triggers.
3Implement exponential backoff with jitter if you retry automatically — do not hammer the endpoint the moment the window resets.
4If you regularly hit the limit, batch your work or queue requests with a token bucket at 10 requests per 60 seconds.

lightbulb

The rate limiter fails open — if the rate limit store is temporarily unavailable, requests are allowed through rather than blocked.