How to Scrape CourtListener Opinions & Dockets in 2026

US case law is public record — court opinions carry no copyright — but getting it in bulk is another matter. The full-text search on court websites is built for a human reading one case at a time, PACER charges per page, and stitching together a citation-analysis dataset by hand is a non-starter. CourtListener solves the access problem with a free, keyless API covering over 4 million opinions and millions of PACER-sourced dockets. This guide covers what that API exposes, how the three scrape modes map onto it, and how to pull clean legal records at scale.

What’s worth extracting

The actor returns a consistent structured record for every opinion, docket, or court — about 18 fields. Grouped by what you’ll query on:

• Case identity — caseName (short form, e.g. “Sony Corp. v. Universal City Studios”), caseNameFull (the formal name), and type (opinion, docket, or court).
• Court — court (full name), courtId (the CourtListener code like scotus, ca9, dcd), and jurisdictionType.
• Citations & docket — citation (e.g. “464 U.S. 417”), docketNumber, clusterId, and docketId.
• People — judge (or the panel) and attorney names on the case.
• Substance — status (Published, Unpublished), snippet (an opinion excerpt or the party list for dockets), and cause (cause of action, dockets only).
• Timeline & links — dateFiled, the CourtListener case-page url, and a downloadUrl to the opinion document when one is available.

Opinions mode gives the richest text — citation strings, judge names, and opinion snippets are far more complete there. Dockets mode trades text richness for volume and adds party/attorney/cause data pulled from PACER.

How the source actually works

The scraper connects directly to the CourtListener REST API v4 (courtlistener.com/api/rest/v4/), a free public API maintained by the Free Law Project, a 501(c)(3) nonprofit whose mission is exactly this: making US court data programmatically accessible. There are no credentials and no rate-limit wall for standard usage.

A single mode parameter routes between three surfaces:

• opinions — full-text search across 4M+ opinions using CourtListener’s relevance engine (a BM25-based search). Returns case names, citations, judges, filed dates, docket numbers, snippets, and download links.
• dockets — keyword search across PACER-sourced federal docket records, with party names, attorneys, cause of action, and jurisdiction type.
• courts — enumerate all ~3,300 courts in the database with jurisdiction type, citation strings, active status, and official URLs.

A typical opinions run, scoped to one circuit and a date window, looks like:

{
  "mode": "opinions",
  "query": "fair use copyright",
  "court": "ca9",
  "dateFrom": "2015-01-01",
  "dateTo": "2024-12-31",
  "maxResults": 500
}

Pagination is automatic: opinions and dockets use the API’s cursor-based paging, courts use page-based. The actor walks the cursors for you until it hits your maxResults. To enumerate courts (useful for finding valid courtId values first), the input is trivial:

{
  "mode": "courts",
  "maxResults": 500
}

The court filter takes a CourtListener court ID. Common ones: scotus (Supreme Court), ca1–ca11 (Circuit Courts of Appeals), cadc (DC Circuit), cafc (Federal Circuit), dcd (DC District). If you’re unsure of a court’s ID, run courts mode first and look it up.

Choosing between opinions and dockets is a genuine tradeoff, not a preference. Dockets mode is the volume play — most legal topics match a large pool of PACER-sourced dockets, so a broad query returns high row counts fast. Opinions mode is the depth play — the citation strings, judge names, and opinion snippets are far more complete there, at the cost of a narrower result universe. If you’re building a citation graph or doing judge analytics, opinions; if you’re mapping where a kind of case gets filed, dockets.

▶ Open the CourtListener Scraper on Apify — one run turns a legal query into hundreds or thousands of structured opinion or docket rows with citations, judges and case names. No key, no login. Export to CSV, JSON or Excel.

The access reality

CourtListener’s API is open by design, so the constraints are about result caps and search behavior rather than anti-bot defenses:

• No key, no login, no rate wall. The v4 API is fully public and keyless for standard usage. You only need an Apify account to run the actor.
• 5,000 results per run. The actor caps at 5,000 records per run. For a larger dataset — say, a decade of a busy court — split your date range into yearly windows and run it repeatedly, then merge.
• Throughput is API-bound. The actor processes roughly 20 records per API request. A 200-opinion run finishes in about 30–60 seconds; 1,000+ results can take 3–5 minutes depending on CourtListener’s server response times.
• Proxy is optional. Datacenter proxy is included for reliability, but basic usage needs no rotation.
• The search is BM25-based. It works best with real legal terminology. Overly specific or misspelled queries return zero results — broaden the terms or verify the courtId if a search comes back empty.

