Most court data integrations fail in a way that never generates a support ticket. The integration works. The data is correct. It sits behind a tab labelled Research that a fee earner opens in the first week, twice in the second week, and never again. Six months later somebody asks whether the firm is getting value from it, and nobody can say, because the feature was never in anybody's path.
The lesson is not that lawyers resist software. It is that a tab is an invitation and a field is a fact. An associate opening a matter to draft a letter sees the fields on that matter whether they meant to or not. They will not navigate to a second screen to check whether the other side has forty pending recovery proceedings, because at the moment they are drafting a letter, that question has not occurred to them. The integration has to put the answer where the question will arise.
This article is for teams building or extending firm software: practice management systems, case management tools, in house legal platforms, and the growing set of internal tools large Indian firms build for themselves. It sets out where court data actually belongs across the matter lifecycle, how to design the sync inside a real budget of 10 requests per minute per key, and where the honest limits of any aggregated view of registry data lie.
The Winning Integration Surface Is the Matter Record
Start from the design conclusion and work backwards, because it determines everything else. Court data should appear as fields on the matter, not as a destination a user navigates to.
The reasoning is about attention rather than technology. Legal work is organised around matters. A partner's mental model of the firm is a list of matters. Time is recorded against matters, documents are filed against matters, and conflicts are cleared against matters. Anything that lives outside that model competes for attention with the matter itself and loses, every time, on a busy day. Anything that lives inside it is seen without effort.
There is a second reason, less obvious and more important. A field on the matter record can be wrong in a visible way. If the next hearing date field says 14 August and the associate knows it was adjourned to September, they will notice, and now you have a correction loop. A research tab cannot be visibly wrong, because nobody is looking at it. Putting data in the user's path is what makes the data improve over time.
A separate research tab is a tool people forget to open. A field on the matter is a fact people see, and a fact people see is a fact people correct.
The test for any court data feature
Ask where in the existing workflow the question this feature answers actually arises, then put the answer there. Party litigation history belongs on the intake form, not in a research module. The next listed date belongs on the matter header, not in a report. Orders belong in the matter's document list beside the documents the firm drafted. If the answer to where does this live is a new screen, the feature will not be used.
Intake: Search the Party Before You Open the File
The first place court data earns its keep is before a matter exists at all. A prospective client walks in, or a counterparty is named in an instruction, and somebody types a name into a new matter form. That is the moment to run a search.
Mechanically this is a POST /search/cases with the party name as the query, filtered by court where the client's operations suggest a jurisdiction, and by a date window where only recent activity matters. It is one call. The value of that one call at intake is disproportionate, because everything discovered later is discovered after the firm has already committed.
- Volume tells you what kind of client this is. A prospective client with a long tail of section 138 proceedings under the Negotiable Instruments Act 1881 is a different engagement, with a different fee structure and a different risk profile, from one with two commercial suits.
- Pending insolvency changes the commercial question. Proceedings before the NCLT under the IBC 2016 against a prospective client, or against the counterparty in a recovery matter, go to whether the engagement is worth taking on the terms proposed.
- Existing proceedings may already cover the instruction. Occasionally a search shows that the dispute the client is describing is already before a court, sometimes with different counsel on record. That is worth knowing on day one rather than in week three.
- The name itself is a finding. Indian party names transliterate several ways and corporate entities change names on restructuring. Where a search returns near misses, capture the variants on the record. Every later conflicts check and every later monitoring run inherits that work.
A design note that matters at intake more than anywhere else: this call has to be fast enough to sit inside a form. That means a keyword search with tight filters, a limit that fits the panel rather than the maximum of 100, and no AI call in the path. Semantic search and the analysis endpoints are slower and draw credit, and neither belongs in a field that fires while somebody is typing. Debounce the input, cap what you display, and let the user ask for more.
Conflicts: Counterparty Exposure as a Standing Question
Conflicts checking in most firms is an internal exercise. It asks whether we have acted against this party, whether anyone in the firm has a relationship, whether the matter touches an existing client. Those are the right questions, and court data does not replace them.
What court data adds is the external half of the picture: what this counterparty is already litigating, against whom, and where. That is not strictly a conflict in the professional sense, but it is exactly the intelligence a partner wants before a first meeting, and the intake system is where it can be gathered without anyone doing extra work.
The design pattern is to run the counterparty search once at intake, store the result set against the matter as a snapshot with a timestamp, and re run it on a schedule for matters that are live. The snapshot matters because a conflicts record needs to say what was known when. A screening that says the counterparty had no insolvency proceedings is a defensible statement only if it also records as at which date, against which name variants, and across which courts it was run.
Name variants are the whole difficulty
A screening run against one spelling of a party name is a screening with a hole in it. Indian records carry transliteration variants, abbreviated corporate suffixes, entities renamed after restructuring, and individuals recorded with and without honorifics or initials. The search fields accept a string, a comma separated string, or an array, so several variants can go into one call rather than several. Record which variants were searched alongside the result, because that list is the substance of what the screening actually covered.
Matter Tracking: The Fields That Belong on the Record
This is the core of the integration, and it is the smallest part to build. A handful of fields from the case record, written onto the matter, changes the daily experience of running a practice more than any other feature discussed here.
| Field on the case record | Where it belongs in the firm tool | Why it earns its place |
|---|---|---|
| nextHearingDate | Matter header, and the diary or calendar view | The single most consequential date in a live matter. It drives briefing, counsel availability and client updates, and it is the field people currently chase by telephone. |
| caseStage | Matter header | Where the proceeding has reached. It tells a partner whether the matter needs attention this week without opening the file, and it is the field that makes a matter list readable at a glance. |
| caseStatus | Matter header and matter list filters | Pending or disposed, at the level the registry publishes it. It is what allows an accurate active matter list rather than one maintained by memory. |
| caseHistory | Matter timeline view | The sequence of listings and what happened on each. This is what a new associate reads to get up to speed, and reconstructing it manually from the file takes hours. |
| lastListedOn | Matter header, beside the next date | Context for the next date, and the first signal that something is stale. A matter last listed months ago with no forward date is a matter worth a telephone call. |
| cnr | Matter identifiers | The stable identifier for the proceeding across systems. Store it at intake and every later lookup, reconciliation and support query becomes straightforward. |
| acts and sections | Matter classification | Drives practice area reporting, precedent suggestions and know how. It is also the cheapest way to make a matter list searchable by subject rather than by name. |
| disposalNature | Matter closure workflow | How the proceeding ended, as the registry recorded it. It is what should prompt the closure checklist, rather than a monthly review noticing that the matter went quiet. |
Two implementation notes. First, store the source and the fetch time next to every synced field. A date on screen with no provenance is a date somebody will argue about. A date labelled as published by the registry and retrieved at a stated time is a date somebody can act on, or check. Second, never overwrite a value a human has edited. If an advocate has recorded that a matter was adjourned to a date not yet reflected upstream, the sync must not silently revert it. Keep both, show both, and flag the divergence for somebody to resolve.
Documents, Billing and Reporting
Document management
Judgments and orders belong in the matter's document list, alongside the pleadings and correspondence the firm produced. That is where somebody looks for a document, so that is where the document should be.
GET /cases/:id/pdf returns a presigned link with an expiresIn of 3600 seconds. The important discipline here is that the link is time limited and issued per request, so it must never be stored in your database as though it were a permanent document URL. A firm tool that saves that URL will show working documents for an hour and broken links thereafter, and the failure will surface at the worst possible moment. Fetch on demand when a user opens the document, or retrieve the file once and store it in your own document store under your own retention and access controls, which for a firm handling client data under the DPDP Act 2023 is generally the position your policies will require in any event.
GET /cases/:id/related is the natural companion. It returns every stored document sharing a case number, sorted by decision date ascending and capped at 50, together with an assembled timeline whose entries carry a date, a status of either final judgment or hearings and orders, a status label that prefers the disposal nature where present, and a document id. One call populates a matter's document history. Reconstructing the same thing with individual fetches costs a call per document, which on a constrained budget is a poor trade.
Billing and reporting
Once matters carry structured court metadata, reporting stops depending on how carefully somebody filled in a form. Realisation by case type, cycle time from filing to disposal by court, hearings per matter, exposure by forum: these become queries over your own database rather than manual exercises, because the classification came from the registry record rather than from a dropdown that somebody rushed on a Friday evening. For firms doing Commercial Courts Act 2015 work, or arbitration under the Arbitration and Conciliation Act 1996 where a section 34 challenge has its own rhythm and cost profile, this is the difference between knowing what a matter type costs to run and guessing at it.
Mapping Workflow Stage to Endpoint
Here is the whole integration in one table. It is deliberately short, because the surface that a firm tool needs is smaller than most teams assume.
| Firm workflow stage | Endpoint that serves it | Cadence |
|---|---|---|
| Intake and party search | POST /search/cases with the party name as query, filtered by court and date window | Once per prospective matter, interactively, with a small limit so it fits in a form |
| Conflicts and counterparty screening | POST /search/cases across name variants, stored as a timestamped snapshot | At intake, then periodically for live matters |
| Attaching a matter to a proceeding | GET /cases/:id, which accepts either the internal case id or a case number | Once, at the point the matter is linked, storing the cnr for later lookups |
| Matter status and diary | GET /cases/:id for nextHearingDate, caseStage, caseStatus and lastListedOn | Nightly reconcile over the watched set of live matters |
| Matter document history | GET /cases/:id/related for the family of documents and the assembled timeline | On matter open, then cached, since decided documents do not change |
| Retrieving a judgment or order | GET /cases/:id/pdf for a presigned link valid for 3600 seconds | On demand, never cached as a permanent URL |
| Full hearing history | POST /request-timeline to start the job, GET /get-timeline/:requestId to poll | On explicit user request, in the background lane, never on page load |
| Research from inside a matter | POST /search/cases for known vocabulary, POST /search/cases/semantic for a described fact pattern | Interactive, user initiated, with semantic kept out of automated paths because it draws credit |
| Case summarisation for a brief | GET /cases/:id/analysis first, POST /cases/:id/analyze only when nothing is stored | Read on open, generate only on a deliberate user action |
| Judge name entry and autocomplete | GET /judges/search with a q parameter over a curated Supreme Court and High Court name list | Interactive, cheap, no AI credit consumed |
Sync Design Inside a Real Budget
The constraint that shapes everything is 10 requests per minute per API key. That is 600 an hour, and 14,400 a day if nothing is wasted. It is a modest budget and it is entirely sufficient for a firm tool, provided the design is built around it from the start rather than discovered halfway through a rollout.
The mistake to avoid is polling everything. A firm with three thousand matters, refreshed hourly, needs three thousand calls an hour and has six hundred. The answer is not a bigger budget. It is a watched set: only live matters are synced, only the fields that actually move are refreshed, and the cadence is nightly rather than continuous.
Define the watched set explicitly
Live matters only. A disposed matter needs no daily refresh, and a decided judgment is immutable and can be cached indefinitely. In most firms the watched set is a small fraction of total matters, and that is precisely what makes the arithmetic work.
Reconcile nightly, not continuously
Registries publish on their own rhythm, driven by listing and by data entry, not by your poll interval. Checking a matter twelve times a day produces eleven identical answers and one useful one. A single overnight pass per watched matter is the right default, with a second pass after cause lists move if the firm's practice warrants it.
Sync fields, not whole records
The volatile fields are nextHearingDate, caseStage, caseStatus, lastListedOn and the tail of caseHistory. Party names, filing date, court and case number do not move. Keep the last known values so that computing a diff is cheap and so that you can show a user what changed rather than only what is current.
Queue the work, do not loop it
A shared token bucket refilling at ten per minute, drawn on by every caller including interactive searches from users, is the only structure that behaves correctly once more than one thing is running. A fixed sleep inside a loop breaks the moment a second worker or a user search appears on the same key.
Use a separate key per workload
The limit is enforced per key. If the nightly reconcile and the intake search box share one key, the reconcile will starve the users and the users will make the reconcile unpredictable. One key for background sync, one for interactive traffic, and separate keys per environment. Keys are shown once at creation and stored only as hashes, so treat issuing them as a deliberate act.
Make partial completion loud
Count matters attempted, matters updated and matters that failed, and alert on the difference. The dangerous outcome is not a sync that fails visibly. It is one that fails quietly and leaves a stale date sitting on a matter header that somebody then relies on.
Where a firm needs hearing history rather than current status, POST /request-timeline starts an asynchronous job for a case and returns a requestId with a status, sometimes with cached true, a message, an order count and the orders immediately when the work had already been done. GET /get-timeline/:requestId is the poll target and returns the status along with orders and counts as they become available. That work belongs in the background lane, triggered when somebody actually asks for a hearing history, never on every page load.
When Nothing Changes for Weeks, That Is Not an Answer
Here is the failure mode that a well built sync creates, and it is worth designing against deliberately because it is counterintuitive: the better your integration, the more your users will trust its silences.
The sync runs nightly. For six weeks a matter shows no change: same stage, same status, no new hearing date. The interface, quite reasonably, shows nothing new. The associate reads that as no movement. But silence in registry data has several possible causes, and only one of them is that nothing happened.
Nothing did happen
The matter genuinely has not been listed. This is common and it is the reading everyone defaults to, which is exactly why the other possibilities are dangerous.
Something happened and has not been published
Data entry at a registry follows the hearing rather than accompanying it, and the lag varies by court and by establishment. The order exists; the record of it has not appeared yet.
It was published somewhere your query does not reach
A transfer, a renumbering on registration, a matter moving between benches or from a District Court to a High Court. The proceeding is moving under a different identifier, and a lookup on the old one returns a record that has stopped changing.
Your sync stopped and said nothing
A key deactivated, a queue that stalled, a 429 swallowed by a retry wrapper. The screen looks identical to a genuinely quiet matter, which is the whole problem.
The design response is to make the distinction visible. Show the time of the last successful check separately from the time of the last observed change. Those are two different facts and users conflate them constantly. A matter that says last checked at 02:14 today, last change 41 days ago carries a completely different meaning from one that says last checked 41 days ago, and the second is a sync failure wearing the costume of a quiet matter. Escalate on staleness thresholds that reflect the court and the stage rather than a single global number, and let a user mark a matter as verified by telephone, because sometimes the only way to resolve the ambiguity is to ask the registry.
The Registry Is the Authority, and Your Software Is a View
Everything a firm tool displays about a live proceeding is a view of what registries published. That sentence should appear in your product documentation, and its consequences should be visible in the interface itself rather than buried in terms nobody reads.
The data originates from official government sources, principally eCourts, the National Judicial Data Grid and the court registries themselves, covering the Supreme Court, all 25 High Courts, the district judiciary and tribunals including NCLT, NCLAT, ITAT, CESTAT, SAT, TDSAT and DRT. That provenance is a real advantage over anything sitting behind a third party intermediary. It is not a guarantee of completeness, and the two should not be confused.
Metadata quality varies considerably. District Court records are thinner than Supreme Court records. Older records are thinner than recent ones. Fields that are present and reliable for one court in one year may be sparse for another, and an absent field usually means the registry never published it rather than that your sync dropped it. Build reconciliation that can tell those two situations apart, because a pipeline that treats missing upstream metadata as a fetch failure will retry the same records indefinitely and still never fill the gap.
A date on a screen is not a date in the cause list
No aggregated feed should be the last word before a step with consequences. If a limitation period under the Limitation Act 1963 turns on it, if an appearance depends on it, if a client is being told when the matter is next listed, somebody must confirm against the registry or the cause list before acting. Design for that confirmation instead of designing around it. Show provenance, show the check time, and make it one click to reach the source document. A tool that quietly encourages a partner to skip verification has created a liability, not a feature.
What to Build First
For a team starting this week, the sequence that produces value soonest is not the sequence that is most technically interesting.
Begin with matter linkage and four fields. Let a user attach an existing matter to a proceeding, store the cnr and the case id, and sync nextHearingDate, caseStage, caseStatus and lastListedOn onto the matter header with provenance and a check time. That is one endpoint, a nightly job and a header component, and it removes an entire category of telephone calls from the firm's week. Ship it, watch which fields people correct by hand, and let that tell you what to build next.
Then add intake search, because it is one interactive call and it changes conversations before an engagement is accepted. Then the document list from the related endpoint, which is again one call per matter and turns the matter file into something complete. Analysis, semantic search and consolidated summaries come later, deliberately, because they draw credit and belong behind explicit user intent rather than inside automated paths.
The endpoint and parameter reference is at the API documentation, coverage across the courts and tribunals is set out at the API overview, and if your firm's tooling is being built around an assistant rather than a traditional interface, the same data is reachable through the MCP server. Price the call volume for your matter count at API pricing before you commit to a sync cadence, because the cadence is the cost.
Put the data where the work already happens
Court data changes how a firm operates only when it appears on the matter record, next to the work it informs. The CourtMesh API gives you party search for intake and conflicts, case records carrying nextHearingDate, caseStage, caseStatus, caseHistory and cnr for matter tracking, a related documents endpoint and presigned judgment links for document management, and timeline jobs for full hearing history, over a corpus of roughly 310 million records sourced directly from official government portals. Design the sync around 10 requests per minute per key and a watched set of live matters, show provenance and check times so that silence is never mistaken for stability, and remember that the registry remains the authority. Start with the endpoint reference and the coverage detail at the API overview.
Explore CourtMesh
