US Federal Court Cases Scraper

US Federal Court Cases Scraper - CourtListener Docket Search API

Search US federal court dockets and get one row back per case: the caption, the court, the docket number, the date it was filed, the nature of suit, the cause of action, the judge it is assigned to, the parties, their counsel and a link straight to the docket. No PACER account, no API key, no login, no browser.

Read this first: it returns the case index, not the filings. You get the docket record: who is suing whom, in which court, under which statute, on what date. You do not get the complaint, the motions, the opinions or any PDF; that half of CourtListener needs an account key, and this Actor does not hold one. If what you need is the text of a filing, this is the wrong tool and it is better you know now.

• Federal courts. District, bankruptcy and appellate dockets that have reached CourtListener; state trial courts are not in here.
• Filter by court, filing date window, nature-of-suit code, cause of action, case name, docket number, party, attorney or assigned judge, or combine them.
• Every filter is checked against the rows that come back before you are charged. A value the search quietly ignores gets caught instead of billed.
• Results arrive 20 at a time behind a rate limit on the source, so budget about a minute per 100 cases. The run paces itself rather than hammering a free public service.
• Run it with empty input and you get a labelled sample row, free, so you can see the shape first.

Price

$0.50 per 1,000 cases, plus a $0.0005 start fee per run.

This is a flat rate on every plan, free or paid. There are no volume tiers, no minimum spend, no subscription and no add-on fees. What you read here is what you pay on day one and on day four hundred.

A single run returns at most 2,000 cases, so those are the figures in the table. Larger jobs are several runs, and each run carries its own start fee.

What is actually charged

• One case-scraped event per case row written to the dataset. Nothing else is metered per row.
• Free: the sample row an empty run returns, and every diagnostic row: a blocked target, a dead URL, a search that matched nothing. Those rows all carry "charged": false.
• Cases already returned earlier in the same run are skipped before they are charged.
• Rows that came back not matching your filters are dropped, not billed, and you get a diagnostic row saying how many and why.
• Time spent waiting out the source's rate limit is not billed to you in any way; it costs wall clock, not events.
• A run that finds nothing costs the start fee and nothing more.
• Rows never leave the dataset without a charge, and are never charged without a row.

Input

{
  "searchTerms": [
    "\"artificial intelligence\" copyright"
  ],
  "courts": [
    "mad",
    "cand",
    "nysd"
  ],
  "natureOfSuit": [
    "820"
  ],
  "filedAfter": "2026-01-01",
  "maxItems": 100
}

Run it with empty input and you get one clearly labelled sample row, free, so you can see the output shape before you spend anything.

Output

One row per case. A real row from a real run:

{
  "ok": true,
  "charged": true,
  "recordType": "case",
  "docketId": 74812464,
  "caseName": "UMG Recordings, Inc. v. Suno, Inc.",
  "caseNameFull": null,
  "court": "District Court, D. Massachusetts",
  "courtId": "mad",
  "courtCitation": "D. Mass.",
  "docketNumber": "1:26-cv-14275",
  "dateFiled": "2026-09-18",
  "dateTerminated": null,
  "dateArgued": null,
  "natureOfSuit": "820 Copyright",
  "natureOfSuitCode": "820",
  "cause": "17:101 Copyright Infringement",
  "jurisdictionType": "Federal Question",
  "juryDemand": "Plaintiff",
  "assignedJudge": "F. Dennis Saylor IV",
  "referredJudge": null,
  "parties": [
    "UMG Recordings, Inc.",
    "Ultra Records, LLC",
    "Capitol Records, LLC",
    "Suno, Inc.",
    "Arista Music",
    "Volcano Entertainment III, LLC",
    "Sony Music Entertainment",
    "Arista Records, LLC",
    "Zomba Recording LLC",
    "John Does 1-10",
    "Sony Music Entertainment US Latin, LLC",
    "Alamo Records, LLC",
    "Records Label, LLC",
    "LaFace Records, LLC"
  ],
  "partyCount": 14,
  "lawFirms": [],
  "attorneys": [
    "Daniel J. Cloherty",
    "Alexandra Arnold"
  ],
  "bankruptcyChapter": null,
  "pacerCaseId": "306399",
  "docketUrl": "https://www.courtlistener.com/docket/74812464/umg-recordings-inc-v-suno-inc/",
  "addedToCourtListener": "2026-09-18T15:08:42.969152Z",
  "scrapedAt": "2026-09-20T11:42:18.905Z"
}

Field notes

