Attach the Statute to Every Case: Enriching a Litigation Portfolio With Section Text and Classification

Last updated: 3 November 2026

Key takeaways

• Three layers, three prices. Case Detail gives you the citations on a record free inside the call; /case/{cnr}/provisions adds section text, classification and equivalents per distinct section; the Acts batch endpoint reads up to 50 sections at a time.
• Be honest about coverage. In our tests on 3 November 2026, most CNRs returned no parsed citations, and the rest carried citations the corpus could not resolve. Most records today carry only the court’s own act and section string.
• The fallback works: split the court string, resolve the act name to a key once, read every distinct section in a batch, and cache the result against the corpus version.
• Deduplicate at portfolio level. A thousand cheque cases cite the same few sections. You pay for Section 138 once, not a thousand times.
• Classification is per offence row. BNS 318 creates three offences and BNS 316 four. Store every row and pick the one that matches the facts; never collapse a section to one label.

What does a case provisions API do, and why would a legal team want one?

It answers the second question every litigation report gets asked: not just “what cases do we have”, but “under what law, and how serious is it”. A case list tells you a complaint is pending in a magistrate’s court. The statute layer tells you it is a Section 138 cheque complaint, that a company accused brings its officers in under Section 141, and that the cheating count alongside it is cognizable and non-bailable.

General counsel, lenders, background-verification teams and litigation funders all hit the same wall here. The court record stores the act and section as free text typed by a registry clerk. One registry writes Negotiable Instruments Act, 1881 | Section 138, another writes Negotiable Instruments Act | Section 138, a third types the BNS section under the IPC heading. Before you can group, count or classify, someone has to turn those strings into exact provisions and read them. Doing it by hand for a few hundred matters is a week of a junior’s time; doing it with an API is a script.

eCourtsIndia sells both halves on one key. The case side covers 35 crore+ records across the Supreme Court, the High Courts, district and taluka courts and tribunals. The statute side, the same corpus that powers IndiaCode by eCourtsIndia, holds 4 lakh+ provisions of Central and State Acts, the Constitution, the CPC First Schedule and subordinate legislation. IndiaCode is independent of the government’s India Code (indiacode.gov.in), and the Gazette remains the authoritative text.

Which endpoints attach a statute to a case?

Four endpoints do the work: Case Detail for the citations, Case Provisions for the enriched sections, Resolve for act names, and the Acts batch endpoint for many sections at once. Case Search v2 then lets you query the portfolio by statute.

Endpoint	What it returns	Price (base / Pay As You Go)	Use it when
GET /api/partner/case/{cnr}	The full case record, including courtCaseData.provisions: act as written, act key, unit, number and IndiaCode URLs	₹0.50 / ₹1.50 per case; the provisions list costs nothing extra	Always: you need the case record anyway
GET /api/partner/case/{cnr}/provisions	Every cited provision with section text, offence block, offence rows and equivalents; unresolved citations come back as section: null	₹0.05 / ₹0.15 per distinct section returned; unresolved citations and empty cases free	A record has parsed citations and you want the law in one call
GET /api/partner/acts/resolve?name=	The citation key for an act name, or candidates when the name is ambiguous	₹0.05 / ₹0.15, charged only on a single match	You only have the court’s act string
POST /api/partner/acts/sections/batch	1 to 50 sections with text, classification and equivalents; duplicates collapsed; not-found free	₹0.05 / ₹0.15 per distinct section	Portfolio-level enrichment
GET /api/partner/v2/search	Cases filtered by actKeys, provisions or provisionPaths, with a provisionPath facet	₹0.20 / ₹0.60 per call	“All our cases under NI Act 138”
GET /api/partner/acts/status	Corpus version and counts	Free	Cache invalidation

Pay As You Go packs are ₹1,000, ₹2,500 or ₹5,000 plus 18% GST and never expire. The docs list rate limits of 100 requests a minute, 3,000 an hour and 50,000 a day, with 10 concurrent; back off exponentially on a 429. The statute API guide covers every Acts endpoint, unit and error code in detail.

