What is API Rate Limiting & Throttling?

Rate limiting is a control that caps how many requests a client may make per window; throttling slows the excess instead of rejecting it. Add the third sibling — the quota, a billing-period allowance — and you have the full vocabulary most explanations blur into one word. Together they are how APIs stay fair, solvent, and up.

Key takeaways

What the 429 response and rate-limit headers mean

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← wait this long (seconds or a date)
X-RateLimit-Limit: 1000               ← your budget this window
X-RateLimit-Remaining: 0              ← what's left
X-RateLimit-Reset: 1767024000         ← when it refills
RateLimit: "default";r=0;t=30         ← the emerging IETF standard form

The client half of the contract — the code every SDK consumer eventually needs:

// JavaScript / Node.js — Back4app JS SDK
// The client half of rate limiting: back off, with jitter, then retry
async function withBackoff(fn, attempt = 0) {
  try {
    return await fn();
  } catch (e) {
    if (e.code !== 155 || attempt >= 4) throw e;   // 155: request limit hit
    const wait = 2 ** attempt * 500 + Math.random() * 200;
    await new Promise((r) => setTimeout(r, wait)); // exponential + jitter
    return withBackoff(fn, attempt + 1);
  }
}
const results = await withBackoff(() => query.find());

// Flutter / Dart — Back4app Flutter SDK
// The client half of rate limiting: back off, with jitter, then retry
Future<ParseResponse> withBackoff(Future<ParseResponse> Function() fn,
    [int attempt = 0]) async {
  final response = await fn();
  if (response.success || attempt >= 4) return response;
  final wait = (1 << attempt) * 500 + Random().nextInt(200);
  await Future.delayed(Duration(milliseconds: wait)); // exponential + jitter
  return withBackoff(fn, attempt + 1);
}
final response = await withBackoff(() => query.query());

// iOS / Swift — Back4app Swift SDK
// The client half of rate limiting: back off, with jitter, then retry
func withBackoff<T>(_ attempt: Int = 0,
                    _ fn: @escaping () async throws -> T) async throws -> T {
  do { return try await fn() }
  catch {
    guard attempt < 4 else { throw error }
    let wait = pow(2.0, Double(attempt)) * 0.5 + .random(in: 0...0.2)
    try await Task.sleep(for: .seconds(wait))   // exponential + jitter
    return try await withBackoff(attempt + 1, fn)
  }
}
let results = try await withBackoff { try await query.find() }

// Android / Kotlin — Back4app Android SDK
// The client half of rate limiting: back off, with jitter, then retry
suspend fun <T> withBackoff(attempt: Int = 0, fn: suspend () -> T): T {
  return try {
    fn()
  } catch (e: ParseException) {
    if (attempt >= 4) throw e
    val wait = (1L shl attempt) * 500 + Random.nextLong(200)
    delay(wait)                                 // exponential + jitter
    withBackoff(attempt + 1, fn)
  }
}
val results = withBackoff { query.find() }

Token bucket vs. leaky bucket vs. fixed window vs. sliding window

One distributed footnote the diagrams skip: with many API servers, the bucket must live somewhere shared — typically an in-memory store doing atomic increments — and you choose between strict accuracy (every check hits the store) and speed (local counters, loose sync). Most platforms accept slightly-loose limits as the price of latency; contractual quotas get the strict treatment.

Scoping: who exactly is limited?

Per-IP stops anonymous floods and DDoS absorption-leakage, but an office NAT makes hundreds of users one address. Per-key maps limits to applications and pricing plans — the workhorse scope. Per-user keeps one account from monopolizing a shared app’s key. Per-endpoint prices expensive operations honestly — search and export endpoints deserve tighter budgets than health checks. Production systems layer them; the composite question is always “which budget did this request spend?”

Common use cases

• Public API protection — the canonical case: fair budgets per key, published in headers, enforced at the edge.
• Tier enforcement — free vs. paid plans differing precisely in quota and burst allowance.
• Abuse and scraping defense — tight anonymous limits, generous authenticated ones.
• Cost control on expensive paths — LLM calls, exports, searches: per-endpoint budgets that reflect real cost.
• Client-side self-defense — backoff and request coalescing against other people’s limits, which your integrations must respect to stay unbanned.

Reject or throttle? A decision matrix

And the meta-rule: whatever you choose, publish it — limits in documentation and headers turn a frustrating wall into an engineering contract clients can build against.

Limitations and trade-offs

• Limits are blunt instruments. A request is not a cost unit — one cheap read and one monster export both spend “1.” Cost-aware limiting (points per operation) is the refinement, at complexity’s price.
• Distributed accuracy costs latency. Strict global counters serialize on a shared store; loose local ones over-admit at the margins. Pick per guarantee, not per fashion.
• 429s punish the innocent retry loop. Clients without jitter synchronize into thundering herds; your limiter’s design must assume the worst client, because it will meet them.
• Throttling hides overload. Queued requests smooth graphs while building invisible backlog; queues need bounds and shed policies or they become outage delays.
• Limits are product decisions wearing ops clothing. Budgets, tiers, and burst allowances shape user experience and revenue — set them with the pricing page open, not just the dashboard.

Rate limiting on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Protection is a platform default rather than a project: request limits apply at the edge per app and plan, expensive operations can be gated behind Cloud Code functions with their own checks, and clients receive clean 429 semantics — which the SDK-side backoff pattern in the code tabs above turns into resilient behavior instead of failed screens. You tune policies; you don’t build the limiter.