Limits by endpoint
| Endpoint | Limit | Rationale |
|---|---|---|
POST /api/v1/classify | 5 RPM | Calls OCR + LLM; 10-30s per request |
POST /api/v1/check | 60 RPM | Deterministic lint engine; fast but mutable |
GET /api/v1/courts, /judges, /rules | 300 RPM | Lightweight reads |
Response headers
Every response (including successful ones) includes rate limit headers:| Header | Description | Example |
|---|---|---|
X-RateLimit-Limit | Maximum requests allowed in the window | 5 |
X-RateLimit-Remaining | Requests remaining in the current window | 3 |
X-RateLimit-Reset | Unix epoch (seconds) when the window resets | 1709913600 |
429 response
When the limit is exceeded, the API returns429 Too Many Requests:
Retry-After header with the number of seconds to wait.
Retry guidance
- Read
Retry-Afterand wait at least that many seconds before retrying. - Use exponential backoff if you receive multiple 429s in a row: wait 1s, 2s, 4s, etc.
- Check
X-RateLimit-Remainingbefore sending requests to avoid hitting the limit in the first place.
Common mistakes
Tight-loop classify calls./classify is limited to 5 RPM because each request calls OCR and an LLM. If you need to process a batch of PDFs, space requests at least 12 seconds apart or queue them server-side.
Ignoring Retry-After. Retrying immediately after a 429 wastes your remaining budget and delays recovery. Always respect the header value.
Polling /check on every keystroke. While /check has a generous 60 RPM limit, calling it on every form change in a UI can still exhaust it. Debounce to at most once per second.