What is an API rate limit?

Read the headers rather than guessing. A limit, a remaining count and a reset timestamp are standard, and Retry-After on the 429 names the wait in seconds.

Back off exponentially with a little randomness added. Without the jitter, every client that hit the wall retries in the same instant and rebuilds the spike that caused it.

Limits exist because the work behind them is real. Verification opens outbound connections to third-party mail servers, and an unbounded client would generate the traffic pattern those servers rate-limit in turn.

For large volumes the bulk endpoint is the right tool. Submitting a file as one job removes the per-request ceiling entirely, which is what it is for.

Say your nightly job verifies new CRM contacts one at a time and fires 40 requests a second. Suppose the API allows 10 a second on your plan. Within the first second you get a 429 Too Many Requests.

A naive loop retries at once, gets another 429, and burns the night doing it. Better clients wait out the rate-limit window. If the response names no wait time, they wait one second, then two, then four, doubling up to a cap of about a minute, and add a random fraction of a second each time so parallel workers don't wake together.

ZapBounce's 429 carries no Retry-After header. It sends X-RateLimit-Limit and X-RateLimit-Window-Seconds, so the window is known but the wait is yours to choose. Other APIs may send Retry-After as seconds or as an HTTP date, so handle both there and fall back to your own backoff for anything you can't parse.

Reacting to 429s is the safety net. The better design is a client that doesn't exceed the limit in the first place. A token bucket does this in a few lines: you get ten tokens a second, each request spends one, and a request with no token waits. Your 40-a-second job becomes a steady 10 and finishes sooner than the one that kept getting locked out.

Rate and concurrency are separate limits. One counts requests per second and the other counts how many are in flight at once. Verification calls can take a while when a mail server is slow, so 10 requests a second at three seconds each means 30 open connections. Some APIs cap that figure separately.

Don't confuse a 429 with a 503. The first is about you and clears when you slow down, while a 503 means the service is struggling and you should back off harder. When the job is thousands of addresses, stop looping and send the file as one bulk job instead.