Rate limiting caps how fast a client can make requests, so one user or script cannot overwhelm a system.
Key points
- HTTP status 429 Too Many Requests, defined in RFC 6585, is the standard response when a client exceeds a limit [1][2].
- Servers can send a Retry-After header, defined in RFC 9110, telling the client how long to wait [3].
- Common algorithms include fixed windows, sliding windows and the token bucket, which allows short bursts within an average rate [4].
- OWASP lists missing limits on resource consumption among the top API security risks [5].
- Email has its own form of rate limiting: mailbox Sending Limits and receiver-side throttling that shows up as a Soft Bounce.
How rate limits work
A rate limiter counts requests from each client, usually identified by an API Key, a user account or an IP address, and rejects requests over the allowed rate. The simplest design is a fixed window, such as 100 requests per minute that resets on the minute. Sliding windows smooth out the edges. The token bucket algorithm adds tokens at a steady rate up to a maximum, and each request spends one, which allows short bursts while holding the average rate [4]. When a client is over the limit, a REST API typically returns status 429, which RFC 6585 defines for this purpose [1]. MDN notes that the response may include a Retry-After header indicating how long to wait before trying again [2][3].
Why providers limit
Limits protect shared systems. Without them, one buggy script or aggressive integration can slow a service for every customer, and an attacker can try passwords or scrape data at high speed. OWASP's API Security Top 10 lists unrestricted resource consumption as a major risk, noting that missing limits can lead to denial of service and higher operating costs [5]. Limits also enforce commercial terms: many APIs set different limits by plan, and under Usage-Based Pricing each call may be billed. For clients, this means limits are part of the contract. Integrations should read the documented limits, track their own usage, and treat a 429 as a normal condition to handle rather than an unexpected error.
Handling limits in sales automation
Sales automation touches many rate-limited systems at once: the CRM (Customer Relationship Management) API, enrichment services, mailbox APIs and the mail servers of every recipient. A Workflow Automation that ignores limits will fail in bursts, often at the worst time, such as during a large import. The fixes are standard: queue work instead of sending it all at once, back off exponentially after a 429, honor Retry-After, and spread jobs across the day. Email sending needs its own caps. Mailbox providers set daily Sending Limits, and receiving servers throttle senders they do not trust yet, which is one reason Email Warmup increases volume slowly. Keeping a daily send limit per mailbox protects Sender Reputation as much as it respects provider rules.
Related terms
Outreach without the busywork.
PineLead finds new B2B prospects every day, qualifies them against your criteria and writes the first email in your voice. You approve — PineLead sends.
Start free with 100 credits →