Rate limits

Rate limits protect selected high-volume and public operations. Limits are counted by authenticated person when available and by client IP otherwise.

Current policies

Policy	Limit	Window	Applied to
Standard read	100,000 requests	1 hour	Selected detail and related-resource reads.
Strict collection	5,000 requests	1 hour	Selected collection and report operations from non-allowlisted origins.
Allowlisted application	100,000 requests	1 hour	Strict collection operations called from an allowlisted application origin.
Public prospect submission	1 request	1 minute	POST /p/v1/public-prospects, counted by IP address.

Not every operation currently uses a shared limiter. Resource pages identify a limit when one is registered for that operation. Limits can be tightened to protect service reliability, so clients should honor returned headers instead of hard-coding these values.

Response headers

• RateLimit-Policy describes the request limit and window in seconds.
• RateLimit reports the limit, remaining requests, and seconds until reset.
• Retry-After is returned with 429 Too Many Requests and gives the minimum number of seconds to wait.

Handling rate limits

When the API returns 429:

1. Stop sending requests governed by the exhausted policy.
2. Wait for Retry-After.
3. Resume gradually and use exponential backoff with jitter if another 429 occurs.

Cache reads when appropriate, avoid polling unchanged resources, and request a larger page instead of making many small collection requests when the endpoint supports it.

Available capacity

HTTP/1.1 200 OK
RateLimit-Policy: 5000;w=3600
RateLimit: limit=5000, remaining=4999, reset=3600

Limit exceeded

HTTP/1.1 429 Too Many Requests
RateLimit-Policy: 5000;w=3600
RateLimit: limit=5000, remaining=0, reset=37
Retry-After: 37