Skip to main content
The API enforces rate limits at two levels: per IP address (all requests) and per API key (authenticated requests). Both use a sliding-window counter backed by Redis.

IP-based rate limiting

Every request is rate-limited by source IP, regardless of authentication.
ScopeLimit
Per minute600 requests
Per day15,000 requests
These limits apply per IP address. If multiple API keys share the same IP (e.g. corporate NAT), they share this budget.

API key rate limiting

Authenticated requests are additionally rate-limited per API key. These limits are configured per key and depend on your plan.
ScopeDefaultDescription
Per minute60 requestsSliding 60-second window
Per month3,000 requestsResets monthly
Unique IPs20Maximum distinct IP addresses per key per month
Your actual limits may differ from the defaults above depending on your plan.

Response headers

Every response includes rate-limit headers so you can track your usage:
HeaderDescription
X-RateLimit-LimitTotal requests allowed for the period
X-RateLimit-RemainingRequests remaining in the period
X-RateLimit-ResetSeconds until the period counter resets
X-RateLimit-Limit-MinuteRequests allowed per minute
X-RateLimit-Remaining-MinuteRequests remaining in the current minute
X-RateLimit-Limit-IPMaximum unique IPs allowed for the key
X-RateLimit-Remaining-IPUnique IPs remaining

Error responses

When a rate limit is exceeded, the API returns 429 Too Many Requests with a JSON body:
{
  "error": "rate_limit_exceeded",
  "message": "Too many requests per minute. Check X-RateLimit-Limit-Minute and X-RateLimit-Remaining-Minute headers.",
  "retry_after_seconds": 60
}
The Retry-After header is also set, indicating how many seconds to wait before retrying.

Possible rate-limit errors

CauseMessage hintRetry after
Per-minute limit exceededToo many requests per minute60 seconds
Monthly limit exceededMonthly request limit exceededSeconds until period reset
Too many unique IPsToo many requests from different IP addressesSeconds until period reset

Best practices

Monitor X-RateLimit-Remaining and X-RateLimit-Remaining-Minute headers to proactively throttle before hitting limits.
  • Use exponential backoff — when you receive a 429, wait for the Retry-After duration before retrying.
  • Consolidate IPs — if you run distributed workers, be aware of the unique IP limit per key.
  • Use POST multi-search — combine multiple queries into a single request where possible.