What is rate limiting?
- Rate limiting
- Rate limiting caps how many requests a system will accept from one source in a given period, rejecting anything above the cap to protect the service behind it.
What rate limiting means in practice
Two purposes sit behind almost every limit. Stopping abuse, and stopping one enthusiastic customer from starving everyone else.
Well-behaved systems say so clearly when they refuse. A specific status code, and a header telling you how long to wait.
Badly behaved ones just fail, which is how a limit becomes a mysterious integration bug that only appears on busy days.
The limit that matters is usually the one on a service you do not control, several layers down in whatever your tools are built on.
What people get wrong
Monday, 9:00 am, and a limit of 100 requests per 10 seconds
Say your CRM accepts 100 requests every 10 seconds per account. Most days you use a tiny share of that. Then on Monday at 9:00 a nightly import, a reporting tool and your phone system's call records all wake up together in the same minute. The import alone fires 400 requests in its first 10 seconds. Your CRM accepts 100 and answers the other 300 with status 429, "Too Many Requests", plus a Retry-After header that says 10.
A polite client reads that header and waits 10 seconds before trying again. Careless clients retry at once and fail again, which eats into the next window too. Here's the unlucky part: the limit is per account, not per tool. Your 9:01 call record gets a 429 because the import used up the allowance. Whether it reaches the CRM at 9:02 or never depends on how the sender treats a refusal.
How to tell if a limit is biting you
You rarely see a rate limit directly. What you see is symptoms: records missing from busy mornings and present on quiet afternoons, or a sync that runs "a bit behind" every Monday. If the gaps cluster at the top of the hour or right after a bulk job, suspect a limit before you suspect a bug.
Check a few places. Your CRM's developer docs state the limit, usually on a page called API limits or usage. Connector tools such as Zapier keep a task history that shows 429 errors by time. Bulk jobs of your own can often be moved to 2:00 am or slowed down with a setting.
Put one question to vendors: when the far end says slow down, do you wait and resend, and for how long before giving up? At 20 calls a day, the answer barely matters. Once you're at 300 a day, with two other tools sharing the account, it decides whether your records have holes.
How GreetKeeper handles it
Where GreetKeeper pushes a call record into another system, the connection is the place limits show up rather than the phone call itself.
Our integration matrix says which connections write natively and which route through Zapier, and that distinction changes which limits you meet.
Answering a call never waits on another system, so a slow integration does not become a caller listening to silence.
Rate limiting questions
How do I know a limit was hit?
A well-built system returns a specific refusal with a wait time attached. Where you get a generic error instead, limits are still the first thing worth suspecting.
Does it affect phone calls?
Not the call itself. It shows up in what happens afterwards, when records are being written into another system.
What is the right way to retry?
Back off progressively and add jitter. Immediate retries are the reason a brief limit turns into an outage.
Related terms
Hear it take one of your calls
Two minutes, your own scenario, no card.