From Scrape to SLA: Why Your Team Should Move Off services.ecourts.gov.in to the eCourtsIndia API

Moving off services.ecourts.gov.in means swapping a fragile scraper for the eCourtsIndia API: a production data layer over 32 crore+ case records from the Supreme Court, all 25 High Courts, district and taluka courts and 18 tribunal and commission types, with OCR’d orders, 23 documented endpoints and a published rate card. Most teams finish the migration in a single sprint behind a feature flag, then retire their proxy pools, CAPTCHA solvers and on-call scraper babysitting for good.

Last updated: 23 September 2026

Every India-focused background verification team, every fintech underwriting engine and every compliance startup that needs Indian court records has a scraper. It works most days. It falls over during a by-election. It falls over when a big hearing drives traffic to the portal. It falls over on a Friday afternoon when you are on call. This is the practical case for why product teams stop treating services.ecourts.gov.in as a production dependency, and how any team can make the move in a sprint.

Key takeaways

• The portal is slow on purpose. It serves the whole country and throttles reads by design. Building a product on scraping it is building on sand.
• A scraper hides its real cost in proxies, CAPTCHA solves, headless browsers and an engineer’s week. Write it all down and a per-call API fee usually reads as a fraction of it.
• The API is prepaid and published: ₹200 in free credits on signup, pay-as-you-go deposit packs at 3x base rate, or Enterprise plans at the base rate.
• Identity is no longer your problem to hand-roll. For person or company checks, LegalCheck does identity-first background checks at ₹99 a check (₹33 on a subscription).
• Some judgment calls stay yours: the legal basis for a lookup, consent, and what you do with a match.

Where Indian court data actually comes from

Indian court data originates in the eCourts Mission Mode Project, the programme that has been computerising courts since 2007 and is now in Phase III (2023 to 2027), with a sanctioned outlay of ₹7,210 crore. The public face of it is services.ecourts.gov.in for district courts, plus the National Judicial Data Grid for aggregate pendency and disposal figures.

Here is the detail most developers discover too late: there is no single government database you can call. District court data sits behind one set of portals. Each High Court runs its own website and search. The Supreme Court has a separate system again, and every tribunal keeps its own registry. There is no unified public API, no standard data format and no real-time feed. Our map of the Indian court data stack walks through every layer, and From PDFs to APIs explains why that fragmentation is the core engineering problem.

Why the portal is slow on purpose

The public services.ecourts.gov.in portal is run by the e-Committee of the Supreme Court of India as part of the e-Courts Mission Mode Project. It serves a nation. Every advocate, every litigant, every researcher, every journalist. It is throttled on reads by design. Scraping at volume either degrades the portal for everyone, or gets your IP blocked, or both. That is not the portal’s fault. It is the portal doing its job. If your product depends on the portal staying fast for your one customer, you have built on sand.

What that actually costs a product team

• Timeouts during peak judicial hours (10 am to 2 pm IST).
• CAPTCHAs that break your headless browser whenever the portal rotates them.
• Scanned PDFs without OCR. You cannot search inside them.
• Case-type naming that differs from court to court. Our Case Type Encyclopedia decodes them.
• IP bans when your fleet of containers scales past the respectful limit.
• An on-call rotation that quietly reads the e-Committee news feed for portal maintenance windows.

None of these are acceptable for a product promising a BGV turnaround in 24 hours or a KYC decision in five minutes.

A cost and latency model worth sketching

Before any team agrees to retire a scraper, someone in the room asks the only two questions that matter. What does it cost, and how fast is it. Both deserve an honest answer rather than a sales slide. The scraper numbers below are illustrative ranges drawn from the kind of stacks teams run, not a quote, but they are close enough to plan with.

Start with the DIY scraper. The line items rarely show up in one budget, which is exactly why the true cost stays hidden. There is the residential proxy pool, often billed per gigabyte, which climbs every time you add courts or polling frequency. There is a CAPTCHA-solving subscription that bills per solve and spikes without warning whenever the portal rotates its challenge. There is headless browser infrastructure, which is the most expensive way to fetch a row of structured data ever invented, because you are paying compute to render a full page just to read three fields. And there is the part no invoice captures: a meaningful slice of one engineer’s week spent keeping the thing alive. For a mid-volume scraper the salary is usually the largest number on the page.

