Executive Summary: This court records API integration quickstart walks an engineering team through a working Court Records lookup in about thirty minutes, from API key to a parsed callback that maps to a risk rule. Court records like judgments and liens are public-record signals that affect recovery and adverse-information review, so lenders increasingly pull them into automated diligence.[1][3] The build below uses Cobalt's asynchronous callback model and a no-credit test jurisdiction so you can dry-run before spending anything.
What do you need before you start?
What credentials and scope apply?
You need a Cobalt API key, sent in the `x-api-key` header on every request, and a publicly reachable HTTPS endpoint to receive the callback. The base URL is `https://apigateway.cobaltintelligence.com`. Court Records is asynchronous: there is no synchronous response body, so a callback endpoint is required, not optional.
What does the API actually cover?
Coverage is New York State and Miami-Dade County, Florida only. Search is by `businessName`. Plan your integration around that scope from the start so you do not promise nationwide litigation screening the API cannot deliver.
Treat the test jurisdictions as your default during development. They return realistic mock data without consuming credits, so you can build and debug the full path before a single billed call.
How do you make the first call?
What is the minimal request?
The endpoint is `GET /courtCases`. Three parameters are required: `businessName`, `jurisdiction`, and `callbackUrl`. Use `testNewYork` as the jurisdiction for a no-credit dry run that returns mock data.
curl --location 'https://apigateway.cobaltintelligence.com/courtCases?businessName=Acme%20Corp&jurisdiction=testNewYork&callbackUrl=https%3A%2F%2Fyour-endpoint.example.com%2Fcobalt-callback' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'What jurisdiction values are valid?
The `jurisdiction` parameter accepts exactly four values. Anything else is rejected.
| jurisdiction value | What it does | Credits |
|---|---|---|
| `testNewYork` | Mock New York data for dry runs | 0 |
| `testMiamiDade` | Mock Miami-Dade data for dry runs | 0 |
| `newYork` | Live New York State court search | 1 |
| `miamiDade` | Live Miami-Dade County, FL search | 1 |
How do you build the callback endpoint?
What should the receiver do?
The acknowledgement request returns quickly, then Cobalt posts the result to your `callbackUrl`, typically within 30 to 120 seconds. Your endpoint should accept the POST, persist the raw body immediately, and return a fast 2xx so the delivery is not retried unnecessarily. Do the parsing after you have stored the payload.
from flask import Flask, request
app = Flask(__name__)
@app.route("/cobalt-callback", methods=["POST"])
def cobalt_callback():
payload = request.get_json(force=True)
store_raw(payload) # persist before parsing
findings = parse_cases(payload)
apply_risk_rule(findings)
return "", 200How should you secure the receiver?
Securing the receiving endpoint is the lender's responsibility, since it lives in your infrastructure. As a general best practice, terminate TLS, restrict the route, and validate that incoming payloads have the shape you expect before acting on them. Cobalt has not documented a specific webhook signing secret for this endpoint, so do not assume one. Treat verification as your endpoint's job.
How do you parse the returned fields?
Which fields come back?
The callback carries judgment details such as type and status, case information including case number, case type, and court division, filing dates, the plaintiff and defendant names, and judgment amounts where the record provides them. Amounts are not always present, so guard for missing values rather than defaulting them to zero.
How do you map fields to a decision input?
Reduce the raw cases to a few decision-ready fields: a count of matched cases, whether any judgment is a fraud or misrepresentation type, the most recent filing date, and the largest available amount. Those four are usually enough to drive a first routing rule. Keep the parsing defensive. Court-record completeness depends on what each court system makes electronically available, so older cases or certain case types can be absent, and a quiet result is not proof that no litigation exists. Normalize names and dates as you parse, and keep the raw payload alongside the parsed fields so a later reviewer can confirm what the record actually said. Storing both the raw and parsed forms is also what lets you reprocess old callbacks if your rules change, without re-spending credits on the same lookup.
How do you connect a finding to a risk rule?
What does a simple rule look like?
A first rule can be plain. Zero matched cases continues the file. One old civil matter continues with a note. A fraud-type judgment, or several recent cases, routes the file to manual review before approval. Cobalt provides the data; your team owns the accept, condition, or decline decision. If a court record informs a credit decision, federal rules govern its use: the FCRA generally bars reporting judgments older than seven years or the governing statute-of-limitations period, whichever is longer,[4] and users must keep reasonable written accuracy policies.[6] Keep the threshold values in config rather than hardcoded so policy can tune them without a code change, and log the rule that fired with each disposition so the path stays auditable.
def apply_risk_rule(findings):
if findings["fraud_judgment"]:
return route("manual_review", reason="fraud-type judgment")
if findings["case_count"] >= 3:
return route("manual_review", reason="dense litigation")
return route("continue", reason="no adverse court signal")Where does this sit in the broader stack?
Court review pairs with entity verification, identity matching, and sanctions screening. For how court-record diligence relates to sanctions obligations, see BSA/AML for Alternative Lenders: OFAC's Role, and for pre-funding lien context see Pre-Funding UCC Lien Search: Underwriter Workflow.
How do you handle coverage limits in code?
What should happen outside the two jurisdictions?
Because coverage is New York and Miami-Dade only, with Florida records accessed through county clerks of court,[5] any business elsewhere should route to a fallback litigation process, not auto-clear. Encode that explicitly so a missing jurisdiction is a routing branch, not a silent pass. State courts span thousands of venues, so no single feed is comprehensive.[2]
What goes live versus test?
Keep `testNewYork` and `testMiamiDade` wired into your integration tests so regressions never spend credits. Switch to `newYork` and `miamiDade` only in the live path, behind a clear environment flag. A useful safeguard is to fail the build if a test suite ever resolves to a live jurisdiction, so a misconfigured environment cannot quietly start billing. Treat the test jurisdictions as a permanent fixture of your continuous-integration setup, not a one-time step during the initial build, since every future change to the parsing or routing logic should run against mock data before it ever touches the live endpoint.
How can a team get an API key to start?
Once your callback endpoint is sketched, the next step is a key and access to the test jurisdictions so you can run the dry-run path end to end. You can request access and review the supported coverage on a Cobalt Intelligence demo.
.jpg){kind=small}
.png)