Executive Summary: Designing court case webhook lender alerts starts with one fact about Cobalt's Court Case API: it is asynchronous. The lender supplies a callback URL, Cobalt posts the court-case result to that endpoint when the search completes, and the lender's own system decides when a returned judgment crosses a threshold worth alerting on. Court judgments are public-record signals that can attach to a debtor's property, which is why lenders fold them into automated diligence.[1][3] This guide shows how to build the receiving webhook and the alert logic honestly, without assuming a monitoring product the API does not offer.
Why is the Court Case API a webhook pattern?
What does asynchronous callback mean here?
The endpoint is `GET /courtCases`, and it does not return court data in the response body. Every request requires a `businessName`, a `jurisdiction`, and a `callbackUrl`. The initial call acknowledges quickly, then Cobalt posts the result to your callback URL when the search finishes, usually within 30 to 120 seconds. The webhook in this post is your receiving endpoint that accepts that callback.
Who owns the alert, Cobalt or the lender?
The lender owns it. Cobalt provides the court-case data on a single requested lookup. The alert, meaning the rule that decides a new judgment or an amount over a threshold deserves attention, lives entirely in the lender's system. Cobalt does not run continuous monitoring or push notifications, so the alerting logic is yours to build.
The practical question is not whether a vendor watches the entity for you. The question is what your endpoint does the moment a court-case payload arrives, and which findings your own rules escalate.
How do you call the API and receive the result?
What does the request look like?
Send the request with your API key in the `x-api-key` header against the base URL `https://apigateway.cobaltintelligence.com`. Use `testNewYork` for a no-credit dry run that returns mock data while you build the receiver.
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 jurisdictions are valid?
The `jurisdiction` parameter accepts exactly four values, and coverage is New York State and Miami-Dade County, Florida only. Search is by `businessName`.
| jurisdiction value | Purpose | Credits |
|---|---|---|
| `testNewYork` | Mock New York data for building the webhook | 0 |
| `testMiamiDade` | Mock Miami-Dade data for building the webhook | 0 |
| `newYork` | Live New York State court search | 1 |
| `miamiDade` | Live Miami-Dade County, FL search | 1 |
How should the receiving endpoint behave?
What does a safe handler do first?
The handler should accept the POST, persist the raw payload before parsing, and return a fast 2xx so delivery is not retried unnecessarily. Parse and evaluate alert rules after the payload is stored, ideally on a queue, so a slow rule never blocks acknowledgement.
from flask import Flask, request
app = Flask(__name__)
@app.route("/cobalt-callback", methods=["POST"])
def cobalt_callback():
payload = request.get_json(force=True)
if not valid_shape(payload): # lender-side payload validation
return "", 400
store_raw(payload) # persist before any rule runs
enqueue_for_alerting(payload) # evaluate thresholds off the hot path
return "", 200How do you handle duplicate or replayed deliveries?
Make the endpoint idempotent. Key each stored result on a stable identifier such as the request you issued plus the returned case number, so a repeated delivery updates rather than double-alerts. Idempotency is a property of your receiver, not something the API guarantees for you.
How do you secure the lender webhook?
What is the lender responsible for?
Because the endpoint lives in your infrastructure, securing it is your job. As general best practice, terminate TLS, restrict the route to expected callers where you can, authenticate the path with a hard-to-guess token in the URL or a header you control, and validate that every payload has the shape you expect before acting on it.
Does Cobalt sign the callback?
Cobalt has not documented a signing secret, HMAC header, or retry-and-backoff policy for this endpoint. Do not assume one exists. Treat verification, replay handling, and retry tolerance as responsibilities of your receiving endpoint, and design defensively rather than relying on an undocumented guarantee.
How do you turn a payload into an internal alert?
Which fields drive the rule?
The callback carries judgment details such as type and status, case information including case number 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 treating absent as zero.
What does a first alert rule look like?
Reduce the payload to a few decision fields, then alert your own team when a rule fires. A new fraud-type judgment, or any judgment whose amount exceeds your threshold, raises an internal alert; everything else is logged. If an alert feeds a credit decision, federal rules apply: the FCRA generally bars using 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] For how this diligence sits beside lien checks, see Pre-Funding UCC Lien Search: Underwriter Workflow.
def evaluate_alert(findings, threshold):
if findings["fraud_judgment"]:
return raise_alert("fraud-type judgment found")
amt = findings.get("max_amount")
if amt is not None and amt > threshold:
return raise_alert(f"judgment amount {amt} over threshold")
return log_only("no alert-worthy court signal")How do you handle ongoing checks and coverage limits?
Can Cobalt monitor an entity over time?
No. There is no documented continuous court-monitoring, re-checking, or push-alert product. If you want periodic re-checks, your system schedules repeat `/courtCases` calls on a cadence you control and compares each result against the last. The scheduling and the change detection are yours; each call is a fresh one-credit lookup.
What happens outside the covered jurisdictions?
Coverage is New York and Miami-Dade only, with Florida records accessed through the county clerks of court,[5] so any business elsewhere must route to a fallback litigation process, not auto-clear. State courts span thousands of separate venues, which is why no single feed reaches all of them.[2] For how court diligence connects to sanctions obligations, see BSA/AML for Alternative Lenders: OFAC's Role.
How can a lender stand up this webhook?
The practical first step is to point a test callback endpoint at the test jurisdictions and confirm your handler stores, validates, and alerts on a mock payload before any live call. You can request access and review the supported coverage on a Cobalt Intelligence demo.
.jpg){kind=small}
.png)