API reference
Rate limits & headers
Compresr tier-based rate limits, the response headers you read to track remaining quota, and how to handle 429.
Compresr applies tier-based rate limits per API key, enforced per-minute and per-day, with separate quotas for request count and token volume. Every authenticated response carries headers that tell you exactly how much budget you have left. Read those instead of guessing.
Tiers
The table below is live; it fetches from GET /billing/tiers at page-load time, so the numbers are always current.
Response headers
Every authenticated response includes these headers. Read them on every request to track remaining budget in your own observability stack.
| Header | Meaning |
|---|---|
X-RateLimit-Limit-Minute | Requests-per-minute ceiling for your tier. |
X-RateLimit-Remaining-Minute | Requests left in the current 60-second window. |
X-RateLimit-Limit-Day | Requests-per-day ceiling for your tier. |
X-RateLimit-Remaining-Day | Requests left in the current 24-hour window. |
X-RateLimit-Tier | Tier identifier currently applied to your key (e.g. tier2). |
Retry-After | 429 responses only. Number of seconds to wait before retrying. |
Handling 429
When you exceed your per-minute or per-day request budget, the API returns 429 Too Many Requests with a Retry-After header. The right pattern is exponential backoff that respects Retry-After as a floor.
If you're hitting 429 routinely under normal load, the right fix is moving to a higher tier, not aggressive client-side retry. Retry handles spikes; tiers handle sustained throughput.