• caseName: the short caption the court uses. caseNameFull carries the long form where one exists, and is null on most dockets.
• courtId: CourtListener's own short code for the court, and the value you pass back in courts. court is the full name and courtCitation the Bluebook abbreviation, so you can label a chart without a lookup table.
• docketNumber: as the court writes it. Not unique on its own: 1:26-cv-14275 exists in several districts and in several years. docketId is the stable key.
• dateFiled: when the case was filed with the court. addedToCourtListener is when the record reached CourtListener, which for a new filing is usually within a day or two and for an old one can be years later. Do not use the second as if it were the first.
• dateTerminated: when the case closed. Null means open, or means nobody has recorded a closing date yet. Those two look the same from outside.
• natureOfSuit: the civil cover sheet classification, e.g. 820 Copyright. natureOfSuitCode is just the number, for grouping. Both are null on a lot of criminal and bankruptcy dockets, where the field does not apply.
• cause: the statute and section as typed into the docket, e.g. 17:101 Copyright Infringement. It is clerk-entered free text, so spelling and punctuation vary between districts.
• assignedJudge: the district judge the case sits with. referredJudge is the magistrate it was referred to, and is usually null.
• parties: every party the docket names, in the order the source lists them. Plaintiffs and defendants are not separated, because the index does not say which is which. partyCount saves you a length call.
• attorneys: counsel of record. lawFirms is their firms. Both are often empty: the index only carries them once an appearance has been entered.
• bankruptcyChapter: 7, 11, 13 and so on, on bankruptcy dockets. Null everywhere else.
• pacerCaseId: the court's own internal PACER id. Useful if you are reconciling against a PACER export; meaningless otherwise.
• docketUrl: the docket page on CourtListener. It is the public page, so you can open it and read the entry list for yourself.

Every real row carries "charged": true. Sample rows carry "_sample": true and diagnostic rows carry "_diagnostic": true with an errorCode you can filter on, and neither is ever billed.

How it works

• It calls CourtListener's public search service directly and follows its cursor through the result set. No key, no cookie, no session and no browser. That part of the service answers anyone who asks properly.
• One row per case. The search can also return individual filings nested inside each case, which triples the payload and mixes two different things in one table, so that mode is deliberately not used.
• Results come back 20 at a time and the service rate-limits anonymous callers. When it asks the run to wait, the run reads the number of seconds out of the reply and waits exactly that long rather than guessing. Between pages it keeps a steady pace so the limit is usually not reached at all.
• Every row is checked against what you asked for before it is charged. This matters more than it sounds: the search silently ignores a parameter it does not recognise and answers with the entire index at HTTP 200. Without the check, one wrong code in the input would bill you for hundreds of thousands of unrelated dockets.
• If an entire page comes back not matching your filters, that is the search ignoring a filter rather than a narrow result. The run stops that query, tells you which value looks wrong, and charges nothing for it.

What people use it for

• Tracking a wave of litigation while it happens: every new copyright case filed against an AI company this quarter, by nature-of-suit code and filing date, refreshed on a schedule.
• Watching one company's federal docket, so a new suit shows up the day it is filed instead of the week somebody notices.
• Counting rather than reading: how many patent cases went to the Western District of Texas last year against the Northern District of California, as a table you can chart.
• Building a case list for a practice area: every Fair Labor Standards Act case in a set of districts over a date window, with the judge and the counsel already in columns.
• Feeding a dashboard or a database. The rows are flat, the dates are ISO, and the docket id is stable, so yesterday's pull diffs against today's without any cleaning.
• Journalists and researchers who want the filing record as a spreadsheet instead of a search box that will not let them export.

What this does not do

Worth reading before you buy, because these are the things people assume.

• The index, not the documents. You get the docket record. You do not get the complaint, the motions, the orders, the opinions, the docket entry list or any PDF. Those endpoints need an account key and this Actor does not hold one, will not ask you for one, and does not fall back to one. A case index and a case reader are different products at different prices.
• Federal, not state. District, bankruptcy and appellate dockets that have reached CourtListener. A county or state trial court case is not in here, and neither is anything that has not been pulled into the public database yet.
• Not every federal case. The database is built from what has been fetched from PACER, so coverage is deep in busy districts and busy case types and patchier elsewhere. A missing case means "not in the source", never "does not exist".
• No profiles of people. This is a case index and it stays one. It does not join a name to any other source, does not enrich anybody, does not build a history for a party or a lawyer, and does not emit the internal person ids that would let you do it in one join. Names are published exactly as the court published them and nothing is added.
• No judgement about the case. No outcome prediction, no risk score, no summary, no sentiment. It returns what the clerk entered.
• No sealed or restricted material, obviously. None of that is in the public database in the first place.
• It is not fast. The source rate-limits anonymous callers and the run respects that. A thousand cases is about ten minutes of wall clock. If you need a million rows this afternoon, this is the wrong shape of tool.

About the names in these rows

Court dockets are public records and they name real people: parties, sometimes in bankruptcy or family matters, and counsel. That is a genuine responsibility, so here is exactly what this Actor does with it.

It republishes the docket as the court published it, and stops there. Party names, attorney names and the assigned judge come through unchanged because they are the case. Without them a docket row is not a docket row. What it will not do is turn that into a dossier: there is no enrichment, no joining to any other dataset, no cross-run accumulation, and the internal person identifiers that the source attaches to every party and attorney are deliberately dropped before the row is written. Those ids are the join key that turns a case index into a person index, and the case-level job does not need them.

Fields that tend to carry sensitive personal detail are not emitted either. The output is case metadata: who, which court, which statute, which dates.

