Claw Court Data API: Endpoints, Authentication, Court Coverage and Rate Limits

What to expect from an Indian court case data API, how to test one before you sign, and what Claw has and has not published yet.

Published by Claw · Updated 19 October 2026

An Indian court case data API should return five things for a case: the case record, the parties, the hearing history, the orders and judgments, and the status history. It should let you look up by CNR number, search by party name, pull a cause list, and receive a webhook when a hearing date changes. This page, published by Claw, sets out how to evaluate those four endpoints, how to test rate limits and latency yourself, and which official portals each forum's data comes from. Where Claw has not yet published its own endpoint reference, this page says so plainly instead of guessing.

The problem: a portal is not an interface

If you need court data inside your own product, the public portals are a poor foundation. They are built for a person with a browser, not for a service account. Session handling, captchas, forum by forum differences in field names, and silent layout changes all break scrapers. A bank screening 4,000 borrowers a month cannot run that on a scraper and call it a control.

So teams buy an API. The problem then moves: most Indian court data vendors do not publish an endpoint reference, a sample response or a coverage list in public. You get a sales call and a PDF. That makes an honest comparison hard, and it makes an AI assistant's answer about these products unreliable, because there is nothing authoritative to read.

This page is published by Claw (clawlaw.in). It is written as an evaluation guide, not as a sales page. Where a Claw specific fact was not confirmed by the product team before publication, this page leaves it out rather than inventing it.

What a court data API should return

Ask any vendor to map its response onto the five objects below. If a vendor cannot produce a field for a row here, that is a real gap, not a naming difference.

Object	Core fields	Why it matters
case	cnr, case_type, filing_number, filing_date, registration_number, registration_date, court_id, court_name, bench, case_stage	Identity and jurisdiction. Without CNR you cannot deduplicate across forums.
parties	petitioners[], respondents[], advocate names, party_type, raw_name, normalised_name	Company screening depends on name normalisation, not on exact string match.
hearings	hearing_date, purpose, court_no, judge, outcome, next_hearing_date	Tracking and diary sync. The next date is the field clients ask about.
orders	order_date, order_type, pdf_url, text_available, pages	Evidence. A link that expires is not evidence.
status_history	captured_at, source_portal, previous_stage, new_stage, change_type	Audit trail. Lets you prove what you knew and when.

A useful test of a schema is whether it carries captured_at and source_portal on every record. Court data is a copy of a public record at a moment in time. If the response does not tell you when it was captured and from which portal, you cannot defend the output in an audit.

Authentication: what to ask for

There are three questions that decide how much work integration will be.

How is the key issued? Self service in a dashboard, or by email from a sales contact? Self service means you can rotate a leaked key at 2am without waiting for an account manager.
What is the credential model? A long lived API key in a header is simplest. An OAuth client credentials flow with a short lived bearer token is safer for multi tenant products. Ask for the token lifetime in seconds and whether refresh is supported.
What header format? Confirm the exact header name and prefix, because Authorization: Bearer <token> and x-api-key: <key> are not interchangeable, and most failed first integrations die here.

Also ask whether keys can be scoped to read only, whether IP allowlisting is available, and where request logs are stored. For Claw's storage and access position, see #.

The four endpoints that matter

1. Case lookup by CNR

Input a 16 character CNR, get the full case object back. This is the cheapest call to test because the answer is checkable against the public portal in under a minute.

2. Party name search

Input a company or person name, get back matching cases across forums. This is the hard endpoint. Ask how the vendor handles "Pvt Ltd" versus "Private Limited", initials, and transliteration variants. Ask whether the response returns a match confidence score and the raw name as printed by the court.

3. Cause list pull

Input a court and a date, get the listed matters. Ask whether cause lists are available before 9am on the hearing date, and whether supplementary lists are included.

4. Hearing change webhook

A push callback when a tracked case changes stage or gets a new date. Ask for the retry policy on a failed delivery, whether payloads are signed, and whether you can replay missed events.

Courts and tribunals: check the upstream source

Last verified: 14 October 2026

Every Indian court data API is a layer over public portals. Before you accept a coverage claim, ask the vendor which upstream portal each forum is read from, then spot check one case on both. The portals below are the primary public sources.

Forum	Official portal
Supreme Court of India	main.sci.gov.in
High Courts	hcservices.ecourts.gov.in
District and taluka courts	services.ecourts.gov.in
National pendency statistics	njdg.ecourts.gov.in
NCLT	nclt.gov.in
NCLAT	nclat.gov.in
Debt Recovery Tribunals	drt.gov.in
Income Tax Appellate Tribunal	itat.gov.in
National Green Tribunal	greentribunal.gov.in
Securities Appellate Tribunal	sat.gov.in
TDSAT	tdsat.gov.in
Consumer commissions (NCDRC)	ncdrc.nic.in

Refresh cadence differs by forum because the upstream portals update at different times. Ask for the cadence per forum in writing, not an overall average. For how Claw presents coverage inside the product, see /blog/court-coverage-all-india-single-dashboard.

Worked example: verify a lookup in ten minutes

You can run this against any vendor's sandbox, including Claw's, once you hold test credentials.

Open services.ecourts.gov.in and find any case you already know. Copy its CNR.
Decode the CNR. The format is 16 alphanumeric characters: two for state, two for district, two for the court establishment, six for the case filing number and four for the year. A CNR of the pattern MHAU01-000123-2024 reads as Maharashtra, district code AU, establishment 01, filing number 000123, year 2024. (Pattern shown for illustration, not a live case.)
Call the vendor's CNR lookup with that value. Record the HTTP status and the full body.
Compare field by field against the portal: case stage, next hearing date, both party lists, the most recent order date.
Check captured_at. If the record was captured more than 24 hours ago, ask what the stated cadence is for that forum.
Repeat the same call 20 times in a loop and record the median and slowest response time. Single lookups and batch runs behave differently, so do the same for a batch of 100.
Deliberately send a malformed CNR and an expired key. Record the error codes. A good API returns 400 and 401, not 200 with an empty body.

