Most people don’t think about rate limiting until a bill or an outage forces them to. I’ve watched a single retry loop, written by someone who assumed the validation API would always answer, quietly fire the same lookup a few thousand times in an afternoon. The number was already cached. The code just never checked. Nobody noticed until the usage dashboard did.
Phone validation calls cost money per request, which makes rate limiting less of a hygiene item and more of a budget control. Get it right and your costs stay flat and predictable while traffic spikes. Get it wrong and a bug, a bot, or a good marketing day turns into a problem. Here’s how I’d set it up with an API like CheckThatPhone.
The failure modes you’re guarding against
Without limits in place, an integration tends to fail in a handful of predictable ways:
- Runaway costs from a bug or a malicious caller
- Provider-side throttling when you flood the endpoint
- Legitimate users blocked because abuse traffic ate the budget
- Form spam and bot traffic hammering a public lookup
Rate limiting is the thing that keeps one bad actor, or one bad deploy, from spending your month’s quota in an hour.
The two kinds of limits you’ll hit
Short-interval limits
Most phone validation APIs, CheckThatPhone included, cap requests per second or per minute to smooth out spikes. These usually sit somewhere in the 10 to 100 requests per second range depending on your pricing tier.
This is the limit a marketing campaign trips. Validation runs fine all quarter, then a promo drives thousands of signups in the same ten minutes and every one of them fires a lookup at once. That’s the moment you find out whether you queue or just start throwing errors at users.
Daily and monthly quotas
The longer-horizon limits are about cost, not bursts. Carrier lookup, line type detection, and portability all draw from your monthly allocation on CheckThatPhone, so you want to know roughly where you’ll land before the month is half gone.
Client-side: smooth out your own traffic first
Queue requests instead of dropping them
When you’re near a limit, the wrong move is to reject the user. Queue the work and drain it at a rate you control:
class PhoneValidationQueue {
constructor(maxRequestsPerSecond) {
this.queue = [];
this.processing = false;
this.interval = 1000 / maxRequestsPerSecond;
}
async add(phoneNumber) {
return new Promise((resolve, reject) => {
this.queue.push({ phoneNumber, resolve, reject });
this.process();
});
}
async process() {
if (this.processing || this.queue.length === 0) return;
this.processing = true;
const { phoneNumber, resolve, reject } = this.queue.shift();
try {
const result = await validatePhone(phoneNumber);
resolve(result);
} catch (error) {
reject(error);
}
setTimeout(() => {
this.processing = false;
this.process();
}, this.interval);
}
}Back off when you get a 429
When the API returns a 429, don’t retry immediately. Space the retries out so you stop adding to the pile-up:
async function validateWithBackoff(phoneNumber, maxRetries = 3) {
for (let i = 0; i < maxRetries; i++) {
try {
return await checkThatPhoneAPI.validate(phoneNumber);
} catch (error) {
if (error.status === 429 && i < maxRetries - 1) {
const delay = Math.pow(2, i) * 1000; // 1s, 2s, 4s
await new Promise(resolve => setTimeout(resolve, delay));
continue;
}
throw error;
}
}
}Cache results, because numbers don’t change much
A phone number’s carrier and line type are stable for weeks at a time, so re-validating the same number on every page load is wasted spend. Caching is the single biggest lever you have on cost:
- Keep validation results for at least 24 hours
- Keep carrier and line type data for 7 to 30 days
- Key the cache on the phone number itself
- Invalidate when a user reports something wrong
This works especially well for CheckThatPhone’s geolocation and portability data, which barely moves over time. The retry loop I mentioned earlier would have been harmless if it had checked the cache first.
Server-side: protect against everyone else
Per-user limits
Cap how much any one authenticated user can spend so a single account can’t drain your quota:
from functools import wraps
from flask import request, jsonify
import time
user_requests = {}
def rate_limit(max_per_minute=10):
def decorator(f):
@wraps(f)
def wrapped(*args, **kwargs):
user_id = request.user_id
now = time.time()
if user_id not in user_requests:
user_requests[user_id] = []
# Remove requests older than 1 minute
user_requests[user_id] = [
req_time for req_time in user_requests[user_id]
if now - req_time < 60
]
if len(user_requests[user_id]) >= max_per_minute:
return jsonify({"error": "Rate limit exceeded"}), 429
user_requests[user_id].append(now)
return f(*args, **kwargs)
return wrapped
return decoratorIP throttling on public forms
Anything unauthenticated needs IP-based limits. Lead capture forms that validate a number before submission are a favorite target for spam, and an IP cap keeps a script from grinding through your quota without locking out real visitors. It’s a blunt tool, but for public forms it’s the right one.
Watch the numbers before they bite
Track at minimum:
- Request volume and traffic patterns
- 429 responses over time
- Response times and error rates
- How fast you’re burning the monthly quota
Set an alert at 80% of any limit so you hear about a problem while you still have room to react, not after requests start failing. The CheckThatPhone docs cover how to read the API responses you’ll be monitoring.
When you validate matters as much as how often
Real-time or batch?
Decide which lookups truly need an immediate answer:
- Real-time: registration, checkout, contact forms
- Batch: database cleanup, CRM enrichment, marketing list verification
Batch work is where you have the most control. You set the pace, so you can run it right up against your limit without risking a user-facing failure.
Debounce form input
For live validation in a form, don’t fire on every keystroke. Wait until the user pauses:
let validationTimeout;
const phoneInput = document.getElementById('phone');
phoneInput.addEventListener('input', (e) => {
clearTimeout(validationTimeout);
validationTimeout = setTimeout(async () => {
if (e.target.value.length >= 10) {
await validatePhoneNumber(e.target.value);
}
}, 500); // Wait 500ms after user stops typing
});Skipping this is an easy way to turn one phone field into ten API calls per user.
Where to start
If you do only one thing, add caching: it cuts the most spend for the least code. Then add backoff so a 429 doesn’t snowball, and an 80% alert so you see trouble coming. Revisit the whole setup whenever your traffic doubles, because the limits that were comfortable at one scale get tight at the next. The CheckThatPhone documentation has the specifics for your tier.