Rate Limiting

Capping how many requests a client may make in a time window, protecting the service from abuse and overload.

Rate limiting is a ceiling on request frequency: a client may send, say, sixty requests per minute, and anything beyond that gets rejected with a 429 or delayed. It is the standard mechanism for one API protecting itself from another's traffic, whether that traffic is hostile, buggy or just popular.

Why it matters to an indie builder: you sit on both sides of this rule. As a consumer, every AI and SaaS API you integrate throttles you, and unhandled 429s surface as user-facing failures at the worst moments, like launch day. As a provider, any endpoint that costs money to serve, model inference, scraping, exports, needs a limit before the first abusive client finds it. IndieBoot's own API throttles at sixty requests per minute, which is typical of the politeness budget you will encounter everywhere.

A concrete example: a bulk-enrichment feature fans out to a provider capped at 100 requests per minute. Naive code fires 800 concurrent calls: ninety percent fail with 429 and the retry storm makes it worse. Correct code maintains a queue, spaces requests at the budget, sleeps about 25 seconds on a 429 with exponential backoff, and finishes the batch in nine minutes with zero failures. Same provider, same budget, boring success.

Common mistakes: retrying immediately on 429 (respect the Retry-After header when present; hammering escalates some providers to temporary bans), limiting per account instead of per API key or IP when different customers share an account, skipping client-side rate awareness in scheduled jobs (cron plus cache is how outages begin), and not differentiating limits by endpoint cost: a read can be generous, a write that triggers inference cannot. The api and observability blocks on IndieBoot include gateways that manage this for you.