Court Records API vs Court Data API: Which One Your App Actually Needs

Short answer: a court records API gives you the raw filings (complaints, motions, exhibits, dockets, transcripts) the way PACER and state e-filing systems publish them. A court data API gives you the processed layer built on top: indexed opinions, citation networks, treatment flags, judge analytics. If you need the paper a court emitted, you want a records API. If you need intelligence built from many cases, you want a data API. Most production apps end up wiring both.

TL;DR

• A court records API returns the literal filings: complaints, motions, exhibits, dockets, transcripts. PACER, RECAP, Docket Alarm, UniCourt, Trellis, and judyrecords sit here.
• A court data API returns the analytical layer: indexed opinions, citation graphs, treatment flags, judge biographies, structured case metadata. vLex, Bloomberg Law, and Lex Machina sit here.
• The cleanest PACER API alternative for most teams is RECAP for already-archived federal dockets, with PACER's own Case Locator API or UniCourt for live pull-on-demand.
• PACER costs $0.10 per page, capped at $3.00 per document, with quarterly fees waived under $30.00 (PACER, June 2026).
• Most production legal-AI apps end up using both lanes, at very different price points. This post walks the distinction with real providers, sourced prices where public, and a decision tree at the end.

Part of our MCP and developer guide series.

For related MCP / API / developer coverage, see Best Legal Data APIs for Developers in 2026.

Why this terminology is broken

The two terms are used interchangeably across vendor pages, Hacker News threads, and Reddit's r/legaltech, and that is the first reason developers waste a week picking the wrong product.

"Court data API" can mean an analytics surface on top of indexed cases (Lex Machina pattern), raw scraped opinion text, or the full PACER docket layer (Bloomberg Law pattern). "Court records API" usually means filings, but some vendors use it to describe opinion search too.

What you actually need to pick a vendor is to know what your product needs to do. Three questions cut through the marketing:

1. Do you need the actual filing PDF (complaint, motion, exhibit), or do you need the case to exist as a structured record with a docket number and parties?
2. Do you need indexed opinion text with citation networks, or just the docket?
3. Are you doing analytics across cases (judge tendencies, motion outcomes, time to trial), or single-case lookups?

The answers map cleanly to one of the two lanes.

Court records API: the filing layer

A court records API returns what a lawyer would pull off PACER or a state e-filing portal: docket sheets, individual filings as PDFs, exhibits, transcripts, party lists, judge assignments, and the procedural history of the case. It is the raw paper trail.

Use it when your product needs to track active cases (a litigation monitor, a docket-alert tool), retrieve specific filings (a brief generator that ingests the underlying complaint, a discovery-document tool), or audit the procedural history of a specific matter. Litigation finance, insurance defense, IP enforcement monitoring, plaintiff lead-gen all live here.

Providers worth knowing:

PACER itself. The federal-court system. PACER does publish a real REST API: a PACER Case Locator (PCL) API for nationwide case and party search, plus a separate Authentication API that returns a token you pass on every request (PACER, June 2026). Both speak JSON or XML. What PACER does not give you over API is bulk document retrieval, so most production pipelines pull dockets through PCL and grab the actual PDFs through RECAP or scraping. Billing is $0.10 per page, capped at $3.00 per document, with audio files at $2.40 each and quarterly fees waived under $30.00 (PACER, June 2026). Costs climb fast at production scale.

RECAP. A free archive of PACER documents that other users have already pulled. The RECAP API exposes what is already in the archive at no charge.

When you need a document that is not yet in RECAP, the system can trigger a fresh PACER pull (which costs you), or you can wait. Most production litigation apps use RECAP as a first-cache layer in front of PACER.

Bloomberg Law's docket API. Federal + state coverage, including pull-on-demand for state filings RECAP does not cover. Enterprise pricing, no public number, expect mid-five-figures per year minimum for a real seat.

Docket Alarm (Fastcase / vLex). Federal plus many state courts, alerts on docket changes, full-text search across dockets and filings. Pricing roughly $99 per user per month for the platform, custom for API access.

UniCourt. The volume play, and the one most teams reach for as a PACER API alternative. UniCourt advertises an API-first platform over 140+ million federal (PACER) and state court records and more than 2 billion dockets and documents, with a Court Data API, a Legal Analytics API, and its own PACER API (UniCourt, June 2026). Paid, contact-sales. Strong on state coverage where federal-only tools fall short.

