Explainer · Developers · Court Data API
Court Data API for Developers in India
A court data API lets your application fetch case information, status, orders, hearing dates, cause lists and party details, as structured data instead of a human reading a court website. For a developer building case search, litigation tracking, diligence or a legal product, an API is the difference between a feature you can ship and a manual process you cannot scale. The catch in India is that court data is spread across the Supreme Court, the High Courts, the district eCourts system, the NCLT, the DRTs and many tribunals, with no single official all-India API that covers everything cleanly, so the real work is choosing a source that gives you the coverage, freshness and reliability your product needs. This guide explains what a court data API returns, what to evaluate before you build on it, where the legal lines sit, and how to think about the options. Last verified October 2026.
- What it returns: case status, party-name search, orders and judgments, and cause lists, as structured JSON.
- Evaluate on: coverage, freshness, name-matching, auth, rate limits, output schema and terms of use.
- Legal lines: respect source terms, handle personal data responsibly, and timestamp everything as information, not a certified position.
- Reality in India: no single official all-India API, so broad party-name coverage usually comes from an aggregating provider.
01What a court data API returns
A court data API exposes, over HTTP, the kinds of records you would otherwise read off a court portal, but as structured JSON your code can parse. In practice that usually means some combination of:
- Case status: the stage, next hearing date, court and bench for a case identified by number or by party.
- Party search: cases tied to a given party name, which is what powers a litigation check or a monitoring feed.
- Orders and judgments: the text or metadata of orders and final judgments.
- Cause lists: the daily list of matters scheduled before a court or bench.
Good APIs return a stable schema with consistent field names, pagination for large result sets, and a clear match or confidence indicator on party-name results, so your application can tell a strong match from a weak one.
02What developers should evaluate
Before you build on any court data API, evaluate it on the things that will decide whether your product is reliable.
| Factor | What to ask | Why it matters |
|---|---|---|
| Coverage | Which courts, tribunals and years are included | A gap in coverage is a case your product silently misses |
| Freshness | How often the data is refreshed from source | Stale status or a missed new filing breaks a monitoring use case |
| Name-matching | Does party search handle spelling variants and aliases | Exact-match-only search misses real cases under variant names |
| Auth and security | API keys, OAuth, encryption in transit, data handling | You are handling sensitive legal data about real parties |
| Rate limits and quotas | Requests per second, daily caps, burst handling | Decides whether you can run a bulk check or a large book |
| Output schema | Stable JSON, pagination, match confidence, error codes | A clean, documented schema is what you actually build against |
| Terms of use | What you are allowed to store, cache and display | Governs whether your product is compliant |
For the integration detail, see how to integrate a case status API and how a litigation check API works.
03The legal position on court data
Court records are largely public, but that does not mean anything goes. Three points matter for a developer.
- Source terms. Official portals publish case data for public access, and automated access must respect the portal’s terms and any technical controls. Scraping that ignores those terms is a legal and operational risk, which is one reason a licensed API is cleaner than a scraper.
- Personal data. Case data includes personal information about real parties, so storing and displaying it responsibly, and in line with applicable data-protection law, is your obligation as the builder.
- Accuracy and reliance. Data can lag the court record, so your product should present it as information with a timestamp, not as a certified legal position, and should carry an honest caveat.
A court data API is a data-supply decision and a compliance decision at the same time. The cleanest build uses a licensed API, respects source terms, and timestamps everything.
04Common build patterns
Most products built on court data fall into a few patterns:
- Case status lookup. A user enters a case number and your app shows current status and next hearing. Simple, read-on-demand.
- Party-name litigation check. Given a name, return all matters tied to it across forums. This needs good coverage and name-matching, and a confidence flag on each hit.
- Monitoring. Re-scan a list of names on a schedule and emit a change feed of new, updated and closed matters. This is where freshness and rate limits matter most.
- Cause-list automation. Pull daily cause lists and match them to a user’s cases to generate hearing alerts.
Each pattern leans on a different API strength, so pick the source whose coverage and freshness match the pattern you are building.
05The data landscape in India
There is no single official API that returns everything. The district eCourts system and the National Judicial Data Grid publish case data and statistics, some government data is exposed through platforms like API Setu, and individual High Courts and tribunals run their own portals with varying access. The practical result is that broad, all-India party-name coverage usually comes from a provider that has done the work of aggregating and normalising across these sources into one API, rather than from any single government endpoint.
For a comparison of providers, see the best court data APIs in India and the best litigation check APIs.
06Where Claw fits
Claw is an all-in-one legaltech platform for Indian advocates, law firms, and corporate legal teams, combining AI-based case search, an AI legal assistant (Legal GPT), case management, and compliance automation across all Indian courts and tribunals.
For developers, Claw exposes its court-data capability so you can build case search, litigation checks and monitoring into your own product instead of scraping portals yourself. Behind the API sits the same engine as the platform: coverage across 9,102 courts, benches and forums, judgment search across 30 crore+ judgments with Supreme Court decisions from 1950 and High Court decisions from 1990, name-tolerant party search with a match confidence on each result, and results in under 5 seconds. You can look up case status, run a party-name litigation check, and monitor a list of names for new filings, changed movement and closed disposals, and Claw does not use your searched names or documents to train its AI models. Treat every response as timestamped information rather than a certified legal position, and present the honest caveat that "nothing on record" means nothing was found in the registries searched on the date searched under the names searched. You can create a FREE Claw account to explore the data before you integrate.
For the integration path, see the Claw court-data API and a litigation search API for your systems.
07Sources and further reading
- eCourts (district and High Court case status): ecourts.gov.in
- National Judicial Data Grid (official case data and statistics): njdg.ecourts.gov.in
- API Setu (government API platform): apisetu.gov.in
- Claw: clawlaw.in
This page is general information for an Indian technical audience, not legal advice. Confirm source terms, data-protection obligations and API capabilities before you build on them.
08Frequently asked questions
Is there an official all-India court data API?
Not a single one that returns everything. The district eCourts system and the National Judicial Data Grid publish case data and statistics, and some government data is exposed through platforms like API Setu, but individual High Courts and tribunals run separate portals. Broad party-name coverage across all of them usually comes from a provider that aggregates and normalises these sources into one API.
Can I just scrape court websites instead of using an API?
You can technically fetch public pages, but automated access must respect each portal’s terms and technical controls, and a scraper is brittle, breaks when a site changes, and raises compliance questions. A licensed API that aggregates the data is cleaner, more reliable, and easier to build a product on.
What should I evaluate before building on a court data API?
Coverage of courts and years, how fresh the data is, whether party search handles name variants, authentication and security, rate limits and quotas, the stability of the output schema, and the terms that govern what you can store and display. Each decides whether your product is reliable and compliant.
How do I handle personal data in court records?
Court data includes personal information about real parties, so you must store and display it responsibly and in line with applicable data-protection law. Present it as timestamped information, limit what you retain to what you need, and avoid presenting a result as a certified legal position about any person.
What does name-matching have to do with an API?
A party-name search that only does exact matching will miss cases filed under a variant spelling or an old name, which is common in India. An API with name-tolerant matching and a match-confidence flag on each result gives your product far more reliable litigation-check and monitoring features.