Home/Offers/Legal, Compliance & GovTech/Litigation Intelligence API

Legal, Compliance & GovTech

Litigation Intelligence API

Court records are public, enormous and almost unusable in their native form. Making them queryable is most of the product.

Legal research platforms
Litigation finance firms
Insurers and reinsurers
Law firms
Corporate legal departments

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Litigation data answers questions that are otherwise guesswork. How long does this type of claim take in this court. Which firms appear opposite us most often, and in what outcomes. Is there a cluster of similar claims against a product line that nobody has joined up. For an insurer, whether a class of claim is accelerating; for a litigation funder, what the base rate for a case type actually looks like.

Getting there is tedious in a specific way. Court record systems differ by jurisdiction and often by court, with inconsistent party naming, scanned documents, docket entries written in local shorthand, and access rules that range from fully open bulk data to paid per-document retrieval with terms that forbid redistribution. Entity resolution alone is substantial work: the same corporate defendant appears under a dozen spellings and several group entities.

The analysis sits on top of that and has a limit worth stating plainly. Aggregate statistics about case duration, claim types and outcome distributions are solid and useful. Predicting how a specific case will come out is not — the determinants sit in evidence, argument and judgement that the docket does not contain. Products that blur this sell confidence they do not have.

Who buys this

Legal research platforms, Litigation finance firms, Insurers and reinsurers, Law firms, Corporate legal departments

Category: Legal, Compliance & GovTech

What the API returns

What comes back

Case records with parties, court, cause of action, filing date and status
Docket timeline with normalised event types across differing local terminology
Filing summaries with citations to the document and page
Resolved party entities linked across name variants and group structures
Duration and outcome distributions by court, case type and claim size band
Cluster detection across cases sharing parties, counsel, product or allegation
Counsel and firm appearance statistics where the records support it
Access and coverage flags stating what is retrievable per court and on what terms

Endpoints

Method	Path	Returns
POST	/v1/cases/search	Search cases by party, court, cause of action and date
GET	/v1/cases/{id}	Case record with docket timeline
GET	/v1/cases/{id}/filings/{filing_id}/summary	Cited summary of one filing
POST	/v1/entities/resolve	Resolve party names to entities across variants
GET	/v1/analytics/duration	Duration distributions by court and case type
POST	/v1/clusters	Detect related case clusters across a corpus

Request and response

illustrative

Request

{
  "party": { "name": "Kelmore Industries", "resolve_group": true },
  "jurisdictions": ["US-FED", "GB-EWHC"],
  "causes": ["product_liability", "breach_of_contract"],
  "filed_between": ["2022-01-01", "2026-10-01"],
  "include": ["duration_stats", "clusters"]
}

Response

{
  "entity": { "resolved": "Kelmore Industries Group",
              "variants_matched": 11, "subsidiaries_included": 6 },
  "cases_found": 84,
  "by_cause": [
    { "cause": "product_liability", "n": 37 },
    { "cause": "breach_of_contract", "n": 29 }
  ],
  "duration": {
    "cause": "product_liability",
    "court": "US-FED",
    "median_days_to_disposition": 611,
    "p90_days": 1402,
    "sample": 1840,
    "basis": "docket_disposition_entries"
  },
  "clusters": [
    {
      "cluster_id": "cl_118",
      "cases": 9,
      "shared": ["defendant_group", "product_line_reference", "plaintiff_counsel"],
      "first_filed": "2024-11-08",
      "filing_rate_trend": "increasing",
      "note": "Shared allegations; no finding of liability in any case to date."
    }
  ],
  "coverage": [
    { "court": "GB-EWHC", "documents": "metadata_only",
      "reason": "per_document_access, redistribution_not_permitted" }
  ]
}

Where the data comes from

Court electronic records	Dockets and filings where bulk or programmatic access is permitted — terms differ sharply by jurisdiction and some permit metadata only
Official judgment databases	Published decisions, often under an open licence, which are the cleanest part of the corpus
Court calendars and registers	Hearing and listing information, useful for status tracking
Company registry data	For resolving corporate parties to entities and group structures, which raw docket names cannot support
Licensed legal research sources	Where consolidated or annotated material is needed; redistribution is usually forbidden, so these inform rather than populate the output
Your own matter records	For a firm or insurer, internal matter data joined to public records is where most of the specific value appears

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Jurisdiction-specific ingestion with per-court parsers, because docket conventions are local and a generic scraper produces unusable records
Docket event normalisation onto a common taxonomy, so 'motion to dismiss granted' and its local equivalents aggregate correctly
Entity resolution on parties and counsel combining registry identifiers, address and co-occurrence, with the match basis retained for audit
Cause-of-action classification from filing text where no structured code exists, reported with confidence
Summaries generated under citation constraint and validated against the source document, with the summary withheld rather than shown if a claim cannot be grounded
Survival analysis for duration statistics, because ongoing cases are censored and ignoring that systematically understates how long matters take
Explicit refusal to score outcome likelihood for an individual case — aggregate base rates by court and case type are supportable, a per-case prediction is not
Coverage and access metadata attached to every result, so a gap reads as a gap rather than as an absence of litigation

What it changes for the business

Research that finishes

Entity-resolved search across jurisdictions replaces manual docket trawling for exposure and conflict questions.

Earlier claim signal

Cluster detection surfaces a developing pattern of similar claims before it is a named class action.

Grounded expectations

Duration and outcome distributions by court give clients a realistic timetable instead of an optimistic one.

Underwriting and funding inputs

Base rates by case type are a defensible input to pricing and funding decisions, which anecdote is not.

How it fits into your product

How it embeds

REST search and retrieval for research interfaces, with cited summaries returned alongside records
Bulk extracts into your own warehouse where your licences permit it
Entity resolution endpoint you can run against your own party and client lists for conflict and exposure checks
Webhooks on new filings involving watched entities, which is the main ongoing use for insurers and in-house teams
Deep links to the source docket entry, because a litigator will always want the document
Deployment inside your infrastructure where matter data is joined to public records

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Can you predict who will win a case?

No, and we would decline to build it. Outcomes turn on evidence, argument, procedural posture and judicial reasoning — almost none of which is in a docket. We will provide base rates by court, case type and claim band, clearly labelled as population statistics. A per-case win probability dressed up from docket metadata is a confident-sounding number with nothing underneath it, and in litigation funding or reserving it would be actively harmful.

What coverage is realistic?

It depends entirely on access regime. Some federal and national systems permit programmatic bulk retrieval of dockets and documents. Others publish judgments openly but charge per filing and forbid redistribution, so you get metadata and links rather than text. The coverage endpoint states the position per court, including where we can see that a case exists but cannot retrieve the documents.

Are the summaries reliable enough to rely on?

They are reliable enough to triage with, and every assertion carries a citation to the document and page so a lawyer can verify in seconds. They are not a substitute for reading a filing that matters to a live matter, and we would build the interface to encourage opening the source rather than trusting the summary.

How is case duration measured given ongoing cases?

With survival analysis, treating open cases as censored observations. Simply averaging closed cases is a common error that makes everything look faster than it is, because long matters are over-represented among the still-open. The API reports the method and sample alongside every figure.

Does mentioning a party in a cluster imply wrongdoing?

No, and the output is written to avoid implying it. A cluster is a statement that several cases share parties, counsel, product references or allegations. It is not a finding, and every cluster record carries the disposition status of its cases. Presenting an allegation pattern as established conduct would be both wrong and defamatory.

All Legal, Compliance & GovTech offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers