REST API for Indian court case data, litigation checks and AI legal analysis. 21 live endpoints, documented against the code that serves them.
API access is enabled on Enterprise accounts only. That means a global Enterprise plan, or the Research app upgraded to Enterprise on your account. Every other plan is refused on the first call with HTTP 403 and the message "API access is only available on the Enterprise plan." There is no Premium, Organization or Standard plan: if you have read that anywhere, it was wrong.
A self serve ladder with a free tier, prepaid credits and per endpoint prices is built and published, but it sits behind a feature flag that is switched off in production, so it is not something you can sign up for yet. The prices and allowances it will carry are on the API pricing page. Nothing on this page deducts credits today.
Keys are created on the API Keys screen inside the CourtMesh Research app, at research.courtmesh.ai/api-keys. The full key is shown once, at creation, and only its hash is stored, so copy it then. If your plan does not include API access the screen will still let you create a key; the refusal happens on the first call.
Key format: a prefix, then 32 characters, then 4 more, joined by hyphens. New keys use the cm- prefix. Older keys issued with vv- still authenticate and do not need replacing.
Every endpoint below is relative to:
https://research.courtmesh.ai/api/v1/prodSend the key in X-API-Key or in Authorization: Bearer. Both work.
curl -X POST https://research.courtmesh.ai/api/v1/prod/search/cases \
-H "X-API-Key: cm-YOUR_KEY_HERE" \
-H "Content-Type: application/json" \
-d '{
"query": "dishonour of cheque section 138",
"court": "Bombay High Court",
"limit": 20,
"page": 1
}'Enterprise accounts. With the API_SELF_SERVE_TIERS feature flag off, which is how production runs today, the entitlement gate is Enterprise only: a global Enterprise plan, or the Research app upgraded to Enterprise on your account. Every other plan gets HTTP 403 with the message 'API access is only available on the Enterprise plan. Upgrade to an Enterprise plan for API access.' on the first call. A self serve ladder with free credits is built and priced but not switched on, and the prices it will charge are published on the API pricing page.
Either X-API-Key or Authorization: Bearer. The same middleware reads both, checks X-API-Key first, and falls back to the bearer token. Keys are issued in the form prefix-32characters-4characters, where the prefix is cm for keys issued now and vv for older keys that still authenticate. Anything that does not match that shape is rejected with HTTP 401 'Invalid API key format' before the key is looked up.
Ten requests per minute per API key, on a rolling sixty second window. That is the only request rate ceiling the code enforces today. It is applied per key rather than per account, so splitting traffic across keys splits the budget too. Every successful response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Exceeding it returns HTTP 429 with retryAfter in seconds and an ISO 8601 resetTime. The counter lives in the process memory of the API server, so it resets when the service restarts.
Not today. Per day and per month request windows, maximum page size, pagination depth, distinct case fetches per day, PDF calls per month, concurrent analysis jobs and the number of live keys are all defined in the tier configuration but none of them are enforced while the self serve flag is off. The one account level check that does run on Enterprise keys is a monthly API hit ceiling carried by the enterprise contract, which answers with HTTP 429 when it is reached.
practiceArea is not part of either search schema. The validator parses the body against a plain object schema, so any key it does not know about is stripped silently before the handler sees it: no error, no filter. caseNumber is different. It is accepted by the keyword search schema and echoed back in meta.filters, but the handler never forwards it to the search engine, so it also has no effect on results. To find a case by its number, put the number in the query field instead.
Put it inside the nested filters object, not at the top level. The semantic handler reads only query, limit, page and filters. The schema still accepts court, year, caseType, caseNumber, judgeName, judges, judge, fromDate and toDate at the top level, so sending them does not raise an error, but nothing reads them. Send filters with a court key instead, and the endpoint merges it over whatever it inferred from your natural language query.
POST /search/cases runs against the keyword index, which holds 315.6 million case records across the Supreme Court, all 25 High Courts, District Courts and Tribunals. POST /search/cases/semantic runs against the vector index, which holds roughly 2 million cases that have been analysed and embedded, and is not available on the Free tier. The semantic corpus is a curated subset, not the whole archive, so a semantic query can miss a document that keyword search finds.
No, and today none of them deduct API credits at all. The per endpoint credit prices only settle when the self serve flag is on, and it is off in production. When it is switched on, GET /health, GET /get-timeline and GET /coverage are priced at zero, GET /me and GET /audit are absent from the price list entirely and so are unmetered, and the remaining endpoints carry published prices that range from one credit for a keyword search to four hundred for a consolidated AI analysis.
API access is on Enterprise accounts today. If you already have one, your keys are on the API Keys screen. If you do not, talk to us and we will tell you plainly whether we can serve your use case.