eCourtsIndia API: A Developer’s Guide to India’s Court Data

The eCourtsIndia API is a production-grade REST API for Indian court data, giving developers programmatic access to case search, case details, orders, judgements, and cause lists across 29,000+ courts, with case search that filters by party, advocate, or judge.

Why Build on a Single API Instead of Scraping Individual Court Sites?

The official Indian court estate is fragmented across three tiers: the Supreme Court, 25 High Courts (each with between one and five benches), and district-court complexes across 800+ districts, plus 18 specialised tribunal types (NCLT, NCLAT, ITAT, CESTAT, DRT/DRAT, NGT, AFT, SAT, TDSAT, APTEL, CAT/CGAT, CCI, GSTAT, RCT, and the consumer commissions among them). Every portal has its own HTML layout, CAPTCHA, session handling, and publication schedule. The eCourtsIndia API sits on top of a unified index that normalises all of it:

• One schema: Supreme Court, High Court, district-court, and tribunal results return the same JSON shape, so your parser never branches by court.
• Canonical identifiers: every matter is keyed by its 16-character CNR (Case Number Record), so joins across cases, orders, and cause lists are trivial.
• Daily sync: the index is refreshed continuously from the official court backends, so API responses reflect today’s listings and today’s orders.
• No scraping maintenance: you don’t have to chase court-portal HTML changes, CAPTCHAs, or rate-limited public endpoints.

What Endpoints Does the API Expose?

The API is organised around resources that map to everything you can do on the eCourtsIndia website:

• Case search (/api/partner/search): Solr-powered keyword and full-text search across case titles, order and judgment text, and AI summaries, with structured facets: court, state/district, case type, case status, filing year, decision year, bench type, and hasOrders/hasJudgments. You can also narrow by party, petitioner, respondent, advocate, or judge name. Results come back in data.results[].
• Case details (/api/partner/case/{cnr}): fetch the full case record by CNR: parties, advocates, judge, bench, status, stage, and hearing history. For High Court and District Court matters, records now also capture richer fields such as e-filing number and date, filing type, litigant type, case-type conversion, structured parties, and process / IA-filing / transfer histories. (These are case-detail fields shown on the record; they are not separate search filters.)
• Orders & judgements: list every order passed in a case, stream the underlying PDF, and pull the order text, an AI analysis of the order, or the order as Markdown.
• Cause lists: retrieve the daily cause list (the official schedule of cases set for hearing) for any state, district, or specific court complex, plus the list of available cause-list dates. You can also check whether specific cases are listed with /api/partner/causelist/cnr/batch: pass 1 to 100 CNRs in one call (a one-element array to check just a single case) and it tells you whether each CNR is set down for an upcoming hearing and what it’s listed for, the quick way to answer “is anything on my docket listed tomorrow?”
• Court structure: look up the hierarchy of states, districts, court complexes, and individual courts so you can build accurate pickers and resolve court codes.
• Enums (/api/partner/enums): fetch the live enum lookups (137 case types, 71 case statuses, 13 court types, 29 High Court base codes, 15 NCLT codes) so your app’s dropdowns stay in sync with the backend. Those counts are a point-in-time snapshot. The authoritative live set (including newer entries such as the GSTAT court-codes and case types now being seeded) is always whatever the enums endpoint returns, documented in the API docs.

Every endpoint lives under the REST base https://webapi.ecourtsindia.com and returns a consistent { data, meta } envelope. There’s also a hosted MCP server (Model Context Protocol) at mcp.ecourtsindia.com exposing 26 tools so an AI agent can query Indian court data directly: case search, case details, order AI analysis and Markdown, listing every order in a case, cause-list search, court-hierarchy and enum lookups, batch case fetches, on-demand case refresh, a cause-list check that tells you whether specific cases (up to 100 CNRs at once) are listed for an upcoming hearing, and programmatic portfolio monitoring. You connect by passing your key in the connector URL (https://mcp.ecourtsindia.com/mcp?token=YOUR_API_KEY), and the server authenticates to the backend with your Bearer token on every call (it is not an open or authless server). The court-hierarchy and enum lookups are free; the data tools are credit-metered against the same account (top up at ecourtsindia.com). Via MCP, order text comes as Markdown or an AI analysis; the raw signed PDF is a download from the REST API, not an MCP tool. See the MCP page for the live tool list.

How Do You Authenticate API Requests?

Authentication is token-based, and access is partner-gated. There’s no anonymous tier, so every request must carry a Bearer token. Each request sends an Authorization: Bearer eci_live_<your-key> header. The flow:

1. Request partner API access from ecourtsindia.com/api and, once approved, open the developer dashboard.
2. Generate a Bearer token (it starts with eci_live_). Keys can be rotated at any time.
3. Store the key as an environment variable (ECI_API_KEY) on your server; never ship it to the client.
4. Call the endpoint with the bearer header. Responses are JSON wrapped in a { data, meta } envelope; errors follow the standard 4xx / 5xx HTTP status conventions.

For CI and test environments, issue a separate key so a runaway test suite never burns through your production rate limits.

What Does a Case-Search Query Look Like?

A typical case-search request takes a query string and optional structured filters (court, case type, status, filing/decision year, bench type, party/advocate/judge name), and returns a page of matches. The search works just like it does on the website. Type natural keywords, a name, or a CNR; there’s no special operator syntax to learn:

• Keywords: {"q": "IPC 302"} returns matters referencing Section 302 IPC (murder) anywhere in the indexed case titles, order text, and AI summaries.
• By name: pass an advocate, judge, petitioner, or respondent value to pull that person’s matters, for example, every case where a given advocate appears on record.
• Structured filters: {"caseType": "BA", "courtCode": "DLHC01", "caseStatus": "PENDING"} narrows to pending bail matters in Delhi HC.
• Year ranges: combine filingYear or decisionYear bounds to scope a query to a window of time.

