Rate limits
Per-plan request ceilings and monthly allowances, and what happens past them.
Every /v1 request counts against your organization’s plan ceiling, per API key, in a fixed
one-minute window:
| Plan | Burst limit | Included calls per month | Past the allowance |
|---|---|---|---|
| Trial | 30 requests per minute | 1,000 | refused until the 1st of the next month |
| Small | 30 requests per minute | 500 | refused until the 1st of the next month |
| Medium | 60 requests per minute | 5,000 | refused until the 1st of the next month |
| Large | 120 requests per minute | 25,000 | billed at the published rates |
| Enterprise | 600 requests per minute | custom | billed at the published rates |
Both numbers are resolved from your plan on every call, so an upgrade takes effect immediately —
there is nothing to redeploy or re-issue. Every plan may call /v1. The two columns bound
different things: the burst limit is how fast, the monthly allowance is how much.
Past the monthly allowance, a plan that bills the excess simply continues; a plan that does not
refuses with 402 and code: "api_allowance_reached", naming the date the count returns to zero
and the plans that would give more room before then. Nothing is charged for a refused call, and
no usage is recorded for it.
Over the ceiling, the response is 429 with code: "rate_limited" and a Retry-After header
giving the seconds until the window resets. Refused requests still count toward the window, so
retrying before Retry-After does not help. The limit is enforced against a shared counter, so it
is the same ceiling regardless of how many servers are answering — and if that counter is briefly
unreachable we refuse requests rather than serve them uncounted.
The free public lookup (POST /public/lookup) is limited separately, and has no key:
5 requests per minute per IP address, and
120 requests per minute across all callers.