Rate Limits

API requests are rate limited to ensure fair usage and service stability.

Limits by endpoint class

Limits are currently fixed by the kind of operation and keyed by API key when one is present, otherwise by client IP. They are not daily plan quotas.

Endpoint class	Requests/minute	Typical use
Authentication	10	Sign-in, registration, password and magic-link flows
Token refresh	120	Refreshing portal access tokens
Risk checks	100	/v1/check operations
General ingestion	3,000	RUM, network logs, feedback-agent and automation-agent traffic
Edge ingestion	5,000	/v1/edge/logs
Feature-flag config	3,000	/v1/flags SDK refreshes
Administrative operations	10	Restricted internal administration

Only routes that attach one of these limiters emit rate-limit headers. Other portal endpoints are protected by authentication and pagination but do not currently share a global plan-level limiter.

Rate Limit Headers

Every response includes rate limit headers:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1705320000

Header	Description
X-RateLimit-Limit	Max requests per minute
X-RateLimit-Remaining	Requests remaining
X-RateLimit-Reset	Unix timestamp when limit resets

Rate Limit Response

When exceeded, you'll receive a 429 status:

{
  "success": false,
  "message": "Too many requests. Please slow down.",
  "content": {
    "retry_after": 45
  }
}

The response also includes Retry-After in seconds.

Best Practices

1. Cache results - Store check results to avoid duplicate calls
2. Use bulk endpoints - /check/bulk for multiple checks
3. Implement backoff - Exponential backoff on 429 responses
4. Monitor usage - Track your usage in the dashboard