Top Court Records APIs Compared for Lenders

Executive Summary: Choosing among the top court records API options for lenders comes down to a few axes that decide whether the data actually helps an underwriter: coverage, search method, latency, integration model, and audit trail.^[1][2] This comparison frames those axes neutrally, then positions Cobalt honestly as a targeted New York and Miami-Dade business-litigation API rather than a nationwide aggregator.

Why does court-data choice matter for lenders?

What problem are lenders solving?

Lenders want to know whether a borrowing business carries open judgments or active litigation before they fund. A docketed money judgment can attach as a lien to property and reorder recovery, so the data feeds directly into risk and pricing.^[3]

Why is one API rarely enough?

The large majority of cases are handled at the state level across thousands of venues, and federal cases live in a separate system.^[1] No single API spans all of it cleanly, so the real question is which mix of coverage, speed, and integration matches your borrower base.

The wrong question is which court API covers everything. The right question is which combination covers where your borrowers actually litigate, with a search method and audit trail your workflow can use.

What are the axes that matter?

Which capabilities should a lender weigh?

Compare options on coverage scope, how the data is searched, how fast results return, how the API integrates, and what audit trail it leaves. Each axis maps to a real underwriting constraint, not a feature checkbox.

How do the main options compare?

How does federal court access fit the picture?

What does PACER provide?

PACER is the federal baseline. It gives access to over a billion documents across federal courts, including civil, criminal, and bankruptcy dockets.^[2] For lenders who need federal litigation or bankruptcy history, PACER-based access is the relevant route.

Where does it fall short for some lenders?

Federal coverage misses the state-court matters where most small-business litigation actually sits.^[1] A lender screening MCA or alt-lending borrowers will find that many relevant judgments are state, not federal, which is why federal-only access is a partial answer for that ICP.

How do broad national aggregators compare?

What is the appeal?

National aggregators promise wide coverage across many state and federal venues from one integration. For a lender with borrowers spread across the country, that breadth has clear value.

What should a lender check?

Breadth often comes with uneven depth and freshness across venues, because court systems publish different data in different ways and on different schedules. State court records depend on what each system makes electronically accessible.^[4][5] Verify depth and recency for the specific venues your borrowers use rather than trusting a coverage map.

Where does Cobalt fit honestly?

What is Cobalt's real scope?

Cobalt's Court Records API is targeted, not nationwide. It covers New York State and Miami-Dade County, Florida only, searches by business name, and returns results asynchronously through a callback. It does not query PACER, federal courts, or bankruptcy records, and it does not cover other states.

curl --location 'https://apigateway.cobaltintelligence.com/courtCases?businessName=Sample%20Business%20LLC&jurisdiction=newYork&callbackUrl=https%3A%2F%2Fyour-app.com%2Fcobalt-callback' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'

Why is targeted coverage a real advantage for the right lender?

New York and Miami-Dade concentrate a large share of alt-lending and MCA activity. A lender whose borrowers cluster there gets direct business-litigation data, a single credit pool shared with Cobalt's other lookups, and structured judgment, case, date, and party fields for the audit trail. The data points returned include judgment details, case information, filing dates, parties, and amounts where available. For the lien side of the same diligence, see the pre-funding UCC lien search underwriter workflow.

How should a lender combine sources without overreach?

What does a layered approach look like?

Use targeted state coverage where your borrowers concentrate, add federal or broad national access where you need reach, and write explicit fallback logic for venues no source covers. Cobalt is a data source, not a decisioning engine, so the routing rules and thresholds stay with the lender.

Why must unsupported venues be explicit?

A venue your sources do not cover is not a clean result. The workflow should say clean supported search, risky supported search, or unsupported venue requiring fallback. Court and judgment data used in decisions also carries FCRA care, since civil judgments older than seven years are restricted from consumer reports.^[6] For the AML and sanctions layer, see BSA/AML for alternative lenders and OFAC's role.

What selection checklist should teams use?

What should the evaluation cover?

1. Map where your borrowers actually operate and litigate.

2. Match coverage scope to that map, federal, broad, or targeted.

3. Confirm the search method fits your intake data.

4. Test latency against your funding timeline.

5. Check the integration model and audit-trail fields.

6. Write explicit fallback logic for uncovered venues.

7. Set decision thresholds in your own policy, with counsel on FCRA limits.

How can a lender evaluate Cobalt against this list?

Match the axes above to where your borrowers actually litigate, and if New York and Miami-Dade carry weight in your book, test the targeted lookup directly. To run the call against your own business names and see the returned fields, book a Cobalt demo.