Example output

One opinions-mode record:

{
  "caseName": "Authors Guild v. Google, Inc.",
  "caseNameFull": "AUTHORS GUILD v. GOOGLE, INC.",
  "court": "Court of Appeals for the Second Circuit",
  "courtId": "ca2",
  "dateFiled": "2015-10-16",
  "docketNumber": "13-4829-cv",
  "citation": "804 F.3d 202",
  "judge": "Leval",
  "status": "Published",
  "snippet": "Google has made digital copies of tens of millions of books...",
  "url": "https://www.courtlistener.com/opinion/3137282/authors-guild-v-google-inc/",
  "clusterId": "3137282",
  "docketId": "4879456",
  "type": "opinion"
}

Typical use cases

• Legal research & scholarship — collect every Supreme Court opinion mentioning a doctrine since a given year for citation analysis or computational-law studies.
• Litigation intelligence — pull copyright or antitrust dockets from federal district courts to map litigation hotspots by jurisdiction.
• Judge analytics — build a judge-opinion database to analyze how specific judges rule on a given subject matter.
• LegalTech / AI — assemble structured opinion data to train legal models, build outcome predictors, or power a legal document search product.
• Risk & compliance — extract bankruptcy or enforcement dockets in a district for financial-risk monitoring.
• Jurisdiction tooling — enumerate all active courts to build a court-ID reference or jurisdiction lookup inside a legal SaaS.

A concrete example of the depth on offer: you can collect every Supreme Court opinion mentioning a specific doctrine since a given year, complete with citation strings and authoring judges, in a single scoped run — the kind of dataset that would take days to assemble by hand from a court website’s one-case-at-a-time search.

Build it yourself vs. use the actor

CourtListener’s API is free and well-documented, so a first script is easy. The maintenance is in the details: cursor pagination that differs by endpoint, mode-specific field mapping (opinions, dockets, and courts return different shapes), the 5,000-cap chunking logic, and normalizing partial records where older opinions lack citations or judge names. You’d own all of that.

The actor is that logic, packaged. Pricing is pay-per-result — a small fraction of a cent per record plus a negligible start fee — and the CourtListener data is free. For a 500-opinion pull that’s a trivial cost, and the multi-mode paging is already handled.

Common pitfalls

Specific gotchas with CourtListener data:

• Opinions vs dockets are different objects. Opinions are the written decisions (legal reasoning, rulings, citations). Dockets are procedural records (filings, parties, attorneys, status) and may carry no opinion text. Pick the mode that matches what you actually need.
• Partial records are expected. Not every opinion has a citation, a downloadUrl, or a named judge — older opinions and some state records are incomplete. The actor returns whatever CourtListener has; empty fields are data gaps, not errors.
• Quote your phrases. Multi-word legal concepts like "reasonable expectation of privacy" return far more relevant hits when quoted than as loose keywords.
• Validate court IDs. A wrong courtId silently narrows to nothing. Run courts mode to confirm the exact code before scoping a big query.
• Date filters both speed and shape results. Narrowing to a 2–3 year window with dateFrom/dateTo returns faster and more precisely — and is how you stay under the 5,000-per-run cap on high-volume topics.
• Freshness lag. CourtListener syncs federal courts daily via automated scrapers and PACER sync, but the data typically runs 1–3 days behind real-time filings. Don’t expect same-day coverage.

Wrapping up

Case law is public, but the tooling around it is built for reading, not for datasets. CourtListener’s API closes that gap, and if you need a one-off pull the endpoint is open and worth scripting against. If you need refreshed opinion or docket feeds on a schedule — monitoring new filings on a topic, building a citation corpus — let the actor own the cursor pagination, mode routing, and 5,000-cap chunking and hand you clean rows.

▶ Run the CourtListener Scraper on Apify — reads the Free Law Project’s public API directly across opinions, dockets and courts: case names, citations, judges, docket numbers and document links. No API key, no login. Start on Apify’s free monthly credit.