Limits by endpoint
Rate limits are applied per API key, not per IP. Each key has its own independent counter per endpoint.| Endpoint | Limit | Window |
|---|---|---|
/api/agent/lookup | 60 requests | 1 minute |
/api/agent/validate | 60 requests | 1 minute |
/api/agent/breaches | 60 requests | 1 minute |
/api/agent/ip | 60 requests | 1 minute |
/api/agent/phone | 60 requests | 1 minute |
/api/agent/domain | 30 requests | 1 minute |
/api/agent/company | 30 requests | 1 minute |
/api/agent/google | 30 requests | 1 minute |
/api/agent/darkweb | 30 requests | 1 minute |
/api/agent/monitors | 60 requests | 1 minute |
/api/agent/lists | 60 requests | 1 minute |
/api/webhooks/* | 30 requests | 1 minute |
Enterprise plans get 10× the above limits (e.g. 600/min for lookup, 300/min for domain).
Response headers
Every response includes rate limit headers:| Header | Description | Example |
|---|---|---|
X-RateLimit-Limit | Max requests in the current window | 60 |
X-RateLimit-Remaining | Requests remaining | 42 |
X-RateLimit-Reset | Unix timestamp when the window resets | 1716134460 |
| Header | Description | Example |
|---|---|---|
Retry-After | Seconds until you can retry | 12 |
Handling rate limits
Exponential backoff
The recommended strategy is exponential backoff with theRetry-After header:
Best practices
Respect Retry-After
Always use the
Retry-After header value instead of a fixed delay.Spread requests
Distribute requests evenly across the window rather than bursting.
Use bulk endpoints
For high-volume lookups, use bulk endpoints instead of individual calls.
Monitor remaining
Check
X-RateLimit-Remaining to preemptively slow down before hitting limits.