The decision usually gets made in about four minutes. Somebody opens the eCourts services portal, notices that the case status page renders in plain HTML, pulls it with a script, gets a result, and concludes that the data is free and the work is a sprint. That first request almost always succeeds. It is the second year of that decision that nobody costs.
This is not an argument that scraping is illegitimate or that everyone should buy an API. Plenty of teams should scrape, and some have no realistic alternative. It is an argument that the comparison is almost never done honestly, because one side of it has an invoice attached and the other side is paid for out of engineering time nobody tracks. A scraper is not a capital expenditure. It is a headcount commitment, and it does not end.
What follows is the full list of what you take on when you decide to collect Indian court data yourself: the access mechanics, the fragmentation across courts, the ways a parser breaks without telling you, the operational load of running a fleet, and the legal questions that sit above all of it. Then a table that puts both options side by side on the axes that actually decide the outcome.
What You Are Actually Scraping
The phrase Indian court data suggests one thing behind one door. It is at least four things behind several hundred doors, and they do not carry the same information.
The eCourts services portal
Case status, party details, hearing history and orders for District Courts and, in a different shape, for High Courts. This is the workhorse source. It is also the one built most firmly for a human being sitting at a screen, with the access controls that implies.
NJDG
The National Judicial Data Grid publishes pendency and disposal statistics. It is a magnificent public resource and it is aggregate. It will tell you how many civil matters are pending beyond three years in a district. It will not give you the record for the matter you are actually instructed in.
Individual High Court sites
All 25 High Courts run their own portals for judgments, orders, cause lists and display boards. They differ in URL structure, in search form design, in how they paginate, in what they call a case type, and in whether they publish a PDF or an image of one.
Tribunal portals
NCLT, NCLAT, ITAT, CESTAT, SAT, TDSAT and DRT each publish separately, on their own schedules, in their own formats, with their own numbering. A product that covers litigation but not insolvency or tax is not covering litigation.
The first mistake in most scraping plans is treating NJDG summary data and record level data as points on one spectrum. They are different products. Summary data is useful for a market map or a board slide. Record level data is what a firm's case management system, a diligence report or a limitation calculation actually runs on, and it lives behind the per case lookups, one matter at a time.
The Access Layer Is the Whole Problem
Public portals in India are built for people, not for programs, and they defend themselves accordingly. This is the part of the plan that most estimates skip entirely.
CAPTCHAs
The eCourts services portal presents a CAPTCHA on the lookups that matter. That single fact reshapes the entire project. Every route past it is either a person sitting in the loop, which destroys the economics of automation, or an attempt to defeat a control the operator deliberately put there, which is a different kind of decision and should be treated as one rather than as a technical detail. There is no version of this where the CAPTCHA is a minor engineering inconvenience.
Sessions, tokens and state
Beyond the CAPTCHA, a lookup is rarely a single stateless request. It is a session cookie obtained from a landing page, a hidden token carried forward from the form, a sequence of dependent posts where the state selection populates the district selection which populates the establishment selection, and a result page that only renders if every prior step happened in order within the same session. Your client is not fetching a URL. It is impersonating a browsing session, and every element of that session is something that can change.
Establishment codes
District Court data is not addressed by district. It is addressed by court establishment, and the establishment codes are per state, are not published as a stable machine readable list, and change as courts are created, merged, renamed or reorganised. To cover the District Courts you must first build and then maintain a mapping of every establishment across every state, and you must notice when it moves. Nothing will tell you when it moves.
The estimate that is always wrong
Teams cost the scraper by the first source they build. One High Court, working, in a week, therefore 25 High Courts in six months. It does not compose that way. Each portal is a fresh set of quirks, and the maintenance load is not the sum of the build times, it is a permanent function of how many sources you are keeping alive at once. The build is the cheap part. Nobody costs the second year.
The Failure Mode That Costs Real Money
If scrapers failed loudly, this would be a manageable problem. A crashed job pages someone, someone fixes it, life continues. Scrapers rarely fail that way.
A registry changes a page template. A column that used to sit third in the hearing history table now sits fourth. A field that used to be labelled Next Hearing Date is now labelled Next Date. A parser written against the old positions does not throw. It reads the wrong cell, produces a value with the right data type, and writes it to your database. Your monitoring sees a job that ran, returned rows, and exited zero. Everything is green. You are now recording the wrong hearing date for every matter in that court, and you will find out when a client tells you.
The same problem arrives through PDFs. Orders and judgments are published as PDFs whose internal layout is a formatting choice, not a contract. A court changes its template, or moves from a text PDF to a scanned one, or changes the header block, and the extraction that reliably pulled the coram and the disposal line for four years starts pulling something adjacent to it. Scanned output introduces character recognition errors, and a misread digit in a date or a section number is invisible to any schema validation you are likely to have written.
Wrong data is more expensive than no data
A missing record is a visible gap that somebody investigates. A wrong record is an input to a limitation calculation, a diligence report or an advice note, and it propagates. In legal work the cost of a silently incorrect field is not the engineering time to fix it. It is whatever was decided on the strength of it before anyone noticed.
The Ongoing Headcount Nobody Budgets
Set aside the build. Assume you have working collectors for the Supreme Court, a set of High Courts, a slice of District Court establishments and two or three tribunals. What does keeping that alive look like as a standing job?
- Monitoring per source, not per job. A single green dashboard tells you nothing. You need per court volume baselines and alerts on deviation, because the signal that a court broke is that its record count dropped, not that a process crashed.
- Validation that catches semantics, not types. Schema checks pass on wrong data. You need cross field rules: a decision date that precedes a filing date, a next hearing date in the past on an active matter, a disposal nature that never appears anywhere else in that court.
- A repair queue with a human on it. When a template changes, somebody has to diff the old page against the new one, rewrite selectors, backfill the window where data was wrong, and confirm the repair. That is not a background task. It is somebody's Tuesday.
- Proxy, retry and load management. Government infrastructure is not built for sustained automated traffic, and a collector that hammers it is both an operational risk to you and a burden on a public service.
- Storage, deduplication and identity. The same matter appears under different numbers at different stages and across sources. Reconciling that is a data engineering problem with no ready made answer.
- Coverage expansion as a permanent backlog. Every new client asks for a court you do not have. Each one is another portal, another set of quirks, another entry on the maintenance list forever.
A scraper is not a project with an end date. It is a subscription you pay in engineering time, at a price you do not control, set by people who have no idea you exist.
The Comparison, Honestly Drawn
Here are the two options on the axes that decide the answer. The figures are deliberately expressed as shapes rather than numbers, because your numbers depend on your salaries and your coverage requirement, and a fabricated rupee figure would be less useful than the shape.
| Axis | In house scraper | Maintained API |
|---|---|---|
| Setup | Weeks per source. Session handling, form sequencing, establishment code discovery, parser per template, PDF extraction, storage design. First source is fast and misleads you about the rest. | Hours. Issue a key, send the header, read the response envelope. The integration surface is a documented set of endpoints and parameters. |
| Ongoing maintenance | Permanent and unbounded. Grows linearly with the number of sources you cover, and the load is unpredictable because it is triggered by other people's release schedules. | Zero on your side. Upstream changes are absorbed by whoever maintains the collectors. Your integration only changes when you want new behaviour. |
| Coverage | Whatever you have built and are currently keeping alive. Expanding to a new High Court or tribunal is a fresh project, and the answer to a client asking for a court you lack is a quarter, not a day. | The corpus as published: Supreme Court, all 25 High Courts, the district judiciary, tribunals including NCLT, NCLAT, ITAT, CESTAT, SAT, TDSAT and DRT. |
| Failure visibility | Poor by default. The characteristic failure is silent and produces confident wrong values. Getting to good visibility is itself a substantial engineering investment. | Explicit. Errors arrive as a structured envelope with a success flag and a reason. A 429 tells you to wait, a 408 tells you the query was too broad, a 502 tells you the upstream failed. |
| Throughput | Whatever the portals tolerate, which is undefined and can change without notice. There is no published budget to plan against. | A published limit of 10 requests per minute per key, with X-RateLimit headers on every response. Modest, but it is a number you can design a queue around. |
| Data quality work | Yours. Normalisation, deduplication, identity resolution across stages and sources, and the correction of everything OCR got wrong. | Already done upstream, with the honest caveat that metadata completeness still varies by court and by year because the registries themselves vary. |
| Legal posture | Several distinct questions to answer, and to keep answering as portals update their terms. Your counsel, not your engineering lead, owns this. | A commercial agreement with terms you can read once, plan against, and hand to your general counsel. |
| What you are actually buying | Control over the pipeline, and the obligation that comes with it. | Somebody else's obligation to keep the pipeline correct, and your engineers back on your product. |
The Legal Questions, Carefully Stated
This section is deliberately not advice. It is the list of questions to put to counsel before your first collector runs, because the useful observation here is that they are separate questions and teams routinely collapse them into one.
The first is whether the underlying record is public. Judgments, orders and case status published by courts are public records, and the public character of a judicial record is well settled. That answer is comfortable, and it is the answer most teams stop at.
The remaining questions are not about the record at all. Whether an access control such as a CAPTCHA may be circumvented is a question about the control, not about the document behind it. Whether a portal's terms of use permit automated collection is a question about the terms you accepted when you used the site. Whether sustained automated load on government infrastructure is acceptable is a question about the burden you are placing on a shared public service. Whether personal data appearing in those records is subject to obligations under the Digital Personal Data Protection Act 2023 once you have copied it into your own store is a question about you as a processor, not about the court as a publisher. None of these is answered by the fact that judgments are public.
The question to actually put to counsel
Not is this data public. Ask instead: may we access it by this method, at this volume, under these terms, and what obligations attach to us once we hold a copy. Those are four questions and they have four separate answers. A team that has only asked the first has not asked anything yet.
When Building It Yourself Is the Right Call
There are real cases for it, and pretending otherwise would be dishonest. Build it yourself when your coverage requirement is genuinely narrow, one court and one case type, and you can accept a break costing you a day. Build it when the collection pipeline is your product rather than an input to it, and the maintenance is therefore the work rather than a distraction from it. Build it when you need something no aggregator publishes and you have the standing engineering capacity to own it properly, including the monitoring and the repair queue and the person who staffs them.
Buy it when court data is an input to something else you are building. If your product is a case management system, a diligence tool, an in house tracker or a research interface, then every hour spent on establishment codes and PDF templates is an hour not spent on the thing your users are paying for. The CourtMesh API exists precisely for that case: the coverage and the endpoint surface are set out at the API overview, the parameter reference is at the API documentation, and what a call costs is at API pricing.
The Honest Summary
The scraper is not free. It is a hiring decision presented as a technical one. The bill arrives every month in the form of engineers doing selector archaeology instead of building your product, and the largest single line item is not visible on any dashboard: the periods during which your data was wrong and nobody knew.
An API is not magic either, and it is worth being clear about what it does not solve. Metadata completeness still varies by court and by year, because the registries publish unevenly and no downstream party can invent a field a registry never released. District Court records remain thinner than Supreme Court records. Older records remain thinner than recent ones. Only a subset of the corpus carries AI derived analysis. Any vendor telling you otherwise is describing an ambition, not a corpus. What the API removes is not the unevenness of Indian court records. It removes your obligation to personally maintain a fleet of parsers against several hundred portals you do not control.
Do the comparison properly. Count the engineer months, not the sprint. Count the coverage you actually need, not the one court you prototyped. Count the cost of a wrong hearing date reaching a client. Then decide, and be willing to decide either way, but decide with the whole number in front of you.
Cost the second year, not the first sprint
Scraping eCourts is a standing maintenance obligation across 25 High Courts, hundreds of District Court establishments and a set of tribunals that each do things their own way, and its characteristic failure is a parser that keeps producing confident wrong values. CourtMesh maintains that layer so you do not have to, over roughly 310 million cases sourced directly from official government portals with no third party intermediary. The coverage and endpoint surface is at the API overview, the full parameter reference is at the API documentation, and call costs are at API pricing. Price both options across two years before you commit an engineer to the first collector.
Explore CourtMesh