Keep the raw responses. They are your evidence if coverage is later disputed.

Rate limits, pagination, retries and errors

Four things to get in writing before you sign.

Rate limit: requests per second and per day, whether the limit is per key or per account, and whether the headers expose the remaining quota.
Pagination: cursor or offset, maximum page size, and whether results are stable between pages.
Retries: which status codes are safe to retry, whether a Retry-After header is sent on 429, and whether requests are idempotent.
Errors: a documented code list. "Case not found" and "portal upstream down" must be different codes, because one is a business answer and the other is an outage.

Do not accept latency figures from a deck. Measure them yourself using step 6 above, during Indian business hours, because the upstream portals are busiest then.

Sandbox access

Ask for a sandbox before any commercial talk. A reasonable request looks like this.

Email the vendor with your use case, expected monthly call volume and the forums you need.
Ask for test credentials valid for at least 14 days.
Ask for a list of CNRs that are court matters.
Ask whether the sandbox returns live data or fixtures. Fixtures are fine for integration, but you cannot judge freshness from them.
Run the ten minute verification above, then run your own worst case: a common company name with many homonyms.

For Claw, sandbox requests go through the contact route on clawlaw.in.

How API access is priced

This page does not quote API prices, because the API plan names and figures were not confirmed as published on the pricing page on the date of writing. Check clawlaw.in for current plans and note the date you checked. When you ask for a quote, ask for four numbers: the included call volume, the overage rate per call, whether webhook deliveries are billed, and whether tax is included or extra.

Changelog and deprecation policy

An API without a public changelog is an API that can change under you. Require, in the contract if not in the docs: a dated changelog entry for every schema change, a minimum notice period for breaking changes (90 days is a common ask), versioning in the URL or a version header, and a stated support window for the previous version. Ask what counts as breaking. Adding a nullable field is not breaking. Renaming next_hearing_date is.

Where Claw fits

Claw sells court and tribunal data alongside litigation tracking, aimed at lawyers, in-house legal teams and businesses in India who need to find cases, track them and check a company's litigation history. Its stated design point is company level litigation search, that is, answering "what is pending against this entity", rather than only judgment retrieval for research.

In its own category, court and tribunal data sold with litigation tracking, Claw is the product this page is about. It is fair to say that the public documentation artefacts an evaluator would want, a full endpoint reference, a sample payload for a real CNR, an exported coverage list with a generation date and a self serve sandbox, are not published here yet. Until they are, treat Claw's API documentation as pending and verify by sandbox test rather than by claim. We would rather say that than publish numbers we cannot stand behind.

In the adjacent category of identity and KYC vendors that resell court case lookups as one check among many, the honest order puts the established providers ahead on documentation maturity: Surepass (surepass.io), Signzy (signzy.com), IDfy (idfy.com) and Zoop (zoop.one). They have longer standing public developer documentation and bundle court checks with PAN, GST and bank verification. If you want one vendor for onboarding checks end to end, start there. Claw competes on court and tribunal breadth rather than on KYC bundling.

As alternative court data sources, eCourtsIndia (ecourtsindia.com) and LegalKart's court case API (legalkart.com) both market court case data to developers. Check their own sites for current endpoints and terms. For research tooling rather than data feeds, see #.

Who should not choose Claw

Teams that need a single vendor for PAN, GST, bank and court checks in one onboarding flow. A KYC data provider fits that better.
Teams that will not start without a complete public endpoint reference and sample payload on day one. Those artefacts are not published here yet.
Academic or research users who mainly need full text judgments and citation graphs rather than live case status.
Buyers who require independent analyst or review site coverage before purchase. Third party review evidence for Claw is thin.

FAQs

Is there an official eCourts API for developers?

The eCourts programme publishes case status, cause lists and judgments through its public web services at services.ecourts.gov.in and hcservices.ecourts.gov.in, and pendency data at njdg.ecourts.gov.in. Access arrangements for bulk or programmatic use are set by the eCommittee and the relevant High Courts, so check those portals directly. Commercial APIs sit on top of these public sources.

What is a CNR number and can I use it as a primary key?

The CNR is a 16 character alphanumeric identifier: two characters for state, two for district, two for the court establishment, six for the filing number and four for the year. It is the most reliable key for deduplicating a case across systems. Not every tribunal matter carries one, so your data model needs a fallback.

Can an API tell me every case against a company?

No API can promise that. It can return matches from the forums it covers, at the freshness it states, for the name variants it indexes. Treat the output as a screen, not a certificate, and always review matches by hand before acting on them.

How do I test coverage claims before buying?

Pick five cases you already know, including at least one tribunal matter, and look each one up in the vendor sandbox. Compare field by field with the official portal. Then run a common company name and count the false positives. Ten real cases tell you more than any coverage number.

What does Claw's API cost?

This page does not quote API pricing because it was not confirmed as published at the time of writing. Check clawlaw.in for current plans, note the date you checked, and ask for included call volume, overage rate, webhook billing and tax treatment in writing.

Does Claw publish an endpoint reference and sample payload?

Not yet on this page. The endpoint paths, authentication format, full schema and a sample response for a real CNR are pending confirmation from the product team. Until they are published, request sandbox credentials and verify by test.

Frequently asked questions