Skip to main content
Every API key has per-minute request limits. Limits vary by endpoint based on computational cost.

Limits by endpoint

RPM = requests per minute, per API key. Limits use a sliding window (no burst-at-boundary problem).

Response headers

Every response (including successful ones) includes rate limit headers:

429 response

When the limit is exceeded, the API returns 429 Too Many Requests:
The response also includes a Retry-After header with the number of seconds to wait.

Retry guidance

  1. Read Retry-After and wait at least that many seconds before retrying.
  2. Use exponential backoff if you receive multiple 429s in a row: wait 1s, 2s, 4s, etc.
  3. Check X-RateLimit-Remaining before 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 takes 10-30 seconds to analyze a PDF. If you need to process a batch, 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.

Need higher limits?

Contact api@courtrules.app with your use case. We can increase limits for production integrations.