Rate limiting caps the number of requests an API or service accepts within a defined time window. Rules like "60 requests per minute" or "1,000 requests per day" are enforced, and requests exceeding the limit receive an HTTP 429 (Too Many Requests) response. That status code is defined in RFC 6585 and tells the client it has sent too many requests in a given amount of time.
Rate limiting serves three purposes: server protection (preventing service outages from request floods), fairness (stopping individual users from monopolizing resources), and cost management (controlling pay-per-use cloud billing).
URL shortening services apply rate limiting in several areas: URL shortening API request limits (preventing spam-like mass generation), access limits on shortened URLs (mitigating DDoS attacks), and login attempt limits on dashboards (blocking brute-force attacks).
Four main rate limiting algorithms exist. Fixed window resets a counter at regular intervals. Sliding window continuously calculates requests within the most recent time frame. Token bucket replenishes tokens at a steady rate, consuming one per request. Leaky bucket processes requests at a constant rate, queuing any excess.
Developers working with rate-limited APIs should check the response headers and adjust request frequency based on the remaining quota. Header names differ from service to service: forms such as X-RateLimit-Limit and X-RateLimit-Remaining became a de facto convention, while a standard set of RateLimit headers is still being drafted at the IETF (an Internet-Draft as of August 2026). When a 429 response arrives, follow the Retry-After header if one is present and wait as instructed. If the header is missing, or if retrying after the wait still returns 429, add exponential backoff and lengthen the wait step by step. The two are separate measures: following Retry-After is not by itself exponential backoff.