Rate Limits

VerifNow enforces quotas per billing period and concurrent request limits to ensure fair usage and API stability. This guide explains the limits for each plan and how to handle them.

Plans & limits

How quotas work

• FREE plan: once you reach 250 validations in your billing period, subsequent requests are blocked with a 429 response. The FREE plan runs the same STANDARD checks as STARTER — the two differ in volume, not in depth.
• Paid plans (STARTER, GROWTH, PRO): requests above the included quota are not blocked. Instead, they are billed per unit at the end of the billing period.
• Quota reset: quotas reset at the start of each billing period. The billing period is tied to your subscription start date — for example, if your subscription started on the 4th, quotas reset every 4th of the month for a monthly subscription.

Limits are per account, not per key: every API key on your account draws on the same quota and the same concurrency allowance.

Concurrent request limits

Each plan has a maximum number of simultaneous (concurrent) requests that can be in-flight at the same time. If you exceed this limit, the API returns a 429 Too Many Requests response — regardless of your plan.

For service protection, non-PRO plans (FREE, STARTER, GROWTH) are also subject to shared per-server concurrency controls. This means a request from a non-PRO plan can occasionally receive a 429 even if it is the only request currently in flight for that API key, or even if you are still within your plan’s documented concurrent request limit.

API key limits

Each plan has a maximum number of active API keys you can have at the same time:

If you need more API keys, consider upgrading your plan at app.verifnow.io .

Rate limit headers

Every successful validation carries your quota state:

HTTP/2 200
X-RateLimit-Limit: 10000
X-RateLimit-Remaining: 9812
X-RateLimit-Reset: 1790985600
X-Request-Id: 7d0e…

The Node.js SDK reads these for you: result.quota in @verifnow/sdk carries limit, remaining, resetAt (a Date) and overage.

When you get a 429

A 429 means one of two very different things. Tell them apart before retrying — one clears in a second, the other not before your period resets.

Too many requests in flight (all plans)

You sent more simultaneous requests than your plan allows. It clears as soon as one of your requests finishes.

HTTP/2 429
Retry-After: 1
 
{"status": 429, "message": "Too many requests in flight for this account. Retry in a moment."}

Retry after Retry-After seconds — the Node.js SDK does this automatically. If it keeps happening, you are sending more in parallel than your plan allows: lower your concurrency, or move up a plan.

Monthly quota spent (FREE plan)

Only the FREE plan is blocked at its quota. The edge rejects the request before it reaches the API, and tells you where you stand:

HTTP/2 429
 
{"error": "Monthly quota exceeded", "limit": 250, "usage": 250, "periodStart": "2026-09-04"}

It will not clear before the period resets, so do not retry: upgrade, or wait for the next period. In the rare case where the API enforces the quota itself, the response is {"status": 429, "message": "Monthly quota exceeded. Upgrade your plan or wait for the next period."} with a Retry-After counting down to the reset — days, not seconds.

Overage on paid plans

On paid plans (STARTER, GROWTH, PRO), requests above the included quota are allowed and billed at the per-unit rate at the end of the billing period. They carry X-Quota-Overage: true:

HTTP/2 200
X-RateLimit-Limit: 10000
X-RateLimit-Remaining: 0
X-Quota-Overage: true

Watching your quota in code

With the SDK, every result carries the quota state it was answered with:

import { VerifNow, VerifNowRateLimitError } from '@verifnow/sdk'
 
const client = new VerifNow({ apiKey: process.env.VERIFNOW_API_KEY! })
 
export async function validateAndWatchQuota(email: string) {
  try {
    const result = await client.validateEmail(email)
 
    const quota = result.quota
    if (quota?.remaining !== undefined && quota.remaining < 50 && !quota.overage) {
      console.warn(`Low quota: ${quota.remaining} left, resets ${quota.resetAt?.toISOString()}`)
    }
    return result
  } catch (error) {
    if (error instanceof VerifNowRateLimitError) {
      // The SDK has already retried a concurrency 429. What reaches you here is, in practice,
      // a spent FREE quota: surface it rather than sleeping on it.
      console.error('VerifNow quota exhausted', { retryAfterSeconds: error.retryAfterSeconds })
    }
    throw error
  }
}

Without the SDK, read the same headers from the response — and branch on Retry-After for a 429, as described above.

Best practices

1. Monitor X-RateLimit-Remaining in every response — don’t wait for a 429 to find out
2. Retry a 429 only when Retry-After is short — that is a concurrency limit. A spent quota will not clear by waiting. See Error Handling
3. Cache results — if you’ve already validated an email recently, reuse the result
4. Upgrade your plan if you consistently exceed your quota — visit app.verifnow.io 
5. Track your usage in the dashboard  under Usage & Billing

Quota reset schedule

Quotas are reset at the start of each billing period, aligned with your subscription start date:

• Monthly subscription started on the 4th: quota resets on the 4th of each month
• Monthly subscription started on the 15th: quota resets on the 15th of each month

This is different from a calendar-month reset. Check the X-RateLimit-Reset header or your dashboard for the exact reset date.