Now the API side, where the prices are published. New accounts get ₹200 in free credits with no card. After that, pay-as-you-go deposit packs of ₹1,000, ₹2,500 or ₹5,000 (plus GST) bill at three times the base rate, and credits never expire. Enterprise plans at ₹10,000 plus GST a month, or ₹1,00,000 plus GST a year, include 10,000 credits a month and bill at the base rate.

Call	Pay-as-you-go	Enterprise
Case search	₹0.60	₹0.20
Case detail by CNR	₹1.50	₹0.50
Case refresh (single or per CNR in bulk)	₹0.15	₹0.05
Order markdown and PDF	₹5.25	₹1.75
CNR cause-list check	₹0.30 per CNR	₹0.10 per CNR
LegalCheck background check	₹99	₹33

Latency is the other half, and scrapers quietly lose it. A headless fetch against a throttled public portal is a multi-second affair on a good day. You render, you wait on the portal, you sometimes retry through a CAPTCHA, and your tail latency at the ninety-fifth percentile is the number your customer actually feels. A production API returns structured JSON from a warm index, so a single case lookup does not compete for the public portal’s read budget during peak judicial hours. When your own product promises a five-minute KYC decision, the difference between a sub-second call and a six-second-with-retries call is the difference between a clean SLA and a support ticket.

The point of the exercise is not the exact figures, which will differ for your volume and your courts. The point is that once you write all the lines down in one place, the per-call API fee almost always reads as a fraction of the fully loaded scraper, and it buys you a latency profile you can actually put in a contract.

The operational failure modes you inherit with a scraper

A scraper does not fail in one dramatic way. It fails in six small, recurring ways, and each one becomes a page in your runbook.

• Portal CAPTCHAs. The single most common cause of a 2 am page. The portal rotates the challenge, your solver’s success rate drops, your queue backs up, and your turnaround promise slips before anyone is awake to notice.
• Layout changes. A field moves, a table gains a column, an id attribute is renamed, and your parser silently returns the wrong cell. The dangerous version is not a crash. It is a scraper that keeps running and quietly serves bad data into a credit decision.
• Rate limits and IP bans. Scale past the respectful read limit and the portal stops answering you. Now you are rotating proxies to look like more visitors than you are, which is both fragile and a posture no compliance team enjoys defending.
• Entity resolution. The portal returns rows. It does not tell you which Ashok Kumar is your Ashok Kumar. A brittle scraper makes that harder by serving inconsistent fields.
• Freshness. A scrape is a snapshot from whenever it last ran. If your crawl cadence drifts, you serve a hearing date that has already passed.
• Silent partial failures. One state’s portal is down for maintenance while the rest answer. Your scraper returns a confident, incomplete result, and nobody flags the gap until a customer does.

None of these are exotic. They are the ordinary weather of scraping a public portal at volume, and every one of them turns into on-call time you did not budget for.

What teams actually build on Indian court data

The range of products built on this data is wide, but most fall into five shapes. Knowing which one you are building tells you which endpoints matter.

• Litigation trackers for law firms. Case management that pulls hearing dates, status changes and new orders for a whole portfolio. On the API that is case detail plus refresh and bulk refresh, polled on a schedule. Advocates who do not want to build anything can use the AI Clerk, which sends WhatsApp and email alerts on tracked cases.
• Due diligence for lenders and investors. Banks and NBFCs adding litigation checks to loan origination, and investors profiling an acquisition target. Here the question is about a person or company, not a CNR, which is what LegalCheck is for.
• AI legal research tools. Plain-English interfaces grounded in real Indian court records instead of a model’s memory. The eCourtsIndia MCP gives an AI assistant the same data as tools.
• Compliance monitoring. Watching for new filings against a portfolio company, vendor or counterparty, so the team hears about a suit before it becomes a surprise.
• Court analytics. Dashboards on filing, disposal and pendency for researchers, journalists and administrators. Search facets do most of the counting for you.

