What the code enforces today, what is defined but waiting on the self serve flag, body size and timeout budgets, and CORS.
Enforced today
10 requests per minute, per API key
A rolling sixty second window, counted per key rather than per account. This is the only request rate ceiling in force on keyed endpoints while the self serve tiers are switched off, and it applies identically to every plan and every endpoint that takes an API key. Two caveats worth knowing: the counter lives in the API server's process memory, so it resets when the service restarts, and rejected requests still count against the window, so retrying inside it makes things worse.
One exception: GET /health takes no API key, so it is not part of the ten per minute ceiling above at all. It carries its own always on guard of 120 requests per minute per client IP, unaffected by the self serve flag either way.
// HTTP 429, eleventh request inside the same minute on one key
{
"error": "Rate limit exceeded",
"message": "Too many requests. Maximum 10 requests per minute allowed.",
"retryAfter": 37,
"resetTime": "2026-08-10T09:41:12.884Z"
}
// Successful responses carry the budget in headers
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 6
X-RateLimit-Reset: 2026-08-10T09:41:12.884ZEnterprise keys additionally pass through a monthly API hit ceiling carried by the enterprise contract. Reaching it returns HTTP 429 with a bare error field and no retry hint, because the window is a billing month rather than a minute. Your contract states the number; there is no published default.
The tier configuration also carries per day and per month request windows, a maximum page size, a pagination depth cap, a distinct case fetch cap, a monthly PDF cap, a concurrent analysis job cap and a limit on live keys. None of them are checked while the self serve flag is off, and the ones that only exist on paper are marked as such in the configuration itself. We list them because they will start applying on the day the ladder turns on, not because they apply now.
There are no per day API call limits and no per day AI analysis limits of any kind in the current code. Any figure of that shape you have seen for this API was invented.
Every request body is capped at 256 kb; a larger body is refused with HTTP 413 PAYLOAD_TOO_LARGE before it is parsed. Set a client side timeout well above these figures, and treat your own timeout as your client giving up on reading the response, not as cancelling the call: a request that is already running on our side keeps running and, if it succeeds, still charges credits. Your timeout does not cancel work in progress and does not refund anything.
| Endpoint | Budget |
|---|---|
| POST /search/cases/semantic | Up to 10 minutes for a cold, heavily filtered query. Most calls finish in seconds; the connection is held open rather than cut early. |
| POST /request-timeline (refresh: true) | Up to 210 seconds for the live court portal fetch. A stored read (refresh omitted or false) answers immediately. |
| POST /cases/:id/analyze-consolidated | Synchronous: the call runs the model before it answers, rather than handing back a job id to poll. Budget for a genuinely long single request. |
| Everything else | Seconds, bounded by the underlying Mongo or OpenSearch query. |
Every keyed endpoint is meant to be called server side. There is no key you can safely put in front end JavaScript: a key visible to a browser is a key visible to everyone who opens dev tools, and it will be used against your balance and your rate limit. The public, no key endpoints that exist specifically for a browser to call directly, GET /coverage, GET /reference/courts and GET /reference/case-types do carry CORS headers for that reason. Every keyed endpoint does not. Proxy through your own backend if you need to reach this API from client side code at all.