Court Case API: Slash Underwriting Risk in Seconds (2026)

Executive Summary: A court case API exposes the litigation history that traditional KYB workflows miss: civil judgments, federal lawsuits, bankruptcy petitions, and state-court complaints filed against a business or its principals. For alternative lenders moving from manual review to real-time decisioning, court records are the single biggest source of unpriced credit risk sitting in plain sight. This guide breaks down what court case APIs actually return, how they fit into a verification waterfall, how the major vendors compare, and the five RFP questions that separate a real data partner from a reseller of stale aggregator data.

Why are court judgments the biggest blind spot in alt-lending due diligence?

Most KYB stacks check four things: secretary of state filings, UCC records, EIN or TIN match, and beneficial ownership. That stack confirms a business exists, knows who owns it, and shows what it has financed. It does not tell you that the same business is being sued for $400,000 in a state court three weeks before the merchant cash advance application landed on your desk.

Bureau credit data, the layer that traditionally absorbed court-record signal, lags filings by 30 to 90 days according to the Federal Reserve's annual Small Business Credit Survey.^[1] For a commercial bank funding a 60-month term loan, that lag is acceptable. For an MCA provider or a working-capital lender approving a 12-month advance the same day, it is the difference between funding a healthy business and funding a defendant.

The blind spot compounds in three ways:

• Speed mismatch. Alt-lenders advertise same-day or next-day funding. Bureau refresh cycles assume monthly tradeline reporting. Court filings hit dockets the day they are filed.

• Coverage gaps. Bureaus aggregate consumer and limited commercial trade data; they do not consistently surface civil judgments against small entities, especially LLCs formed within the last 24 months.

• Counterparty visibility. A business defendant may be the plaintiff in three other suits. Pattern signal lives in the docket itself, not in a credit score.

Underwriting teams that rely on bureau pulls alone are pricing risk on a stale snapshot. A court case API closes that gap by going to the source: the same dockets that PACER and state clerks publish, queried in seconds rather than days.

For alternative lenders specifically, the risk concentration is greater than for traditional banks. Industry coverage in publications like deBanked has consistently tracked stacking and rapid-decline behavior as cycle-driven phenomena, with heightened loss windows concentrated in segments where merchant cash advance products dominate.^[11] The U.S. Small Business Administration's lending data shows that small-business credit demand remains above pre-2020 baselines, which means more applications hitting underwriting queues that have not been re-instrumented for real-time court-records signal.^[12] Looking across commercial litigation in aggregate, the 2025 Annual Litigation Trends Survey from Norton Rose Fulbright reports that mid-market disputes drove a meaningful share of new commercial filings, the same band where alt-lending portfolios concentrate.^[9]

What data does a court case API actually return, and which jurisdictions does it cover?

Court case APIs vary widely in coverage, freshness, and structure, but a serious vendor returns the following fields per matched case:

• Case caption. Plaintiff and defendant names, case number, court of filing.

• Case type. Civil, bankruptcy (Chapter 7, 11, or 13), federal civil, tax court. Criminal data is rare in commercial underwriting feeds and usually excluded by vendor policy.

• Filing date and status. Open, judgment entered, dismissed, settled, on appeal.

• Judgment amount. Where available; parsing accuracy varies by vendor.

• Docket events. Filings, motions, hearings; the rich version of what is happening in the case right now.

• Linked documents. PDF or image links to the complaint, judgment order, or settlement notice, where the source court publishes them.

Jurisdiction coverage is where vendor reality diverges sharply from vendor marketing. The federal system is the easy part: PACER publishes federal civil, criminal, and bankruptcy data through a single national interface.^[2] State coverage is the hard part. The United States has roughly 16,000 trial-court venues spread across 50 states, the District of Columbia, and four territories.^[3] Most state courts publish dockets through county or circuit clerks, each with its own format, fee structure, and refresh cadence.

Practical implications for buyers:

• A vendor claiming "nationwide court coverage" almost always means federal plus a curated list of top states by population.

• State-level depth varies from real-time docket scraping (rare, expensive) to monthly batch ingestion (common).

• Judgment-amount parsing is often the weakest field. Some vendors extract it from docket text; others rely on filer-entered values that may be blank.

• Older records, especially pre-2015 state-court filings, are inconsistent across providers.

The right question for vendor evaluation is not "do you cover X state" but "which states do you refresh daily, which monthly, and what is the average lag between docket filing and your API returning the record."