What does the enriched provision look like?

Each provision carries the act as the court wrote it, its key, unit and number, and a section object with heading, text, an offence block, an offences[] list for multi-offence sections, offence_source and equivalents[]. The docs’ own example, abridged, shows the shape for a BNS 115(2) citation:

{
  "act_as_written": "Bharatiya Nyaya Sanhita (B.N.S.), 2023",
  "act_key": "2023/45", "unit": "s", "number": "115(2)",
  "section": {
    "act": {"key": "2023/45", "title": "The Bharatiya Nyaya Sanhita, 2023"},
    "section": {
      "number": "115", "heading": "Voluntarily causing hurt",
      "offence": {"cognizable": false, "bailable": true,
                  "punishment": "Imprisonment for 1 year or fine of 10,000 rupees, or both.",
                  "triable_by": "Any Magistrate.", "offences": []},
      "offence_source": "own",
      "equivalents": [{"key": "1860/45", "number": "321", "relation": "near-identical",
                       "direction": "predecessor"}]
    }
  }
}

That is an example from the API docs, trimmed for space, not a live response. Four fields deserve attention in your data model:

• number keeps the sub-section the court cited (115(2)), while section.number is the section the corpus holds (115). Store both: one is what the record says, the other is what you can read.
• offences[] is the truth for multi-offence sections. The top-level offence block mirrors the first row. For BNS 318 the first row is simple cheating, which is bailable; the row for dishonestly inducing delivery of property is not.
• offence_source tells you where the classification came from. own means the section’s own First Schedule row. equivalent:2023/45/s/318 means a repealed IPC section is being classified through its BNS successor.
• equivalents[] carries a relation label, near-identical or close and a direction.

How many cases have parsed citations today?

Few. Of seven CNRs we tested through the eCourtsIndia MCP on 3 November 2026, six returned an empty provisions list and one returned a single citation that the corpus could not resolve. The tool said so plainly each time: parsed citations are not yet populated for most cases, and an empty list does not mean the case cites no law.

Record we tested	Court string on the record	Case provisions result
MSR Leathers v. S. Palaniappan, Supreme Court (SCIN010047712001)	None on the record	No parsed citations; not charged
Delhi Race Club (1940) Ltd. v. State of Uttar Pradesh, Supreme Court (SCIN010172722024)	None on the record	No parsed citations; not charged
A Bajaj Finance Limited complaint, Metropolitan Magistrate Court, Ahmedabad (2025)	Negotiable Instruments Act, 1881 | Sections 138, 142	No parsed citations; not charged
A second Bajaj Finance Limited complaint, same court (2025)	Payment AND Settlement Act, 2007 | Section 25	No parsed citations; not charged
An IIFL Finance Limited complaint, Metropolitan Magistrate Court Complex, Calcutta (2025)	Bharatiya Nyaya Sanhita (B.N.S.), 2023 | Sections 318(2), 318(3), 318(4), 316	No parsed citations; not charged
The CNR used in the docs’ Case Provisions example	Not read	No parsed citations; not charged
The CNR used in the docs’ Case Detail example	Not read	One citation: CrPC with a blank section number, returned with section: null; not charged

Two lessons come out of that table. First, Supreme Court records usually carry no act and section line at all; for those, the citation lives in the order text, and the order AI analysis lists the provisions it cites. When we ran it on the MSR Leathers judgment, it listed Sections 138 and 142 of the Negotiable Instruments Act. Second, district records often do carry a court string, as the three finance-company complaints show. That string is the raw material for the fallback.

An empty result costs nothing, so call Case Provisions first and drop to the string route when it comes back empty. As parsing coverage grows, more records move to the first route without a code change.

How do I enrich a case when the record has only the court string?

Split the string at the pipe into act and sections, resolve the act name to a key once, pull the section numbers out, read the distinct sections in one batch, and flag anything odd for a human. Here is the IIFL Finance string from the table, worked through on 3 November 2026.

