Skip to main content
Rate limits are per workspace, not per key. Issuing more keys does not buy more throughput. Read your workspace’s actual limit from GET /v1/me rather than hard-coding these.

​
Reading the headers

Every response carries the current state:
​
integer
Requests left in the window. Slowing down as this approaches zero is cheaper than being throttled.
​
integer
Unix timestamp when the window resets.
When you exceed a limit you get 429 with a Retry-After header in seconds. Honor it — backing off on your own schedule keeps you limited longer.

​
Staying under

Requesting 100 rows per page instead of the default 25 cuts your request count by four for the same data, at no extra credit cost — credits are charged per row.
/resolve and /enrich take 100 inputs per call. One hundred single-input calls will exhaust a 60/minute budget immediately; one batched call uses a single request.
A job is one request regardless of how much work it does. Anything above a few thousand rows belongs in a job rather than a paging loop.
Polling job status every five seconds burns a read budget to learn nothing. Subscribe to job.completed instead.
GET /channels and GET /categories change on the order of weeks. Refresh them on a schedule, not per request.

​
Concurrency

Alongside the per-minute limits, a workspace may have at most 20 requests in flight at once. Exceeding it returns 429 with Retry-After: 1. A bounded worker pool is the fix, not a retry loop:

​
If you need more

Limits are raised for workspaces with a demonstrated pattern. Before asking, check that the volume is real rather than avoidable — the list above removes most of it. If it is real, contact [email protected] with your workspace ID and the sustained rate you need.
Rate limits and credits are independent. Staying under the rate limit does not mean you have credits, and having credits does not raise your rate limit.