How does a court case API integrate into a real-time underwriting workflow?

For an alternative lender, the integration pattern is dictated by latency. Court-records APIs split into two architectural camps: synchronous (response within a few seconds, suitable for blocking UI calls) and asynchronous (response via webhook or polling within minutes to hours, suitable for queued workflows).

A typical KYB verification waterfall looks like this:

1. Entity exists. Pull the SOS record. If no match, decline or route to manual review.

2. UCC check. Look for existing secured filings, prior advances, stacking signal.

3. TIN or EIN match. Confirm the tax ID matches the legal name on the application.

4. Court records query. The API call this article is about.

5. Score the decision. Apply your underwriting model; route to auto-approve, manual review, or decline.

The question of where to place the court-records call inside that waterfall depends on its latency profile. If your court-records vendor responds synchronously in under three seconds for the jurisdictions you care about, slot the call in step 4 and let the model consume it like any other feature. If the vendor is async-only, your architecture has to absorb that:

// async court records pattern
POST /court-records/lookup
{
  "ein": "12-3456789",
  "legal_name": "Acme Industrial LLC",
  "principals": ["John Smith", "Jane Doe"],
  "jurisdictions": ["federal", "TX", "FL"],
  "callback_url": "https://underwriting.lender.com/callbacks/court"
}

-> 202 Accepted
   { "request_id": "req_8k4j2", "expected_completion": "2026-05-13T17:42:00Z" }

// callback fires when results are ready
POST https://underwriting.lender.com/callbacks/court
{
  "request_id": "req_8k4j2",
  "matches": [...],
  "completed_at": "2026-05-13T17:39:14Z"
}

Async-only delivery is not a defect; it reflects the underlying reality that state-court ingestion sometimes requires multiple upstream lookups. What matters operationally is whether your decisioning workflow can wait. Most alt-lenders run a two-track flow: the SOS and UCC results gate the soft approval, court records get appended when they land, and any auto-approved deal is held in a 30-minute review queue if a high-severity court match arrives late.

What are the 5 court-record signals that change a credit decision?

Not every court hit moves the needle. A small-claims dispute over a $1,200 invoice is noise; an active $400,000 civil judgment is the entire signal. These five are the ones that move underwriting models in practice:

1. Active civil judgment above $25,000 against the business or a principal. An entered judgment means a creditor has a legal right to collect. Investopedia defines a civil judgment as a court's binding decision after a non-criminal lawsuit, with enforcement mechanisms that include garnishment, asset seizure, and lien attachment.^[10] In practice, an active judgment means a creditor already has the legal apparatus standing by to collect; layering new working capital on top of that priority position is exactly the scenario underwriting teams should pre-screen for. Multiple active judgments compound the risk further: incoming working capital is paid out to existing creditors rather than to your customer's operations.

2. Bankruptcy petition (Chapter 7, 11, or 13) within the last 36 months. Filed against the business or a principal; both matter. Federal bankruptcy filings are well-published through PACER, which makes this signal high-confidence.^[4]

3. Pattern of multiple smaller suits across jurisdictions. A business with eight active or recently dismissed suits, none individually large, is signaling either a litigious operating model or chronic dispute exposure. Pattern beats single-case severity for medium-ticket underwriting.

4. Tax lien filings, federal or state. Federal tax liens often surface in district-court records before they appear in commercial bureau data. State tax liens are even more bureau-blind. Both indicate priority creditor positions that supersede new debt.

5. Mechanic's liens or contractor disputes. Industry-specific signal: for construction, trades, and service businesses, a pattern of mechanic's lien filings against the applicant is a strong leading indicator of cash-flow distress.

None of these signals replaces underwriting judgment; each one is a feature that should be weighted inside your model. The point of integrating a court case API is to make those features available within seconds rather than hours, so the model fires on real data instead of a missing field.

How do Wolters Kluwer, CSC, PACER, and Cobalt approach court records differently?

The court-records market is not a single category. Some vendors are direct sources (the courts themselves and PACER for federal data). Others are bundled compliance and entity-management platforms where court data is one product line. Others are KYB platforms that include court signal as part of a broader entity report. And a smaller group are data-layer specialists that expose verification fields through APIs without bundling decisioning.

Honest positioning. Cobalt is in a separate row because we are not a KYB platform. We are the verification data layer that KYB platforms need as input. The four products above all do something Cobalt does not, which is bundle court data with decisioning, entity management, or compliance workflows. Cobalt does something they generally do not, which is expose verification fields as a low-friction API that lenders own and orchestrate. The honest answer for most VPs of Risk is to pick one of the platforms for the decisioning layer, then plug a data source like Cobalt in for the verification fields the platform does not cover natively. For court records specifically, Cobalt's current coverage is 2 jurisdictions and async-only with a callback contract; if you need broad state coverage on day one, a bundled compliance vendor is the better fit.

What does build-vs-buy look like for court-records integration?

The build-vs-buy conversation for court data is rarely binary. Federal data is straightforward to integrate directly through PACER for any engineering team that can handle XML parsing and a per-page billing model. State data is the part that breaks build plans.

The realistic build path

Federal-only build: 4 to 8 weeks of engineering effort to integrate PACER's API, build a docket parser, handle the per-page fee accounting, and wire results into your underwriting model. Stable, well-documented, low maintenance burden once shipped.

State-coverage build: 6 to 12 months minimum, plus ongoing maintenance. Reasons it goes long:

• Each state's court system publishes data through a different portal, with different access models (some free, some fee-based, some captcha-gated).

• A meaningful chunk of state-level coverage requires scraping, which is legally gray in some jurisdictions and operationally fragile when courts change their site structure.

• Match logic (entity name to docket party) is its own machine-learning problem; off-the-shelf string matching produces unacceptable false-positive rates for high-volume underwriting.

The realistic buy path

An aggregator API trades engineering time for vendor fees and coverage tradeoffs. Per-call pricing is the dominant model for transactional lookups; subscription pricing is common for monitoring-style use cases where you want notifications when a new case is filed against an existing customer.

Hidden costs of buy: vendor lock-in if your model depends on a specific schema, coverage gaps that surface only after you have built downstream logic, and renewal pricing changes that can move your unit economics.

The hybrid path most mature lenders end up at

Federal coverage built directly against PACER for accuracy and cost control on high-volume queries. State coverage purchased from one or two aggregators chosen for the jurisdictions where your portfolio concentrates. The hybrid is more work to maintain than pure-buy, but it removes the single-vendor dependency and gives you direct control over the federal data flow that drives bankruptcy and federal-tax-lien signal.

For a deeper look at how this fits with the rest of your KYB stack, see our guide on the verification waterfall and where each data layer plugs in.

What 5 RFP questions should you ask a court records API vendor?

Generic RFP questions, such as "do you have an audit trail" or "can I run a test query," tell you nothing because every serious vendor answers yes. The questions below are designed to expose the gap between what a vendor sells and what it actually delivers.

1. "For each of my top 10 jurisdictions by portfolio volume, what is the average lag between docket filing and your API returning the record, and which of those jurisdictions are refreshed daily versus monthly?" This question replaces the marketing phrase "nationwide coverage" with a concrete commitment per state. Vendors who cannot answer per-jurisdiction are reselling another aggregator's data and do not control their own refresh cadence.

2. "How do you parse judgment amounts, and what is your accuracy rate on cases where the docket lists the amount in unstructured text rather than a structured field?" Judgment amount is the field that drives the largest weight in most underwriting models. Vendors who rely solely on filer-entered fields are missing 30 to 60 percent of real judgment values, depending on the court.

3. "What is your entity-match logic for distinguishing 'John Smith Industries LLC' from 'John Smith Industries LP' at the same address, and what is your false-positive rate at our volume tier?" Entity match is where most aggregator products break under volume. Ask for the rate at your actual call volume, not the cherry-picked rate from their public case study.

4. "When a new case is filed against a customer I am already monitoring, what is the median time from filing to notification?" Monitoring is a separate product motion from one-shot lookup. The honest answer ranges from minutes (for federal PACER-backed monitoring) to days (for state aggregator-backed monitoring).

5. "Provide a reference from a customer with portfolio volume within 25 percent of mine, in my segment, who is using the same API endpoints I would use." Customer references at the wrong scale are useless. A vendor with three megabank customers may have zero applicable experience for an MCA shop pulling 5,000 lookups per month.

If a vendor cannot answer all five in writing, it is a signal that the data layer is shallower than the sales conversation. Production underwriting deserves better than a demo built on cherry-picked records.