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 with Retry-After: 2.

A naive loop retries at once, gets another 429, and burns the night doing it. Better clients read the header and sleeps for the two seconds it was told to. If there's no header, it waits 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.

One detail trips up parsers. Retry-After can be a number of seconds or a full HTTP date such as Wed, 21 Oct 2026 07:28:00 GMT. Both are valid under the HTTP specification, so handle both, 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.