Rate limits#

Rate limits are abuse / burst protection, not your billing quota; they cap how fast an account can call, uniformly across search, enrich, and verify. How much you can call per month is a separate lever.

Limits are enforced per organization with a token bucket: the bucket holds limit tokens (the burst) and refills at limit / 60 per second, so you can fire a whole minute's allowance at once, then settle to the steady rate.

The limit#

Every organization currently gets the same generous limit: 6,000 requests / minute (~100/s, burst up to the full 6,000). It exists to stop runaway loops, not to meter usage — credits do that.

A list-fulfillment request (count) counts as one request against your limit, even though the server pages, dedupes and filters internally on your behalf — it is the cheapest way to build a list, for you and for the limit.

When you hit the limit#

Over-limit requests get 429 Too Many Requests with a Retry-After header (in seconds) and a JSON error:

{ "error": { "code": "rate_limited", "message": "Request rate limit exceeded" } }

Back off for the number of seconds in Retry-After, then retry. A steady pace under your per-second rate never trips the limit; brief bursts up to the bucket size are fine.

Tips#

• Spread large jobs across time rather than firing everything at once.
• Treat 429 as normal backpressure, not an error; retry with a short delay.
• Need more headroom? Upgrade in the dashboard or talk to us about an Enterprise ceiling.