How to Integrate a Case Status API into Your Systems (India) (2026)
A developer-facing guide to integrating a case status API in India: the fields you get, matching by CNR or party name, polling versus alerts, and what to watch on reliability and data freshness. Last verified October 2026.
How-To Guide · Developers
Integrating a case status API means wiring an Indian court data source into your own system so case details flow in automatically: the stage, the next hearing date, the latest order. Done well, your team stops checking court websites by hand and starts getting updates where they already work. This guide is for developers and technical leads. It covers the fields you usually get, how to match a case reliably, when to poll versus when to use alerts, and the reliability points to watch. Last verified October 2026.
- Match on: the 16-character CNR wherever you have it; it uniquely identifies a case.
- By name: use name-tolerant matching plus a confirmation step, because Indian party names vary in spelling.
- Keep current: poll on a schedule, and use event alerts or webhooks for changes where the provider supports them.
- Build for lag: expect a gap between court and API, store a last-updated timestamp, and add retries and coverage checks.
01What integration actually involves
A case status integration has three moving parts: getting the data in, matching it to the right case, and keeping it current. The data comes from a court data source over an API. Matching means tying each result to a case in your own records. Keeping it current means deciding how often you refresh and how you learn about changes.
Before writing code, be clear about the job. Are you tracking a known, fixed list of matters, for example a lender’s own litigation? Or are you searching for any case against a name, for example at onboarding? The answer drives almost every later choice. For the background on what these APIs expose, see what a court data API is.
02The fields you usually get
Most case status APIs expose a similar core set of fields. Expect some or all of these, named differently by each provider:
| Field | What it holds |
|---|---|
| CNR | The unique 16-character case number, the safest key to match on |
| Parties | Petitioner and respondent names, and advocates |
| Court and case type | The court, the case type and the case number |
| Stage / status | Pending or disposed, and the current stage |
| Next hearing date | The date the case is next listed |
| Orders / judgments | Links to or text of orders passed |
| History | Past hearing dates and what happened on each |
Map these to your own schema rather than storing the raw response, so a change in a provider’s field names does not break your system.
03Matching by CNR or party name
Matching is where integrations quietly go wrong. There are two ways to find a case, and they are not equally reliable.
- By CNR: the 16-character CNR uniquely identifies one case. If you have it, store it and match on it. This is the gold standard.
- By party name: needed when you do not yet know the case, for example at onboarding. But Indian party names are spelled inconsistently, a common name can belong to many people, and one person can appear under several spellings.
Name matching needs tolerance and a confirmation step
Plain exact-text matching on a name either misses real cases or flags the wrong person. Use a source with name-tolerant matching, and always confirm a returned case actually belongs to your subject before you act on it. For how this plays out in practice, see how a litigation check API works.
04Polling versus alerts
Once you can match a case, decide how you keep it current.
- Polling: you ask the API for the status of your tracked cases on a schedule, say once a day. Simple to build, but you only learn of a change at the next poll, and you spend calls even when nothing changed.
- Event alerts or webhooks: the provider tells you when something changes, for example a new hearing date or order. More efficient and more timely, where the provider supports it.
A common pattern is a daily poll for the full portfolio plus alerts for high-priority matters. Respect the provider’s rate limits, spread your calls out, and never hammer a court-backed source, because aggressive polling can get you throttled or blocked.
05Reliability: what to watch
Court data is messy at the source, so build for imperfection:
- Freshness lag: there is always a gap between what happens in court and what the API returns. Store a last-updated timestamp and surface it to users.
- Coverage gaps: no single source covers every court and tribunal perfectly, and the Supreme Court sits outside the main eCourts system. Confirm your target courts are covered.
- Downtime and errors: build retries with backoff, and fail safe, so a missed poll does not silently drop a case.
- Data quality: expect spelling variation, missing fields and the odd duplicate. Validate before you act.
For the enterprise workflows this feeds, see litigation monitoring by API, and to compare providers, the best court data and case-tracking APIs in India.
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.
On the integration side, what matters is breadth, matching and data handling. Claw tracks cases, orders and hearings across 9,102 courts, benches and forums, so a portfolio keyed by CNR or party name can be followed from one place instead of many court sites. Its case search spans 30 crore+ judgments, with Supreme Court decisions from 1950 and High Court decisions from 1990, returning results in under 5 seconds, with name-tolerant matching that handles the spelling variation Indian names are prone to. Claw does not use your case documents to train its AI models, which matters when litigation data flows through an integration.
Create a FREE Claw account to try case search across Indian courts before you integrate, and confirm API details with Claw directly.
07Sources and further reading
- eCourts (official court data portal): ecourts.gov.in
- National Judicial Data Grid: njdg.ecourts.gov.in
- Claw: clawlaw.in
This is general technical information, not advice. API fields, limits and coverage change, so confirm them with each provider and the official sources before you build against them.
08Frequently asked questions
How do I integrate a case status API in India?
Decide whether you are tracking known cases by CNR or searching by party name, get access credentials, store a clean key such as the CNR for each case, pick a sync pattern of polling or alerts, map the fields to your own model, and add retries and freshness checks. Test on a small known set before scaling.
What fields does a case status API return?
Typically the CNR, the parties and advocates, the court and case type, the stage or status, the next hearing date, orders and judgments, and the case history. Names differ by provider, so map them to your own schema.
Should I match cases by CNR or by party name?
By CNR wherever possible, since the 16-character CNR uniquely identifies one case. Match by party name only when you do not yet know the case, and then use name-tolerant matching plus a step to confirm the case belongs to your subject, because Indian names vary in spelling.
Should I poll or use alerts?
Polling asks for status on a schedule and is simple but less timely. Event alerts or webhooks tell you when something changes and are more efficient, where the provider supports them. A common mix is a daily poll for the full set plus alerts for priority matters.
What reliability issues should I plan for?
A lag between court events and API data, coverage gaps including the Supreme Court sitting outside the main eCourts system, provider downtime and errors, and messy data with spelling variation and missing fields. Store a last-updated timestamp, add retries with backoff, and validate before acting.
Can I use the official eCourts or NJDG API directly?
Official NJDG open API access is restricted mainly to government bodies and institutional litigants with a department identifier and access key. Most businesses integrate a private provider built on public court data, so confirm coverage, fields and limits with that provider.