What you do with the rows afterwards is on you. If you are building anything that makes decisions about an individual, a docket index is a poor basis for it: names collide, records go stale, a case being filed says nothing about whether it had merit, and a terminated case says nothing about who won.

Reading the output

Every run writes three kinds of row and they are easy to tell apart:

• Real rows carry "charged": true and "recordType": "case". One billed event each.
• The sample row carries "_sample": true and "charged": false. There is exactly one, it only appears when the input had nothing to search for, and it is there so you can see the shape before you spend anything.
• Diagnostic rows carry "_diagnostic": true, "charged": false and an errorCode worth switching on: NO_RESULTS when a search ran fine and matched nothing, BAD_INPUT when rows came back that did not match your filters or when a part of the source refused the request, NETWORK when the service could not be reached at all, TIME_BUDGET when the run ran out of time before a search.

The difference between NO_RESULTS and NETWORK is the one that matters: the first means there is genuinely nothing there, the second means nobody looked. Neither is charged, and confusing them is how somebody concludes a company has never been sued when the service was simply down.

If you only want data, filter on charged == true. The count of those rows always equals the number of events you were billed for, so the dataset is its own invoice.

Limitations

• The case index only. Filings, opinions, orders, docket entries and PDFs are not returned. Those parts of the source require an account key this Actor does not use.
• Federal courts only. State and county trial courts are not covered.
• Coverage follows what has been pulled into the public database from PACER. It is deep in busy districts and busy case types and thinner elsewhere, so an absent case means "not in the source", not "does not exist".
• Results are paged 20 at a time and the source rate-limits anonymous callers. Expect roughly a minute per 100 cases; the hard ceiling is 2,000 cases in one run.
• Nature of suit and cause are null on many criminal and bankruptcy dockets, where the civil cover sheet does not apply.
• Attorneys and law firms are empty on plenty of cases, because the index only carries counsel once an appearance has been entered.
• dateTerminated being null means either the case is open or nobody recorded a closing date. Those two are indistinguishable from outside.
• Cause of action is clerk-entered free text and the wording varies between districts, so filter on a substring rather than an exact phrase.
• Docket numbers repeat across courts and across years. Pair one with a court id if you want a single case.
• Person ids are deliberately not emitted, so you cannot pivot from a case to a party's full litigation history. That is on purpose, not an oversight.
• The data is only as current as the source. A docket that has not been refreshed there will repeat its stale terminated date faithfully.
• A search term is full-text, not a boolean query language. Quote a phrase to hold it together; there are no AND/OR/NOT operators.

Questions

Do I need a PACER account or a CourtListener API key?

No. The search this reads is open to anyone, and the Actor holds no account, no login and no cookie for it. It will never ask you for a key either. If it needed one, the honest thing would be to say so rather than quietly using somebody else's.

Can I get the actual complaint or the judge's opinion?

Not from this Actor. Those live behind endpoints that require an account key, and this returns the case index instead: who, which court, which statute, which dates, plus a link to the public docket page where you can read the entry list yourself. A case index and a document reader are genuinely different products and pretending otherwise would be selling you the wrong one.

Does it cover state courts?

No. Federal district, bankruptcy and appellate dockets only. State and county trial court records are published on hundreds of separate portals and none of them is in here.

I searched for a judge and got cases from other judges. Why?

You will not, and that is the point. The search has a parameter that looks like the obvious one for a judge, returns HTTP 200, and hands back the entire index instead of filtering. It was measured returning 903,887 unrelated dockets. This Actor does not send that parameter, sends the one that actually works, and then checks every row against the name you asked for before charging you. If something slips through it is dropped and reported, not billed.

Why is it slower than other scrapers?

Because the source rate-limits anonymous callers, and the run respects that instead of hammering a free public service. When the service asks for a pause it reads the number of seconds out of the reply and waits exactly that long. You are not billed for the waiting. It costs wall clock, not events.

What happens if my search matches nothing?

You get one uncharged diagnostic row with errorCode: "NO_RESULTS" and the run finishes as succeeded. You are never billed for a search that returned nothing.

Can I run this on a schedule?

Yes, and it is a good fit for one. Nothing is held between runs. Pair a daily schedule with filedAfter set to yesterday and you pick up only new filings; docketId is a stable key, so diffing today against yesterday is trivial.

Will the run fail if the source is down?

No. You get an uncharged diagnostic row saying the service could not be reached, and the run still finishes as succeeded. A failed run would still bill the start fee, which would mean paying to be told something was broken.

Are the party names real people?

Some of them are, yes. A docket names whoever is in the case. They come through exactly as the court published them and nothing is added: no enrichment, no joining to other sources, no history built up, and the internal person ids that would let you do that in one step are dropped on purpose. There is a section above on this worth reading if you are building anything that touches individuals.

How far back does it go?

As far back as the public database does, which for many districts is the 1990s and for some is much more recent. Set filedBefore and see: a search for cases filed before 2005 returns tens of thousands, so there is real depth, it is just uneven by court.