Trellis. State trial court records with real depth in California (Los Angeles, Orange, San Diego, Alameda), Texas, and Illinois, plus rulings, judge analytics, and webhooks. Trellis API V2 (May 2024) added federal and PACER integration on top of the state layer (Trellis, June 2026). Contact-sales with a free trial.

judyrecords. It does have a real API now, contrary to what older write-ups (including an earlier version of this post) claimed. judyrecords exposes a Full-Text API across over 750 million cases and a Structured Objects API across over 650 million cases and 1.2 billion parties (judyrecords, June 2026). Programmatic access is allowed only through that API; scraping the UI is off-limits. Pricing is contact-sales (api@judyrecords.com).

The shared trait across this lane: the underlying data has acquisition cost (PACER pages cost money, scraping state courts costs engineering time and breaks weekly). That cost gets passed to the API consumer somehow, either directly or as part of a high-touch enterprise contract.

Court data API: the indexed-opinion and analytics layer

A court data API returns the structured intelligence built on top of cases: opinion full text, citation graphs, treatment flags (overruled, distinguished, criticized), case headnotes, judge biographies, party history, statutory citations within opinions. It is the layer where the case has been processed, not just published.

Use it when your product needs to ground answers in actual law (a legal-research agent, a citation-check tool, a brief generator), surface "good law" status (a Shepardize-equivalent feature), do analytics across cases (judge-shopping analytics, motion-grant rates, settlement timing), or recommend similar cases.

Most legal-AI apps shipping in 2026 are this lane, regardless of how they market themselves.

Providers worth knowing:

vLex (acquired by Clio, also operates Fastcase + Vincent AI). Roughly one billion legal documents globally including US case law, statutes, and editorial enhancements. API access via Fastcase contracts, enterprise pricing.

Westlaw API. Limited public API surface; most Thomson Reuters integrations are partnership-led. Pricing is not published, and access runs through a sales relationship. If the gate is the problem, see LexisNexis and Westlaw API alternatives for developers.

LexisNexis API. Same situation as Westlaw. Lexis+ AI and Protege are platform features, not API products you build against from the outside without an enterprise relationship.

Bloomberg Law data API. Court opinions, dockets, analytics, all in one. Strong on financial-services case law. Enterprise pricing.

Lex Machina. Analytics-focused. Not a research API; it is a litigation analytics product (judge tendencies, motion outcomes, time-to-trial benchmarks) with an API surface for embedding analytics into other tools. Owned by LexisNexis.

Statute and primary-law APIs. Adjacent to the case-data layer but distinct. A primary-law API exposes the US Constitution, US Code, CFR, Federal Rules of Procedure, 50-state statute codes, state constitutions, state court rules, and every Executive Order since 2015.

Case law typically sits in a separate product surface, not the statutes API. The distinction matters for your architecture: if your product needs unified case plus statute access, plan for two API surfaces and a thin merge layer of your own.

Create an API keyBook a demo

Where the two lanes overlap

Some providers serve both lanes from one platform. Bloomberg Law and vLex sell records and data together, but at enterprise price points where the choice between "we need records" and "we need data" stops mattering because you bought everything in one contract.

Records is what the court emitted; data is what got built on top of it.

That is the cleanest mental model. The same vendor can publish both when it does the indexing itself.

The decision tree

Four common product cases, with the right lane for each:

1. Litigation monitor or docket alert tool. Records layer. Start with RECAP + PACER fallback. Add Bloomberg or UniCourt for state coverage if your customers care.
2. Citation-grounded legal research agent (the "Westlaw, but AI" category). Data layer. vLex/Westlaw enterprise if you need editorial quality and have the budget.
3. Discovery / brief ingestion tool that needs the actual filings. Records layer. RECAP + on-demand PACER pulls, budgeted carefully.
4. Judge or motion analytics, win-rate dashboards. Lex Machina (paid) or build it yourself on a licensed opinion corpus + structured judge metadata. Most teams underestimate what "build it yourself" costs.

Pricing reality

Roughly, by lane:

A few notes most marketing pages do not surface:

• PACER charges add up nonlinearly. A docket with 200 filings averaging 10 pages each at $0.10/page is $200 just to pull the case once. A 5,000-case crawl is hospital-bill territory.
• Westlaw and Lexis API access is gated by sales process, not just price. If you do not already have a relationship, expect months.

Gotchas across both lanes

A few production lessons that translate across vendors.

Search recall is not the same as data quality. A records-layer API can return 200 dockets matching your query, but if the docket parsing is bad, every record is missing the field you actually need. Test the response shapes against your real use case before committing.

State coverage varies wildly. Federal coverage is consistent across vendors. State coverage is patchwork.

RECAP covers federal; state court data is split across UniCourt, Trellis, Bloomberg, and one-off scraping. If your product needs uniform state coverage, plan for a multi-vendor stitch.

Rate limits are aspirational. Free tiers often "5,000 requests per day" really means 5,000 requests per day if you do not also trigger expensive search operations or pagination. Practical throughput is usually 30-50% of the published cap. Plan accordingly.

Citation formats are not standardized across vendors. A "410 U.S. 113" returns slightly different metadata from Westlaw, vLex, and Bloomberg. If you are merging across sources, write a canonical citation normalizer upfront.

What to do this week

If you are scoping a legal product right now:

1. Write down which of the four use cases you are actually solving. If you cannot pick one, you are scoping too broadly.
2. Match the use case to the lane (records or data) using the decision tree above.
3. Start free where you can. RECAP for already-archived federal records is good enough to validate a v1.
4. Budget for the lane you missed. Most products eventually need both. Plan the architecture for that from day one, with a thin merge layer between sources.

FAQ

What is the difference between a court records API and a court data API?

A court records API returns the filings a court emitted: dockets, complaints, motions, exhibits, transcripts, the way PACER and state e-filing portals publish them. A court data API returns the layer built on top: indexed opinion text, citation networks, treatment flags, and judge analytics. Records is the paper; data is the intelligence derived from it.

What is the best PACER API alternative?

For already-archived federal dockets, RECAP is the cheapest path. For live pull-on-demand at volume, UniCourt advertises an API over 140+ million federal and state records (UniCourt, June 2026), and PACER's own Case Locator API handles nationwide case search. PACER itself still bills the underlying pages at $0.10 each, capped at $3.00 per document (PACER, June 2026).

Does PACER have an official API?

Yes. PACER publishes a Case Locator (PCL) API for nationwide case and party search and a separate Authentication API that issues a token for each request (PACER, June 2026). Both return JSON or XML. There is no official bulk-document API, so most teams pull PDFs through RECAP or scraping.

Is court data always public and free to use?

Court records are generally public, but access is not free. PACER charges per page, and many state portals charge or rate-limit. RECAP is free because it re-publishes federal dockets that users already pulled, but it only covers what is already in the archive. Commercial APIs like UniCourt and Trellis charge for normalization, coverage, and uptime.

How do court data providers get their information?

They pull from the same primary sources: PACER for federal courts and individual state e-filing systems for the rest. The value they add is normalization, deduplication, entity resolution (linking parties, attorneys, and judges across cases), and a stable API on top of court systems that change formats often.

Can I get state court records through one API?

Not uniformly. Federal coverage is consistent, but state coverage is patchwork split across UniCourt, Trellis (deep in California, Texas, Illinois), and Bloomberg Law. If your product needs broad state coverage, plan for a multi-vendor stitch rather than one provider.

Do I need a case-law API or a statutes API?

They are different surfaces. Case law (opinions, dockets, citations) comes from PACER/RECAP or the enterprise vendors above. Statutes and regulations (US Code, CFR, 50-state codes, the Constitution, Federal Rules) come from a separate primary-law API. If your product needs both, plan for two API surfaces and your own thin merge layer.

Vaquill AI's own public API sits squarely in the primary-law lane: US Code, CFR, 49-state statutes, state constitutions, court rules, and Executive Orders. It does not serve case law or dockets over the API, so for filings you would wire RECAP or PACER as above. (Case-law research and AI answers live inside the Vaquill AI app, across millions of US court opinions, just not in the public REST API.) For more on the statutes side, see /legal-api, or email contact@vaquill.ai.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.