What is the Valid Email Checker API rate limit?

Rate limits keep the platform stable for everyone. The actual numbers vary by endpoint — /verify-single and /verify-bulk share the same envelope, while /get-results gets a higher per-minute cap because polling is its primary use case.

The exact limits

Per-minute uses a rolling 60-second window, not a fixed clock minute — the counter is the number of requests in the last 60 seconds at any moment. Daily resets at midnight UTC.

Rate-limit headers (returned on every response)

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-DailyLimit-Remaining: 9500

Read these on every response and slow down when X-RateLimit-Remaining drops below 10. Far better than hitting the wall and reacting to a 429.

What a 429 response looks like

Per-minute limit exceeded

{
  "error": "Rate limit exceeded",
  "limit": 60,
  "window": "1 minute",
  "current": 61,
  "retry_after_seconds": 45
}

Response headers include Retry-After: <seconds> and X-RateLimit-Reset: <unix-timestamp> so you do not have to guess the wait time.

Daily limit exceeded

{
  "error": "Daily limit exceeded",
  "limit": 10000,
  "current": 10001,
  "resets_at": "midnight UTC"
}

Why these limits exist

Two reasons. First, we want every customer's API calls to stay snappy — uncapped concurrency from one account can degrade response times for everyone else hitting the same provider. Second, our upstream verification providers have their own rate limits, and exceeding theirs risks getting our verification IPs blocked by mail providers. The 60-per-minute envelope gives plenty of headroom for normal signup-form flows while keeping things stable platform-wide.

For higher volume

Two paths:

• Use bulk verification instead of looping single-verify calls. For anything beyond a few hundred addresses, the bulk endpoint is faster, cheaper in API calls (one call instead of N), and not subject to the per-minute cap on a per-address basis — a 50,000-email bulk task counts as one request.
• Request a custom limit on Enterprise. If your real-time use case genuinely needs above 60/minute or 10K/day for /verify-single, email support@validemailchecker.com with your expected volume. Enterprise plans can raise the caps case-by-case.

How to back off cleanly

When you hit a 429, the response body includes retry_after_seconds. Wait that long, then retry the same request. Do not retry every 100ms in a loop — you stay stuck and the IP-blocking circuit-breakers eventually notice the abuse pattern.

async function verifyWithBackoff(email, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(
      'https://app.validemailchecker.com/api/verify-single',
      {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${process.env.VEC_API_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({ email }),
      }
    );

    if (response.status === 429) {
      const data = await response.json();
      const wait = data.retry_after_seconds || 60;
      console.log(`Rate limited. Waiting ${wait}s before retry…`);
      await new Promise(r => setTimeout(r, wait * 1000));
      continue;
    }

    return response.json();
  }
  throw new Error('Max retries exceeded');
}

See API rate limits and error handling for the full pattern set (Python included), error code matrix, and IP-blocking behavior.

Common questions

Are limits per key or per account?

Per account. All API keys on the same account share the 60/min and 10,000/day envelope. Splitting into multiple keys does not give you more capacity.

Why is `/get-results` higher (120/min)?

Polling. Bulk verification is asynchronous — you create a task, then poll get-results until it completes. The polling cadence for medium-to-large tasks needs more headroom than the once-per-event single-verify pattern. 120/min still gives plenty of safety margin even for tight 1-second poll loops.

Next steps