Skip to main content
All APIs have rate limits to ensure fair usage and system stability.

Standard Rate Limits

Exceeding the Rate Limit

Limits are enforced per client IP address over a one-minute window. Requests over the limit are rejected with HTTP 429 Too Many Requests and this body:
Key on the status code rather than parsing the body: the 429 is returned by our edge gateway, which labels the body Content-Type: text/html. Wait 60 seconds before retrying; a tight retry loop keeps the window full and extends the block.

Average API Response Times

Average response time per request. Unless otherwise noted (for example, the 1,000-number batch row), times are measured for a single phone number. These are averages measured by third-party monitoring services. Outliers will exist that are both faster and slower.

HTTP Method Requirements

Requests with more than 10 phone numbers must use HTTP POST. GET requests will fail. If you don’t know your payload size, use HTTP POST to prevent future issue.

Retry Example

You must plan what your system will do in the event of a network or service outage. Our recommendation is to implement retries with exponential backoff.

Best Practices

Instead of making 100 requests with 1 number each, make 1 request with 100 numbers.
If you receive a 5xx response, wait and retry with exponential backoff. If you receive a 429, you have exceeded your rate limit: wait 60 seconds, then retry.
Cache scrub results to avoid re-checking the same numbers unnecessarily.
Consider what your system will do in the event of a network or service outage. Implement retry logic with exponential backoff and have a fallback plan for when the API is unavailable.
For very large batches of phone numbers where real-time checking is not needed, consider using SFTP file upload instead of the API. This is more efficient for processing millions of records.

File Upload Limits for SFTP or Web Portal