Rate limits

every response tells you where you stand against the rate limit read the headers and back off on 429 and you'll never get surprised rate limit headers every response carries these headers header meaning x ratelimit limit your ceiling for the current window x ratelimit remaining requests left in the current window x ratelimit reset when the window resets the standardized draft equivalents ( ratelimit limit , ratelimit remaining , ratelimit reset ) are emitted too, so a client built against either spelling works the current limit is 10,000 requests per minute (this is the operating ceiling today, not a contractual floor — don't hard code it; read x ratelimit limit if you need the live value ) when you're limited exceeding the limit returns 429 with a rate limit error { "error" { "code" "rate limited", "message" "too many requests ", "type" "rate limit error", "request id" "req a1b2c3" } } the response includes a retry after header — the number of seconds to wait before retrying honor it handling it well retry on 429 (and on 5xx ) with exponential backoff, preferring the retry after value when present import time, requests def call with retry(session, url, max retries=5) for attempt in range(max retries) resp = session get(url) if resp status code != 429 return resp wait = int(resp headers get("retry after", 2 attempt)) time sleep(wait) return resp # give up after max retries for large workloads, prefer the batch endpoints over a tight loop of single email calls — submit a job and poll, rather than hammering /v1/verify see the quickstart and the api reference