API Rate Limits Explained: Designing Around 429s

A rate limit caps how many requests an API key can make in a given window — for Cut.bd, per minute. Hit the cap and the next request gets back 429 Too Many Requests instead of doing anything useful. That's not a bug to work around; it's the API telling you to slow down, and designing for it up front is much easier than retrofitting it after an integration starts failing in production.

Why rate limits exist at all

Without a limit, one misbehaving script — an infinite retry loop, a forgotten cron job firing every second instead of every hour — can degrade the API for every other key on the platform. Per-key limits contain the damage to the key that caused it.

Reading the response headers

Every Cut.bd API response — not just 429s — includes headers that tell you exactly where you stand:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 12
X-RateLimit-Reset: 1716123456
Retry-After: 12

X-RateLimit-Remaining hitting zero is your early warning — checking it lets you throttle proactively instead of waiting for a 429 to find out.

Three patterns that actually work

1. Exponential backoff on 429 — wait Retry-After seconds, and double the wait on repeated failures rather than hammering the limit again immediately.
2. Queue and throttle client-side — if you know your key's limit (3 to 360 req/min depending on plan), rate-limit your own outgoing requests below that ceiling instead of relying on retries.
3. Batch where the API allows it — fewer, larger requests use less of your allowance than many small ones for the same amount of work.

If your integration is consistently hitting the ceiling rather than occasionally bursting into it, that's a signal to move to a plan with a higher limit, not to fight the limiter harder — Cut.bd's API rate limits scale from 3 req/min on Free up to 360 req/min on Ultimate.