Rate Limits
The Benchmark Email API enforces two levels of rate limiting to ensure fair usage and platform stability: an hourly rate limit and a monthly quota.Hourly Rate Limit
Each account is limited to 3,600 requests per hour, which is approximately 1 request per second sustained. This limit applies across all API keys on the account — if you have multiple keys, they share the same hourly budget.Rate Limit Response Headers
Every successful API key request includes headers showing your current rate limit status:| Header | Description | Example |
|---|---|---|
X-RateLimit-Limit | Maximum requests allowed per hour | 3600 |
X-RateLimit-Remaining | Requests remaining in the current hour | 3542 |
X-RateLimit-Reset | Unix timestamp (seconds) when the hourly window resets | 1711828800 |
Monthly Quota
Each account has a monthly API request quota that resets at the start of each billing period. The default quota is calculated as:Monthly Quota Response Headers
| Header | Description | Example |
|---|---|---|
X-Monthly-Limit | Maximum requests allowed in the current billing period | 100000 |
X-Monthly-Remaining | Requests remaining in the current billing period | 98750 |
Exceeding Rate Limits
When you exceed either limit, the API returns a429 Too Many Requests response.
Hourly Limit Exceeded
Retry-After header indicates how many seconds to wait before retrying.
Monthly Quota Exceeded
Retry-After value indicates the number of seconds until the billing period resets.
Handling Rate Limits
Best Practices
-
Monitor response headers. Check
X-RateLimit-RemainingandX-Monthly-Remainingon each response to stay within limits. -
Use exponential backoff. When you receive a
429response, wait for the duration specified in theRetry-Afterheader. If you continue to receive429responses, increase the wait time exponentially:Cap the maximum wait at 5 minutes (300 seconds). - Spread requests evenly. Instead of bursting 3,600 requests in a few minutes, distribute them evenly across the hour (~1 per second).
- Cache responses. If you repeatedly fetch the same data, cache it locally instead of re-requesting it from the API.
Example: Retry Logic (pseudocode)
Failed Authentication Protection
To protect against key probing and brute-force attacks, the API monitors failed authentication attempts by IP address. If an IP address sends too many requests with invalid API keys, it will be temporarily blocked. During a block, all API key requests from that IP address receive a429 Too Many Requests response:
Retry-After header indicates when the block will expire. To avoid triggering this protection:
- Verify your API key is correct before sending many requests.
- Do not cycle through possible key values.
- If you receive repeated
401responses, stop and check your key rather than retrying immediately.
Summary
| Limit | Threshold | Scope | Reset |
|---|---|---|---|
| Hourly rate limit | 3,600 requests/hour | Per account (shared across all keys) | Fixed 1-hour window |
| Monthly quota | Contact limit x 10 (default) | Per account | Billing period start |
| Failed auth blocking | Excessive invalid keys per IP | Per IP address | Automatic (temporary block) |
Next Steps
- Errors — understand all error responses
- Authentication — API key setup and scopes