1. Split. Bharatiya Nyaya Sanhita (B.N.S.), 2023 on the left, Sections 318(2), 318(3), 318(4), 316 on the right.
2. Resolve. A common name like the BNS maps to 2023/45 without a paid call. For an unusual spelling, call Resolve once and cache the key. We tried the messier string from the Bajaj Finance record, Payment AND Settlement Act, 2007, and Resolve returned a single match: 2007/51, The Payment and Settlement Systems Act, 2007.
3. Extract. Four references: 318(2), 318(3), 318(4) and 316.
4. Batch. We sent all four to lookup_provisions, the MCP twin of the batch endpoint. Three came back as section 318 and one as section 316, so the call was charged for two distinct sections, not four.
5. Classify per row. Store every offence row each section returns and mark the ones that match the sub-sections the court cited.

This is what the two sections returned, via the eCourtsIndia MCP on 3 November 2026:

Cited	Offence row	Punishment	Cognizable / bailable	Triable by
318(2)	Cheating	Imprisonment for 3 years, or fine, or both	Non-cognizable, bailable	Any Magistrate
318(3)	Cheating a person whose interest the offender was bound, either by law or by legal contract, to protect	Imprisonment for 5 years, or fine, or both	Non-cognizable, bailable	Any Magistrate
318(4)	Cheating and dishonestly inducing delivery of property	Imprisonment for 7 years and fine	Cognizable, non-bailable	Magistrate of the first class
316	Criminal breach of trust	Imprisonment for 5 years, or fine, or both	Cognizable, non-bailable	Magistrate of the first class
316	Criminal breach of trust by a clerk or servant	Imprisonment for 7 years and fine	Cognizable, non-bailable	Magistrate of the first class
316	Criminal breach of trust by a carrier, wharfinger, etc.	Imprisonment for 7 years and fine	Cognizable, non-bailable	Magistrate of the first class
316	Criminal breach of trust by public servant or by banker, merchant or agent, etc.	Imprisonment for life, or imprisonment for 10 years and fine	Cognizable, non-bailable	Magistrate of the first class

Equivalents came back with the same call. BNS 318 lists IPC 415 as near-identical and IPC 418 and 420 as close predecessors; BNS 316 lists IPC 405 and 408 as near-identical and IPC 406, 407 and 409 as close. Store them: when you search for similar matters filed before 1 July 2024, you will need the old numbers, and our IPC to BNS guide lists the pairs trial courts use most. The sibling guide on finding case law on a section explains why both numbers matter.

The cheque and e-mandate side has a twist worth knowing. NI Act 138, 142 and Payment and Settlement Systems Act 25 all came back with text but with the offence block empty on 3 November 2026: the corpus returned no classification row for these special-Act offences, so the text does the work instead. Section 25 makes dishonour of an electronic funds transfer for insufficient funds punishable with imprisonment up to two years, or fine up to twice the amount, or both, and its sub-section (5) applies Chapter XVII of the Negotiable Instruments Act “to the extent the circumstances admit”. Section 142 says no court inferior to a Metropolitan Magistrate or a Judicial Magistrate of the first class shall try a Section 138 offence.

What does a portfolio table by act and section look like?

Group every case by the act key and section its citations resolve to, then count, and keep a column for records that could not be resolved. We built the first cut for one public company’s 2025 district-court filings to show the shape.

A search for cases filed in 2025 in district courts with Bajaj Finance Limited as petitioner, matched as a phrase, returned several thousand records, mostly criminal complaint cases, followed by sessions trials, civil suits, criminal miscellaneous applications, execution applications and arbitration matters. Filtering on the court’s act string then gave this:

Court string contains	Records (filed 2025, district courts), as of 3 November 2026	Resolves to	What the statute layer adds
Negotiable Instruments Act	1,865	1881/26, mostly s.138 with s.142	Text of 138 and 142; Section 141 if the accused is a company; no classification row in the corpus
Payment and Settlement	1,549	2007/51 s.25	Dishonour of electronic funds transfer; NI Act Chapter XVII applies to the extent circumstances admit
Everything else, or no string	The remainder	Unresolved until read	Order text or a human reading the record

Read those counts with care. They are matches on what the registry typed, so a record with a misspelt act name drops out, and a record citing two Acts appears in both rows. Always compare a filtered count with the unfiltered total before you trust it. A matched litigant name is also not proof of identity: confirm each record belongs to your entity before it goes into a board note.

For a general counsel, Section 141 is the line that changes the risk view. We read it on 3 November 2026: where the person committing a Section 138 offence is a company, every person who was in charge of and responsible to the company for the conduct of its business, as well as the company, is deemed guilty, subject to a proviso for lack of knowledge or due diligence and a carve-out for directors nominated by virtue of a government office or employment. A portfolio where your company is the accused, not the complainant, needs that column. The general counsel’s portfolio guide covers the case side of that workflow.

How do I find all our cases under NI Act 138 with Case Search v2?

Pass the statute as a provision path, add your entity as a litigant, and read the provisionPath facet for the split by section; then run a text search beside it, because path filters only see parsed citations. Request shape from the API docs:

curl -G "https://webapi.ecourtsindia.com/api/partner/v2/search" \
  --data-urlencode "litigants=Your Company Limited" \
  --data-urlencode "nameMatchMode=phrase" \
  --data-urlencode "provisionPaths=1881/26|s|138" \
  --data-urlencode "provisionPaths=2007/51|s|25" \
  --data-urlencode "provisionFacetPrefix=1881/26" \
  --data-urlencode "sortBy=filingDate desc" \
  -H "Authorization: Bearer eci_live_your_token_here"

Three things to know. A section path such as 1881/26|s|138 matches that section and its sub-sections; an act path such as 1881/26 matches every section of the Act; up to 50 valid paths are used. The provisionPath facet counts acts, or the children of whatever you put in provisionFacetPrefix. And v2 computes facets only when the result set is small enough, so read data.facetMode; a date sort keeps the count exact on a name search. Because parsed citations are thin today, run the same litigant search with actsAndSections=Negotiable Instruments Act and merge the two result sets by CNR. The eCourts API pillar documents the rest of Case Search v2.

What does the code look like?

About forty lines of Python: read each case, take parsed citations if present, otherwise parse the court string, then read every distinct section once in batches of 50. This is a sketch written against the documented endpoints; the live results in this post come from the equivalent MCP calls, not from running this script.

import os, re, requests
BASE = "https://webapi.ecourtsindia.com/api/partner"
H = {"Authorization": "Bearer " + os.environ["ECI_TOKEN"]}
ACT_KEYS = {}                                  # court act string -> key

def act_key(name):
    if name not in ACT_KEYS:                   # resolve each spelling once
        r = requests.get(BASE + "/acts/resolve", params={"name": name}, headers=H)
        ACT_KEYS[name] = (r.json()["data"].get("match") or {}).get("key")
    return ACT_KEYS[name]

def citations(cnr):
    d = requests.get(f"{BASE}/case/{cnr}", headers=H).json()["data"]["courtCaseData"]
    parsed = [(p["actKey"], p["unit"], p["number"]) for p in d.get("provisions") or []
              if p.get("actKey") and p.get("number")]
    if parsed:
        return parsed, "parsed"
    act, _, secs = (d.get("actsAndSections") or "").partition("|")
    key = act_key(act.strip()) if act.strip() else None
    nums = re.findall(r"\d+[A-Z]*(?:\(\d+\))?", secs)
    return [(key, "s", n) for n in nums if key], "court string: review"

