Rate Limiting

Rate limiting is the mechanism that controls how many requests a client can send to an API within a given time window, for example 100 calls per minute. When that quota is exceeded, the server responds with an HTTP 429 (Too Many Requests) status code and generally rejects the excess requests until the window resets.

Its purpose is to protect the infrastructure: it prevents a single client, a bug in a loop or an attack from saturating resources and degrading the service for everyone. It also lets a provider distribute capacity fairly among all its consumers and, in many cases, monetize access through plan tiers.

In the ecosystem of platforms like Salesforce, rate limiting is one of the controls that frame any serious integration. When a project on Salesforce consumes external APIs or exposes its own, rate limiting defines the safe pace at which systems can talk to each other without breaking one another.

How it works in practice

The server keeps count of the requests it receives from each client, usually identified by its API key, its token or its IP address. If the client is within its quota, the request is processed normally; if it exceeds it, the request is rejected with a 429 without consuming heavy compute resources. Many APIs include informational headers with the response, such as `X-RateLimit-Remaining` (how many calls are left) and `Retry-After` (how many seconds to wait before retrying), which lets a well-built client self-regulate instead of hammering away.

Behind it are several classic algorithms, each with a different trade-off between simplicity and precision:

• Token bucket: a bucket fills with tokens at a constant rate and each request consumes one; it allows short bursts as long as there are tokens saved up. It is the most widely used because of its flexibility.
• Leaky bucket: requests go out at a fixed rate, like water through a hole; it smooths out peaks but does not reward prior inactivity.
• Fixed window: requests are counted in closed blocks of time (per minute, per hour); it is simple but suffers from the edge problem, where two bursts right at the window change double the real traffic.
• Sliding window: a moving window that corrects that edge effect at the cost of more computation.

Why it matters to the business (and not just to IT)

Although it sounds technical, rate limiting has very concrete consequences. A nightly sync that pushes orders into Salesforce can fail halfway through if it fires more calls than allowed and the provider starts returning 429s. The visible result for the business is stale data, incomplete reports or a webhook that stops sending notifications. That is why sizing limits correctly and handling retries is part of any stable integration, not an optional detail.

A concrete example in Argentina and Latin America

Consider an Argentine e-commerce business that queries a payment provider's API to check the status of each transaction. On a high-demand day (a CyberMonday, for example), the system tries to check thousands of transactions per minute. If it exceeds the provider's limit, responses start coming back as 429s and some customers see their payment as "pending" when it has actually been approved. The right fix is not to insist faster but to apply exponential backoff: on a 429, wait, retry with increasing pauses and respect the `Retry-After` header. The same applies when integrating the WhatsApp Business API, ARCA (Argentina's federal tax agency, formerly AFIP) for e-invoicing, or any service that charges for and protects its capacity through quotas.

Common mistakes to avoid

• Treating the 429 as a permanent failure instead of a "wait and retry": you lose data that could have been recovered.
• Ignoring the `Retry-After` or `X-RateLimit-*` headers and retrying immediately, which makes things worse.
• Not distinguishing rate limiting (a limit on pace, reversible by waiting) from a total quota (a volume limit per day or month, which is not freed up by retrying).
• Confusing traffic control with a platform's internal governor limits, which are a different layer of protection.

How it differs from similar concepts

In short, rate limiting is a silent defense that keeps APIs available and predictable. Understanding it lets you design integrations that behave well under pressure, recover data without losing it and coexist peacefully with the limits each provider sets to protect its service.