Results arrive in data.results[] and include the CNR, parties, advocates, judge, court code, status, case-type code, and next-hearing date. Paginate with the page and page-size parameters (up to 100 results per page) and sort by relevance (the default) or by a structured field such as filing or decision date, filing year, or an order/hearing count; an unsupported sort field simply falls back to relevance. For deep pagination, reach for cursor-based paging rather than very large offsets. For more on how the search behaves and what each filter does, see our eCourtsIndia Search Guide.

How Do Orders, Judgements, and Cause Lists Work?

Three resources handle the documents and listings your practice cares about day-to-day:

• Order list & PDF: fetch every order passed in a case (with date and order type), then stream the underlying order/judgment PDF as a binary file, the court’s own true copy, ready to archive or display.
• Order Markdown: pull the full text of an order as Markdown for RAG or search ingestion, instead of parsing the PDF yourself.
• Order AI analysis: an AI-generated structured read of a specific order: outcome, relief granted, parties, acts invoked, key directions. Saves you a manual read when scanning a large docket. (AI features are credit-metered.)
• Cause-list search: retrieve the daily cause list for a state, district, or specific court complex, and query the available cause-list dates so you only request lists that exist.

Orders and cause lists are the two resources most legal-tech integrations hit every morning. Cache them for the day; re-fetch on your own schedule, or call the refresh endpoint to pull the latest state for a specific case before you re-read it.

How Do You Find a Judge’s, Advocate’s, or Litigant’s Cases?

You don’t need separate people endpoints. The case-search resource already lets you query by the people involved, which few other Indian legal APIs offer in this depth:

• By judge: pass a judge name to case search and get back the matters where that judge appears on record. Useful for bench-research tools and legal journalism.
• By advocate: pass an advocate name to retrieve that advocate’s court-wise and case-type-wise footprint. (On the website, advocates can also claim and maintain a public lawyer profile.)
• By litigant / party: pass a petitioner or respondent value (an individual or a company name) to assemble its litigation footprint across court tiers and tribunals, the pre-deal diligence query.

Public judge and litigant pages on the website present the same court-record case lists if you’d rather link a user straight to them.

How Do You Keep Case Data Fresh?

The API doesn’t push webhooks. You pull. The index is refreshed continuously from the official court backends, so for most use cases a scheduled re-fetch is all you need:

• Poll on a schedule: re-fetch a case, its orders, or a cause list as often as your plan’s rate limits allow. Most teams sweep their active matters once a day, usually first thing in the morning.
• Force a refresh: call the refresh endpoint to pull the very latest state for a single case before you read it, or bulk-refresh to queue up to 50 CNRs in one call.
• Read-after-refresh: newly refreshed records become searchable within roughly half a minute, so a refresh-then-fetch pattern reliably gives you current data.

If you want hands-off case monitoring rather than building your own polling loop, the eCourtsIndia website handles that for you: map a case to a client and opt in to Email and WhatsApp alerts on new orders, hearings, and status changes (near-real-time, delivered by a polling worker, credit-metered). That’s the supported way to be notified when a case moves. No webhook plumbing required.

What Integrations Do Teams Typically Build?

The API is designed to slot into the tools your firm already uses. Four patterns come up repeatedly:

• Practice-management sync: push next-hearing dates into Google Calendar, Outlook, or Microsoft 365, and auto-archive new-order PDFs to Google Drive, SharePoint, or a DMS like NetDocuments.
• CRM and credit enrichment: enrich a customer record with a litigation footprint so credit teams see exposure before approving a loan or expanding a limit.
• Due-diligence dashboards: search a PE or M&A target’s legal-name aliases (party/petitioner/respondent fields) and render a deal dashboard covering all pending and disposed matters.
• AI assistants / RAG: pull order Markdown from the order-Markdown endpoint into an LLM context window so your research copilot can answer “what did Delhi HC say about IPC 498A in the last 6 months?” grounded in real order text. For agent-native setups, point your model straight at the hosted MCP server instead of writing API glue.

What Are the Rate Limits and Pricing Tiers?

API access is partner-gated: you request access, receive a Bearer token, and your account is provisioned with rate limits. The default per-partner limits are:

• 100 requests per minute: burst headroom for interactive lookups.
• 3,000 requests per hour and 50,000 requests per day: enough for steady automation and daily docket sweeps.
• 10 concurrent requests: parallelism for batch jobs.

These limits are configurable per partner, so high-volume SaaS products, due-diligence platforms, and AI research assistants can be provisioned higher ceilings. Exact request-pricing and plan details are on the API pricing page. Every account uses the same endpoints and the same { data, meta } response shape, so you can grow without changing a line of code.

How Reliable Is the Underlying Data?

The API serves exactly the same data as the eCourtsIndia website, sourced from the Government of India’s eCourts services, the Supreme Court registry, individual High Court portals, and tribunal backends. The same case records also feed the National Judicial Data Grid (NJDG), the government’s public dashboard of pending and disposed cases. That means:

• What a human user sees in the browser, your app sees via the API.
• If an order appears on the court portal, it flows into the API within the same indexing cycle.
• The canonical identifier, the CNR, is identical across the website, the API, and the underlying court record.
• For evidentiary use in court, cite the downloaded PDF (it is the court’s own signed order). The JSON is for your app; the PDF is for the bench.

---

---

Related reading on eCourtsIndia Blogs: The Complete eCourtsIndia Search Guide • Track Pending Court Cases • What Is a CNR Number. Published by eCourtsIndia Data Team. General information, not legal advice.

Frequently Asked Questions