Explainer · Developers · Court Data

The eCourts API, Explained (2026)

Updated for 2026 · Claw Editorial

If you are a developer told to "use the eCourts API", the first surprise is that there is no single, open, documented API you can sign up for the way you would for a payments gateway. eCourts is a government computerisation programme, not a product with a public developer portal. It puts case status, cause lists, orders and judgments on public websites and mobile apps, and it has started to expose data through restricted channels, but most of that access is gated. This explainer sets out what engineers actually mean when they say "eCourts API", what the public data layer gives you, the real constraints you will hit, and the practical routes for getting Indian court data into an application. Last verified October 2026.

01What "the eCourts API" really means

eCourts is a national programme run by the National Informatics Centre that computerises the district and High Courts and publishes their data. When people say "the eCourts API" they usually mean one of three different things, and it helps to be precise about which:

• The public portals and apps. The eCourts services website and mobile app, plus the National Judicial Data Grid, let anyone look up case status, cause lists, orders and judgments. This is the real public surface, and it is a user interface, not a developer API.
• The NJDG open APIs. NJDG introduced open APIs in 2023 that are aligned with the national data sharing policy and shared with central and state government and institutional litigants under departmental IDs and access keys. This is a genuine API, but it is not open to the general public or to most startups.
• Third-party APIs. Several commercial vendors sell "eCourts APIs" that are their own services built on top of the public data. They are not operated by eCourts or the National Informatics Centre.

For the wider picture of what a court data layer is, see what a court data API is in India and what eCourts is.

02What the public data layer exposes

Whatever route you take, the underlying data is roughly the same, because it all originates from the courts through eCourts. The useful fields for most products are:

• Case status, keyed by the Case Number Record identifier or by case number, with parties, filing and registration details, the stage and the next hearing date.
• Cause lists, the daily schedule of cases listed before each court.
• Orders and judgments, often as PDFs, with the Supreme Court reported judgments available free through the electronic Supreme Court Reports project.
• Case history, the chain of hearings and interim orders over the life of a matter.

The point to hold on to is that the data is a court record, not a clean analytics feed. Names are entered by court staff, formats vary between courts, and the same person or company can appear under many spellings. For how status lookups work in practice, see how to check case status on eCourts.

03The access realities engineers hit

The gap between "the data is public" and "I can pull it reliably at scale" is where most integrations stall. Plan for these constraints:

• No open sign-up API for the public. The NJDG open APIs are shared with government and institutional litigants under access keys, not handed out to any developer. If you are not in that group, the portal and third parties are your routes.
• CAPTCHAs. The public case-lookup pages use CAPTCHA to stop automated scraping. Tools that get around this with optical character recognition may conflict with the portal terms of use, so this is a legal question, not just a technical one.
• Rate and stability. The portals are built for human lookups. There is no published public rate limit or service-level guarantee, and pages and markup change without notice, which breaks scrapers.
• Data freshness. Court data is updated as courts digitise it. There can be a lag between a hearing and the record going live, so a status you read is "as published", not necessarily real time.

The data is public, but reliable programmatic access at scale is not simply there for the taking. That gap is the whole engineering problem.

04Coverage gaps to plan for

A single source rarely covers every forum a product needs. Map your required forums against what each source actually carries:

• The Supreme Court runs its own case information system and reports its judgments through the electronic Supreme Court Reports project, so it is not always covered the same way as the subordinate courts.
• Tribunals and specialised forums, such as the National Company Law Tribunal, Debt Recovery Tribunals and tax tribunals, often sit outside the core eCourts district and High Court data and may have their own portals or none at all.
• Historical depth varies. Older matters may be thin or missing because digitisation started at different times in different states.

For how the national dashboard differs from the services portal, see the NJDG versus eCourts difference, and for what NJDG can and cannot do for tracking, see whether NJDG can track your case.

05Routes to get the data into your system

In practice teams choose between three routes, and often combine them:

• Apply for institutional NJDG access if you are a government body or institutional litigant that qualifies. This is the official route, but the eligibility is narrow.
• Build and maintain your own scraping layer against the public portals. This is feasible for a narrow need but carries the CAPTCHA, terms-of-use, breakage and maintenance costs above, and it rarely scales to every forum.
• Use a third-party court-data API or export that handles coverage, matching and refresh for you, and consume it through a documented interface. This is the common choice when a team needs breadth without owning the plumbing.

For the integration mechanics once you have a source, see how to integrate a case status API in India, and to compare providers, see the best court data APIs in India for 2026.

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 teams that do not qualify for institutional NJDG access and do not want to own a scraping layer, Claw offers court-data APIs, case export and case tracking across 9,102 courts, benches and forums, covering 30 crore+ judgments with Supreme Court decisions from 1950 and High Court decisions from 1990, with search results in under 5 seconds. That lets a product query and monitor cases through one documented interface instead of stitching together portal scrapers forum by forum. Claw does not train its AI models on your case documents, which matters when the data flows through your own systems.

Create a FREE Claw account to try court data access, and use case search across Indian courts to pull cases by party across courts and tribunals.

07Sources and further reading

• eCourts services (official portal): ecourts.gov.in
• National Judicial Data Grid (case statistics and status): njdg.ecourts.gov.in
• eCourts judgments and orders portal: judgments.ecourts.gov.in
• Claw: clawlaw.in

This explainer is general engineering guidance, not legal advice. Court-data access and scraping raise terms-of-use and data-protection questions, so take advice before you build against any source.

08Frequently asked questions