Skip to content

Rate limits

One endpoint is rate limited: POST /v1/email-verifications, the real-time verify call. Nothing else in the API is — not bulk jobs, not polling a result, not the monitoring endpoints.

The limit is counted per API key. Two keys on the same account have separate budgets, so a batch job running on one key cannot throttle your production traffic on another. Requests from the dashboard (which are authenticated by your session, not a key) are counted per account.

Plan Sustained Burst
Free 1 request / second 2
Starter 3 requests / second 6
Growth 10 requests / second 20
Scale 25 requests / second 50

The sustained rate is what you can hold indefinitely. On top of it you get short bursts of up to 2× your sustained rate — an idle key banks up to two seconds’ worth of requests and can spend them at once, then settles back to the sustained rate as the allowance refills.

Need more? Contact support@tryverifyemail.com.

Every response from the verify endpoint carries your current standing — successes and 429s alike. From a Starter key:

RateLimit-Limit: 3
RateLimit-Remaining: 5
RateLimit-Reset: 1
Header Meaning
RateLimit-Limit Your plan’s sustained rate, in requests per second.
RateLimit-Remaining Requests you can make right now, this instant.
RateLimit-Reset Seconds until your full burst allowance is available again. A duration, not a timestamp.

Over the limit, the API returns 429 Too Many Requests with a Retry-After header and a matching retry_after field, both in whole seconds:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
RateLimit-Limit: 3
RateLimit-Remaining: 0
RateLimit-Reset: 2
{ "error": "rate_limited", "retry_after": 1 }

A 429 never costs a credit. The limit is applied before the address reaches the verification engine, so a throttled request is not billed and does not appear in your history — retrying it costs you nothing but the wait.

  • Sleep for Retry-After seconds, then retry.
  • Use exponential backoff with jitter when retries keep failing, so a fleet of workers does not resynchronise into the same spike.
  • For large volumes, prefer bulk jobs over many single requests — they are queued and run at the fleet’s own pace, with no rate limit to manage.
attempt 1 → wait 1s → attempt 2 → wait 2s → attempt 3 → wait 4s → …

See Errors for the full list of status codes.