Us court records
Search US litigation and court records against a person or company for free - CourtListener's REST API over PACER/RECAP dockets plus published court opinions, for adverse-history due diligence. Use for US litigation search, lawsuit and court-record checks, and the adverse-history leg of a KYC/AML/KYB workflow. Trigger on: 'US litigation search', 'court records', 'is this company being sued', 'lawsuit history', 'CourtListener', 'PACER RECAP', 'federal court docket', 'adverse history', 'litigation due diligence', 'find lawsuits against'. This is a litigation / adverse-history lane, not a company registry - it finds cases, not entity records; register your own free API token.From its SKILL.md
npx -y skills add Nolpak14/getregdata --skill us-court-recordsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
10.5 KB, ~2.4k tokens by cl100k_base, as published. Nobody here has run it
us-court-records
Search US litigation and court records against a name - the adverse-history leg of a KYC/AML/KYB check. Take the entity and the beneficial owners / directors you extracted from a registry, and look for lawsuits, judgments, and published opinions naming them. This runs on CourtListener, the Free Law Project's open database over PACER/RECAP federal dockets plus millions of court opinions. Free with your own free API token - but read the rate-limit trap below before you plan a bulk screen.
Persona
You are a litigation / due-diligence analyst running the adverse-history lane of a screen. You search customers, counterparties, and their beneficial owners for US court exposure, you understand that a party-name hit is a candidate that must be adjudicated (common names produce false positives - CourtListener does no entity resolution), and you keep litigation history separate from sanctions and from debarment - different data problems that together make one screen.
What this gives you (for free)
- Docket records - litigation matters from PACER via the RECAP archive: case name, court, docket number, date filed, nature of suit, parties, and (where present) attorneys and judge.
- Court opinions - published opinions and their clusters: case name, citation(s), citing count, the deciding court, and opinion text snippets with download URLs.
- People / judges - the judiciary database, for resolving a named judge.
- Cross-links - each result carries an
absolute_urlback to the case on courtlistener.com and, for RECAP items, links to the underlying documents.
This is largely public-domain US court data curated by an open-source non-profit. Reuse is permitted; attribution is expected. Responses are JSON and paginated (count / next / previous).
Authentication (free, but read the rate-limit trap)
- Register a free account at https://www.courtlistener.com and generate a token under Profile -> API tokens.
- Pass it as an HTTP header on every call:
Authorization: Token <your-token>. Anonymous/keyless calls work too but hit stricter limits - always use a token. - The rate limit is the real constraint, not the signup. As of the 2026-05-07 policy change, the free tier is throttled to 5 requests/minute, 50/hour, and 125 requests/DAY. The old 5,000/day allowance is gone for new accounts (accounts with 1,000+ historical requests were grandfathered). Heavy or bulk use needs a paid Free Law Project membership.
export CL_TOKEN=your_courtlistener_api_token
curl -s -H "Authorization: Token $CL_TOKEN" \
"https://www.courtlistener.com/api/rest/v4/search/?q=Acme%20Corporation&type=r"
Plan around the 125/day ceiling. It is fine for interactive, one-off DD checks - screening a handful of names and adjudicating the hits by hand. It is not an engine for bulk screening: at 125 requests/day a list of a few hundred subjects (each needing several paginated calls) will exhaust the quota fast. For volume, budget for a paid membership or fall back to the interactive lane and the composite actor. Cache every response; never re-fetch the same query.
Before starting
Ask the user for whichever is missing:
- The name(s) to search - the entity plus every beneficial owner / director you want checked.
- What they need - a one-off adverse-history check (interactive, well within the free tier), or a volume screen (which the free tier will not sustain - flag the membership requirement early).
API reference
Base URL: https://www.courtlistener.com/api/rest/v4/
| # | Purpose | Method + path |
|---|---|---|
| 1 | Search opinions by party | GET /search/?q={party}&type=o |
| 2 | Search RECAP dockets (with nested docs) by party | GET /search/?q={party}&type=r |
| 3 | Search PACER documents | GET /search/?q={party}&type=rd |
| 4 | Search dockets | GET /search/?q={party}&type=d |
| 5 | List / filter dockets directly | GET /dockets/?... |
| 6 | Resolve a judge / person | GET /people/?... |
type values: o = opinion clusters, r = RECAP dockets (nested documents), rd = PACER documents, d = dockets, p = judges/people, oa = oral arguments.
# 1. Opinions naming a party
curl -s -H "Authorization: Token $CL_TOKEN" \
"https://www.courtlistener.com/api/rest/v4/search/?q=%22Acme%20Corporation%22&type=o"
# 2. RECAP dockets (federal litigation) naming a party
curl -s -H "Authorization: Token $CL_TOKEN" \
"https://www.courtlistener.com/api/rest/v4/search/?q=%22Acme%20Corporation%22&type=r"
Quote a multi-word party name to keep the terms together; CourtListener search is full-text, so an unquoted name matches the words anywhere.
Response fields (live-confirmed)
- Case identity -
caseName/caseNameFull,docketNumber,docket_id,cluster_id. - Court -
court,court_id,court_citation_string. - Dates -
dateFiled,dateArgued. - Citations -
citation,neutralCite,citeCount. - Litigation detail -
suitNature(nature of suit),status,posture,procedural_history,judge,attorney. - Opinions - nested
opinions[]with text snippets, download URLs, and SHA1 hashes. - Navigation -
absolute_url(the case on courtlistener.com),meta(BM25 relevance score), andcount/next/previousfor pagination.
Workflow: search an entity and its owners
1. Build the subject list
-> the entity name + every beneficial owner / director you extracted
(e.g. from CRBR, KRS, Handelsregister, Companies House PSC)
2. Budget the calls against the free tier
-> 125 requests/day, 5/min: a few interactive names is fine
-> a volume screen is not - flag the paid-membership requirement first
3. Search each subject
-> type=r for federal litigation dockets, type=o for opinions
-> quote multi-word names; page through count/next only as far as needed
4. Adjudicate each candidate hit
-> strong name match + corroborating detail (address, industry, related party) -> LIKELY the subject: read the docket, assess the matter
-> common-name match, no corroboration -> likely false positive: document why
-> no results -> no US court exposure found (this run, this database)
5. Record the search: which types, the query date, and the outcome per subject
Output interpretation
- A party-name hit is a candidate, not a verdict. CourtListener matching is fuzzy full-text with no entity resolution and no dedup by identity - common company and personal names collide constantly. Confirm the hit is your party (address, industry, a related name from the registry data) before acting on it. This is the same adjudication discipline as
sanctions-pep-screening; a hit is something to adjudicate, not a result to report raw. - This is a case database, not a company registry. It returns lawsuits and opinions, not entity records - there is no company profile, no officers list, no ownership. Resolve the entity itself with a registry skill first, then bring the confirmed name here.
- Coverage is uneven. Federal PACER/RECAP coverage is strong; state-court coverage is partial and varies by jurisdiction. "No results" means nothing was found in what CourtListener holds - it is not proof of a clean litigation record. Say so when you report a clear result.
- Read the matter, not just the match. Nature of suit, posture, and status tell you whether a hit is a routine contract dispute, a resolved matter, or live high-stakes litigation. A raw count of cases is not a risk finding.
- Litigation is not sanctions and not debarment. A US court hit tells you a party has been in litigation - not that it is sanctioned, and not that it is barred from federal awards. A subject can be clear here and still be sanctioned, a PEP, or debarred. Run those lanes separately.
Cross-sell - the adverse-history lane of a fuller screen
This skill is one lane of an AML / due-diligence screen. Pair it with the sanctions, PEP, and debarment lanes, and wire all of them onto the registry actors: extract the beneficial owners and directors, then run each one across sanctions, debarment, and US court history.
| Lane | Source |
|---|---|
| Sanctions + PEP (OFAC / EU / UK / UN, free) | sanctions-pep-screening |
| US federal debarment / exclusions (free) | sam-gov-exclusions |
| Adverse media over the same subject | regdata/adverse-media-scraper |
| Extract beneficial owners (PL) | regdata/crbr-beneficial-owners-scraper |
| Extract board members (PL) | regdata/krs-fullnames-scraper |
| Extract PSC / officers (UK, free) | companies-house-uk |
For the full workflow - risk scoring, adverse-media overlay, cross-source validation - route to regdata-kyc-aml. The registry actors use a free Apify token: https://apify.com?fpr=getregdata.
Related skills
sanctions-pep-screening- the sanctions and PEP lanes; run alongside this for a fuller adverse screen (sanctions + PEP + debarment + litigation).sam-gov-exclusions- the US federal debarment lane; the natural companion to US court history.regdata-kyc-aml- the full KYC/AML/KYB framework; litigation history is one of its adverse-history risk dimensions.gleif-lei-lookup- resolve an entity's global LEI and its parent/child structure, then search each leg.companies-house-uk- free source for the entity and the people to search.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most legal skills give in ~2.4k tokens
Counted across 234 of the 234 authors here whose files we hold, read 2026-08-07
- Use text operators for text fieldsin 11 of 234, across 6 files
- Consult qualified counsel before usein 11 of 234, across 3 files
- Use PatentSearch API for patent searchesin 10 of 234, across 5 files
- Confirm jurisdiction, employment type, and required clausesin 9 of 234, across 2 files
- Choose a document template and tailor role-specific termsin 9 of 234, across 2 files
- Validate compensation, benefits, and compliance requirementsin 9 of 234, across 2 files
- Add signature, confidentiality, and IP assignment terms as neededin 9 of 234, across 2 files
- Open the implementation playbook for detailed templatesin 9 of 234, across 2 files
- Use TSDR for trademark data retrievalin 9 of 234, across 4 files
- Ask for clarification if required inputs are missingin 8 of 234, across 2 files
- Set the USPTO_API_KEY environment variablein 8 of 234, across 3 files
- Use the uspto-opendata-python library for PEDSin 8 of 234, across 3 files
Said here and by no other author read
- search the entity and all beneficial owners
- use a registered API token
- budget API calls against daily rate limits
- cache every API response
- quote multi-word party names in searches
- adjudicate each candidate hit
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.