Transloadit

What is API Rate Limiting?

API rate limiting restricts the requests a client may make within a defined period or resource budget. A service can apply limits by account, credential, endpoint, address, or another usage boundary.

How API Rate Limiting works

A rate limiter counts requests, or a weighted cost per request, against a quota that belongs to a partition such as an account, credential, IP address, or endpoint, and more than one policy can apply to the same request. The counting algorithm decides how bursts are treated. A fixed-window counter resets at each window boundary, so a client can spend one window’s quota just before the reset and the next window’s just after it. A sliding window smooths that edge, for example by adding the previous window’s count weighted by how much of that window still overlaps. A token bucket adds tokens at a steady rate up to a fixed capacity, and that capacity bounds the burst it admits. A leaky bucket drains at a steady rate; NGINX’s implementation delays excess requests by default and rejects them once they exceed the configured burst size. A service can run several limiters side by side, for example a request rate, a cap on concurrent requests, and a separate budget for expensive or content-creating operations, so staying under one limit does not mean staying under all of them. When a request is refused, the response can state how long to wait, which lets clients spread their retries instead of returning all at once.

Key facts

  1. HTTP defines status 429 Too Many Requests for a rate-limited request, and the response may include a Retry-After header, but neither is guaranteed. GitHub documents that it can answer with 403 or 429, together with an x-ratelimit-remaining header of 0 or an error message saying a rate limit was exceeded, and NGINX’s limit_req module rejects with 503 unless limit_req_status is set. Detect throttling from the status codes, headers, and error body that the API documents, not from 429 alone.
  2. Retry-After is either a number of seconds to wait after the response is received or an HTTP date, so a client has to parse both forms. Some APIs report the wait elsewhere: GitHub also uses x-ratelimit-reset, a time in UTC epoch seconds, and other services put a delay in the JSON error body. Read the wait from the place and in the unit that the API documents.
  3. No finished standard exists for advertising remaining quota. The RateLimit and RateLimit-Policy header fields are an IETF Internet-Draft (revision 11, dated May 2026), not an RFC, and deployed APIs use vendor-specific names such as x-ratelimit-remaining. The draft tells clients not to treat the advertised quota as a guarantee and gives Retry-After precedence when a response carries both.
  4. Reported quota can be inexact, because limiters that run across many servers share or approximate their counters. GitHub notes that the remaining count can differ from one response to the next when requests are handled in several regions and advises against logic that depends on an exact remaining count; Amazon API Gateway describes its throttles and quotas as best-effort targets, not guaranteed ceilings. Pace requests from the reported values, but keep handling a limit response even when the last response showed quota left.

When API Rate Limiting matters

Rate limits shape any client that sends requests in bulk or in parallel, such as imports, polling loops, batch jobs, and retry logic. Find the API’s documented limits and its limit response before building the client, then wait at least as long as that response says, add random jitter so parallel workers do not all retry at the same moment, and cap the number of attempts. When a limit response states no wait, use the fallback the API documents, or failing that a delay that grows exponentially with each attempt up to a maximum. Retrying immediately adds load and can prolong the throttling, and some providers, GitHub among them, warn that an integration that keeps sending requests while limited may be banned.

How Transloadit helps with API Rate Limiting

Transloadit rate-limits its own API and documents the current limits on its rate limiting page. A request rejected for exceeding a creation or concurrency limit returns a JSON error that states a recommended wait in seconds, and Transloadit’s official SDKs already apply that backoff and retry.

The stated wait is a recommended backoff: the documentation says it does not guarantee that capacity will be available once it has passed. The same page describes a separate high-frequency limit, and the response shown for it includes no wait time, so a client handling it has to supply its own backoff delay.

Explore Transloadit’s platform capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free