Advocates and judges are search filters on the case API, not separate profile endpoints, so a “lawyer track record” feature is built from case search filtered by advocate. The complete API guide lists every filter.

The migration checklist

1. Inventory your existing scraper calls. Map each to an equivalent eCourtsIndia API endpoint. The mapping is usually one-to-one. See our developer quickstart.
2. Get an API key. Sign up, use the ₹200 in free credits, and point your existing integration tests at the live, token-authenticated endpoints. Most tests pass on day one.
3. Replace the CAPTCHA solver with an API key header. Delete the retry logic you wrote for the portal. Keep a simple backoff for 429s.
4. Reconcile your field mapping. Diff the API response against what your parser expected. Where the API gives you a clean enum and your scraper guessed, trust the enum. This is where most silent-bad-data bugs quietly get fixed.
5. Set your freshness expectation explicitly. Decide which records you read live, which you refresh on a schedule, and which you cache, and write the cache window down so freshness becomes a documented choice rather than an accident of crawl timing.
6. Switch production traffic behind a feature flag. Gradual rollout. Ten percent. Fifty percent. All. Watch your error rate and tail latency at each step.
7. Decommission the scraper. Archive scraper_v7. Send the screenshot to your team. Buy them coffee.

What an API solves, and what stays with you

Moving to an API removes the fetch problem. It does not remove every problem, and any vendor who tells you otherwise is selling. Here is the honest split.

• Party-name aliasing. “Ashok Kumar Sharma” and “A. K. Sharma” can be the same person in real life and different strings in the index. Case search gives you the rows and a name match mode; ranking raw search hits is still your code.
• Scanned and handwritten pages. Some older orders are still images. OCR covers what it can, and the rest stays an image, so plan for pages that still need a human.
• Court-code drift. NCLT bench codes need the trailing zero (NCLTMB0). New courts appear and get added, so your code should tolerate a new code showing up rather than assume a fixed list. Read the live enums instead of hard-coding.
• Name-to-identity resolution. This one has moved. If your question is “does this person or company have litigation against them”, you no longer have to build the linkage yourself. LegalCheck runs an identity-first background check and returns a risk band, a summary and every match with how it was matched. Through the API it is six endpoints under /api/partner/legal-check at ₹99 a check on pay-as-you-go or ₹33 on a subscription, with free status and report reads. The LegalCheck API guide covers the details.

What stays yours is the judgment layer: the legal basis for running a check, your consent flow, your audit trail, and what your product does with a match. That is the right division of labour. For the wider picture of court-record background checks, read our guide to checking court cases against any person or company.

A vendor-neutral framework

When evaluating any Indian court data provider, ask six questions. How is the index kept fresh? What is the SLA? What is the OCR coverage? Which courts are covered? What is the pricing as a function of call volume? Who has audited the data pipeline? The answers tell you whether you are buying production infrastructure or a scraper behind a salesperson.

Ask the same questions of eCourtsIndia and most answers are public. Coverage is 32 crore+ case records across the Supreme Court, all 25 High Courts, district and taluka courts in all 36 states and union territories, and 18 tribunal and commission types. Freshness is on your terms: any case can be re-pulled from the official servers with a refresh call, typically in 2 to 10 minutes. The pricing page publishes the per-call rate card and a 99.9% uptime SLA on its infrastructure. The API documentation lists all 23 endpoints, the rate limits and the error codes. For the last question, audits, ask any vendor directly and ask for it in writing.

What this means for product teams

Your engineers did not take the job to maintain a scraper. Your product did not promise court data because court data was easy. Move the data layer to an API that treats it as a first-class responsibility, and spend your engineering time on the workflow your customer actually pays for. Our MCP guide covers the AI layer, and the complete API guide covers everything else.

The fastest path from a fragile scraper to a product with an SLA is one sprint and a feature flag.

Further reading: Developer quickstart, LLMs.txt for Indian Courts, Court Data Watch: Delhi Cause Lists, LegalCheck launch.

Frequently Asked Questions