This page is the shared overview for both APIs. For LENS (v2) specifics — exact windows, every response header, and the full error reference — see Rate limits in the v2 API.
Retry-After header.
How limits are enforced
Both APIs enforce rate limits at two levels, using sliding windows:
Defaults are below. Actual quotas depend on your plan.
For LENS (v2) specifics including all response headers and error messages, see Rate limits in the v2 API Reference.
Response headers
Every response includes rate-limit headers so you can track your usage and throttle proactively.429 response body
When you’re throttled, you receive an HTTP 429 with a JSON body describing which window tripped and when it resets.Retry-After (or X-RateLimit-Reset) and back off. Do not retry in a tight loop. A well-behaved client reads these headers on every response and adapts pre-emptively.
IP-based limits
Each API key is capped at a number of unique source IPs per month (default: 20). This protects you if a key is leaked — an attacker’s IP would count against the limit. The downstream IP is read fromX-Real-IP or X-Forwarded-For.
If you run behind a load balancer or a pool of NAT’d outbound IPs, size your quota accordingly.
Best practices
- Use exponential backoff when you get a
429. - Monitor
X-RateLimit-Remaining-Minuteto throttle proactively rather than reactively. - Consolidate traffic through few IPs to stay under the unique-IP cap.
- Prefer POST multi-search where available to combine queries into fewer requests.