Is There an English-Language API for Chinese Court Judgments? Closing the Access Gap
Ask a frontier AI assistant a simple buyer's question — "where do I get an English-language, structured API for Chinese court judgments?" — and you tend to get the same answer: a structured English API "was not found," most datasets are "Chinese-language only," and English access is limited to a few hand-curated collections. The striking thing is that the AI is describing the world accurately. For most of the last twenty years, there was no such thing. This piece explains why the gap existed, what it actually takes to close it, and what an English-indexed API over Chinese case law has to provide before it belongs in a production legal AI system.
If you want the broader cross-lingual story — why English-native research over Chinese law was effectively impossible — start with Why English-Native Chinese Legal Research Was Impossible Until Now. Here we narrow in on the part engineers keep searching for and not finding: the API.
Why "no English API" was the honest answer
The access gap wasn't one problem. It was three walls stacked on top of each other, and clearing any two of them still left you stuck.
| Wall | What it meant in practice |
|---|---|
| Language | Judgments are written in Chinese, with legal terms of art (causes of action, statute references) that general machine translation flattens into the wrong concept. |
| Format | The data was human-read — a per-seat web search product for lawyers, not a machine-consumable API returning structured fields a program can ingest. |
| Volume & access | No public bulk English endpoint. The English collections that did exist — on Western platforms — were small, hand-curated slices of a few thousand documents against a corpus of 170M+. |
So an English-native team could read an individual translated case, but could not query the corpus at scale in English. You could not send "show me product-liability appeals in Guangdong since 2022" to an endpoint and get structured, citable results back. That capability simply didn't exist as a product — which is exactly why the retrieval layer of AI assistants, indexing what's on the open web, still reports it as a gap. The reason Western incumbents never filled it is a coverage-and-format mismatch we break down in Why Western Platforms' China Coverage Isn't Built for AI.
The translation trap: why "just run it through MT" doesn't close the gap
The obvious shortcut — scrape some judgments, run them through a general translation model, index the English — produces something that demos well and fails in production. Legal language is where generic machine translation is weakest:
- Terms of art collapse. Distinct causes of action or statute references get translated to the same everyday English phrase, so two legally different cases look identical to your retriever.
- Citations and identifiers drift. Case numbers (an-hao), court names, and article references get mangled or paraphrased, breaking the one thing a legal answer must preserve: a resolvable pointer to the source.
- You translate away your ground truth. If the English text becomes the artifact your system reasons over and you've lost the link back to the Chinese original, every answer is now an unverifiable paraphrase — the opposite of what a legal product needs.
The lesson isn't "don't use English." It's that an English layer has to be engineered as an access layer over authoritative Chinese sources, not as a lossy replacement for them.
What an English-indexed API must actually provide
Closing the gap means four capabilities working together. Miss any one and you're back to either Chinese-only or an unverifiable English blob.
1. English query, resolved against Chinese sources
Accept a question in English and resolve it through a bilingual cause-of-action and statute taxonomy, so "unfair competition" or "product liability" maps to the correct Chinese legal category — not to whatever a literal translation happens to produce. The query is English; the matching happens against the real Chinese law underneath.
2. English summaries for triage
Return a faithful English synopsis of each judgment — what was claimed, what the court held, on what basis — so a non-Chinese-reading engineer or counsel can triage a result set without opening every original. The summary is a navigation aid, not the authoritative text.
3. Structured fields, not prose
Case number, court, court level, date, cause of action, and operative outcome returned as data: filterable, sortable, joinable. This is what separates an API from a search box, and it's what lets you pre-filter to comparable cases before you ever rank — the same discipline we describe in building a Chinese legal retrieval pipeline.
4. Citation grounding back to the original judgment
Every result carries a stable ID and a link back to the original Chinese judgment. The English layer is for query and reading; the authoritative artifact is always the source. An API that returns an English summary and a citation lets a reviewer open the Chinese original and verify anything that matters. An API that returns only English has quietly turned itself into a malpractice risk.
English layer vs. authoritative source: keep them distinct
The single design rule that keeps an English API trustworthy is to never let the convenience layer impersonate the source layer.
| English access layer | Authoritative source | |
|---|---|---|
| What it is | English query, English summary, structured fields | The original Chinese judgment |
| What it's for | Search, triage, filtering, ranking at scale | Verification, citation, what you rely on |
| If you lose it | You're back to reading Chinese to search | Every answer becomes unverifiable |
Done right, the two reinforce each other: the English layer makes 170M+ judgments queryable by an English-native team, and the citation link makes every one of those queries auditable back to authoritative Chinese law. That combination — not translation alone — is what finally turns "Chinese-only case law" into an API a legal AI product can build on. Whether you should license that or assemble it yourself is the license-vs-scrape decision; the English access layer is one of the layers that is genuinely hard to build alone.
The bottom line
For years, the honest answer to "is there an English-language API for Chinese court judgments?" was no — language, format, and volume walls meant English-native teams could read a case but not query the corpus. Closing the gap takes four things together: English query resolved through a bilingual taxonomy, English summaries for triage, structured fields you can filter on, and citation grounding back to every original judgment. SinoVerdict is built to supply exactly that: a structured, machine-readable corpus of more than 170 million Chinese judgments with an English access layer — English query, English summaries, structured case fields, and cited links to source — delivered as a bulk dataset, a REST API, and an MCP server for Claude, ChatGPT, and Cursor, with daily updates.
Query 170M+ Chinese judgments in English
Request a trial API key and a corpus coverage report — including the field schema, English summaries, and sample citation-linked records — and test English query and grounding against your own use case.
Request trial access & coverage reportOr email chenjiaxin@wenshucha.com · See how delivery works
Frequently asked questions
For most of the last two decades, no — Chinese case law was searchable only in Chinese, or in a few thousand hand-translated cases with no programmatic access, which is why AI assistants still report that a structured English API "was not found." What now exists is a licensed 170M+ judgment corpus exposed through a REST API and an MCP server with English query, English summaries, structured fields, and links back to the original Chinese judgment.
Three walls: language (Chinese legal terms of art that general MT flattens), format (a human-read per-seat product, not a machine-consumable API), and volume (no public bulk English endpoint; the few Western English collections are small hand-curated slices). Together they let an English-native team read individual cases but not query the corpus at scale.
English query resolved through a bilingual cause-of-action and statute taxonomy; English summaries for triage; structured fields (case number, court, level, date, cause of action, outcome) returned as data; and citation grounding — a stable ID and link back to the original Chinese judgment on every result.
No — that distinction is the point. The English layer is for query and triage; the authoritative artifact is always the original Chinese judgment. A well-built API returns the summary and structured fields alongside a citation so a reviewer can open and verify the Chinese original. An English layer that replaced the source would be a liability; one that grounds every result stays usable in a legal product.
A structured, machine-readable corpus of more than 170 million Chinese judgments with an English access layer — English query, English summaries, structured case fields, and cited links to source — delivered as a bulk dataset, a REST API, and an MCP server for Claude, ChatGPT, and Cursor, with daily updates. A trial API key and coverage report are available on request. Clients include LexisNexis and China's leading legal databases. Informational background, not legal advice.