Rate limiting

The public API allows:

60 requests per minute per IP address
120 requests per minute per workspace

Both limits apply at once. They are generous for an integration that creates a verification per person and relies on webhooks; they are reached by polling or by bulk jobs. The per-IP limit is counted for each workspace separately. Workspaces that call from the same IP address, such as several of yours on one server or the customers of an integration platform like Zapier, do not use up each other’s budget.

When you are over the limit

The API answers 429 Too Many Requests:

{
  "error": {
    "code": "RATE_LIMIT",
    "message": "Too many requests. Please try again later."
  }
}

with these headers:

Header	Meaning
`Retry-After`	Seconds until you may send again.
`X-RateLimit-Limit`	The limit that was hit.
`X-RateLimit-Remaining`	Requests left in the current minute: `0`.
`X-RateLimit-Reset`	Unix time, in seconds, when you may send again.

Wait Retry-After seconds, then retry. A 429 means the request was not processed, so retrying it is always safe, including a POST.

Staying under the limits

Let webhooks tell you about outcomes instead of polling GET /v1/verifications/{id}.
If you must poll, poll one verification at a time and no more often than every few seconds.
Spread bulk jobs, such as re-reading many results, over time.

The server SDKs wait for Retry-After and retry a 429 for you.

Guides

Recipes

Model Context Protocol (MCP)

Web

Server SDKs

Integrations

When you are over the limit

Staying under the limits

​When you are over the limit

​Staying under the limits

When you are over the limit

Staying under the limits