def enrich(cnrs):
    cases, sections = [], {}
    for cnr in cnrs:
        cites, how = citations(cnr)
        cases.append({"cnr": cnr, "how": how, "cites": cites})
        for k, u, n in cites:
            sections[(k, u, n.split("(")[0])] = None   # 318(2), 318(4) -> 318
    keys = list(sections)
    for i in range(0, len(keys), 50):
        body = {"sections": [{"key": k, "unit": u, "number": n} for k, u, n in keys[i:i + 50]]}
        r = requests.post(BASE + "/acts/sections/batch", json=body, headers=H)
        for s in r.json()["data"]["sections"]:
            q = s["requested"]
            sections[(q["key"], q.get("unit") or "s", q["number"])] = s["section"]
    return cases, sections

Production code needs more than this. Handle 402 INSUFFICIENT_CREDITS before a batch, since the balance must cover the batch size up front; retry 429 and 503 CORPUS_UNAVAILABLE with backoff; and log every row marked “court string: review” for a person to check, because a regex reading sec138 &142 or 223of will sometimes be wrong. Cache the section results with the corpus version from the free /acts/status call, and only re-read when the version changes.

What does it cost to enrich a portfolio?

The case records dominate the bill; the statute layer is close to a rounding error once you deduplicate. Illustrative arithmetic at published prices for a 1,000-case portfolio, assuming it cites 40 distinct sections across 20 distinct act spellings:

Step	Calls	Pay As You Go	Base rate (Enterprise)
Case Detail, once per case	1,000	1,000 × ₹1.50 = ₹1,500	1,000 × ₹0.50 = ₹500
Resolve each distinct act spelling	20	20 × ₹0.15 = ₹3	20 × ₹0.05 = ₹1
Batch read of distinct sections	1 batch of 40	40 × ₹0.15 = ₹6	40 × ₹0.05 = ₹2
Per-case Case Provisions instead, at 2 sections a case	1,000	2,000 × ₹0.15 = ₹300	2,000 × ₹0.05 = ₹100

The last row is the point. Calling Case Provisions on every case is convenient, and for a small portfolio it is the simplest route. At scale, reading each distinct section once and joining locally is cheaper by more than an order of magnitude on the statute side, and it is the only route that works for records without parsed citations.

Who uses case-to-statute enrichment, and for what?

• General counsel and in-house teams: exposure by statute across business units, matters where the company is the accused, and officers drawn in under provisions such as NI Act 141.
• Lenders and NBFC credit teams: what a borrower’s or guarantor’s litigation is actually about, with recovery, cheque and fraud matters separated. The borrower due diligence workflow puts this beside company and land records.
• Background-verification teams: explaining a pending criminal matter in plain words, classified by its own First Schedule row, with the caveat that pending is not guilt.
• Litigation funders and analysts: portfolio composition by Act, section and court, with old and new code numbers joined so that pre-2024 and post-2024 matters count together.

The legal due diligence API tutorial shows the surrounding pipeline, from name search to report, if you are building this into a product.

What this does not tell you

Sources and method

• Endpoints, field names, billing rules and request shapes: eCourtsIndia API docs (saved copy read 3 November 2026). Prices: eCourtsIndia API pricing, read 3 November 2026.
• Case Provisions tests on seven CNRs: eCourtsIndia MCP lookup_case_provisions, run 3 November 2026.
• Order citations for MSR Leathers: eCourtsIndia MCP get_order_ai_analysis, run 3 November 2026.
• Act resolution of “Payment AND Settlement Act, 2007”: eCourtsIndia MCP resolve_act, run 3 November 2026.
• Text and classification of BNS 316 and 318, IPC 420, NI Act 138, 141 and 142, and PSS Act 25: eCourtsIndia MCP lookup_provisions, run 3 November 2026.
• Bajaj Finance Limited and IIFL Finance Limited record counts and court strings: eCourtsIndia MCP search_cases, run 3 November 2026.
• Government sources: India Code (indiacode.gov.in), Legislative Department, Ministry of Law and Justice; e-Gazette (egazette.gov.in) for authoritative text, referenced 3 November 2026.

Frequently asked questions