This guide covers how Baselayer's Docket Search product works: what it searches, how results are structured, and what each field in the response means.

For background on litigation types, bankruptcy proceedings, and court terminology, see Litigation, Bankruptcy, and Public Records before reading this guide.

For step-by-step API implementation, see Litigation & Bankruptcy Search: API Quickstart.

1. What Baselayer Searches

A Baselayer docket search retrieves public court records associated with a business or individual across federal, state, and county court systems.

Baselayer returns:

Litigation (commercial disputes, contract claims, fraud, employment cases, and more)
Bankruptcy proceedings (Chapter 7, Chapter 11, Chapter 13, involuntary bankruptcy)
Regulatory and administrative cases
Trademark, service mark, and patent application history

2. Execution Mode

Docket searches support both synchronous and asynchronous execution, controlled via the Prefer header or your API key's default mode. For full details, see Synchronous & Asynchronous Request Execution.

Docket-specific webhook events emitted during async execution:

Event	When it fires
`DocketSearch.submitted`	Search has been accepted and is in progress
`DocketSearch.completed`	Results are ready for retrieval
`DocketSearch.failed`	Search has failed to execute

3. Three Ways to Initiate a Docket Search

Baselayer supports three request types for POST /docket_searches:

Option 1: Using a business_id Use a business_id from a previous Baselayer Business Search.

Option 2: Using a business_search_id with optional additional_search_entities Use the id returned from a Business Search response. Supports additional_search_entities to search linked individuals or alternate business names in the same call. This is the recommended approach when officer, guarantor, or beneficial owner coverage is needed alongside the primary business.

Option 3: Using a person_id Use a person_id from an existing Baselayer person record. Covered in detail in Litigation & Bankruptcy Search for Individuals.

4. Scoping the Search: Litigations, Bankruptcies, or Both

By default, Baselayer searches for both litigations and bankruptcy proceedings. You can scope the search to one type using the options field:

`options` value	What is searched
`["Order.Litigations", "Order.Bankruptcy"]`	Both - this is the default
`["Order.Litigations"]`	Litigation only
`["Order.Bankruptcy"]`	Bankruptcy only

Most customers search for both. For full details, see Litigation & Bankruptcy Search: API Quickstart.

5. Two Levels of Data: Dockets and Details

Baselayer returns docket data in two tiers:

Tier 1: Docket search results (default) The initial search returns high-level case metadata for every case found: case identifiers, parties, filing date, case type, status, and Baselayer's risk assessment. This is sufficient for the large majority of underwriting and KYB workflows.

Tier 2: Case details (on request) For specific cases, you can request the full case timeline - a chronological list of all filings, hearings, motions, and court orders. Details are retrieved via a separate PUT/GET flow and are typically only needed for deeper underwriting on large or complex exposures.

Details may include references to exhibits (court documents), which can be retrieved individually when available.

Most customers do not need case details or exhibits for standard workflows. If you expect to rely on detailed case timelines or documents, contact your Baselayer representative to design the right approach for your use case.

6. Response Structure

A completed docket search returns a response object containing a dockets array: one object per legal case found.

Top-level response fields:

Field	Type	Description
`id`	UUID	Unique identifier of the docket search request
`state`	string	Current state of the request (`PENDING`, `COMPLETED`, `FAILED`)
`dockets`	array	List of docket objects - see Section 6.1
`business_id`	UUID \| null	Business associated with the search, if applicable
`person_id`	UUID \| null	Person associated with the search, if applicable
`business_search_id`	UUID \| null	Business search ID used to initiate the request, if applicable
`last_updated_at`	datetime	When the search result was last updated

6.1 Docket Object Fields

Each object in the dockets array represents a single legal case.

Field	Description
`id`	Unique identifier of the docket - used for requesting details
`title`	Case title as provided by the court
`docket_number`	Case number in the court's system
`court`	Court where the case was filed (e.g., `NY Supreme Court`, `US Bankruptcy Court`)
`date_filed`	Date the case was originally filed
`case_type`	Court-provided description of the case nature (e.g., `Contract Dispute`, `Chapter 7`, `Trademark`)
`status`	Raw case status as returned by the court (varies by jurisdiction)
`normalized_status`	Baselayer's standardized status - see Section 6.2
`is_bankruptcy`	`true` if the case is a bankruptcy proceeding
`bankruptcy_type`	Bankruptcy chapter, if applicable (e.g., `Chapter 7`, `Chapter 11`)
`risk_level`	Baselayer's severity assessment - see Section 6.3
`match_level`	How closely the case title matched the searched entity name - see Section 6.4

6.2 Normalized Status

Raw case status values vary significantly across court systems - the same case state may be labeled Open, Pending, Active, or In Progress depending on the jurisdiction.

Baselayer provides a normalized_status field with two values:

Value	Meaning
`open`	Case is active or status is uncertain - treat as potentially ongoing
`closed`	Case is definitively resolved

Important: Baselayer only sets normalized_status = closed when it is certain the case is resolved. This conservative approach means some cases may appear as open even when resolved in practice. For decisioning purposes, treat open as a conservative signal that a case may still be active.

6.3 Risk Level

Baselayer generates a risk_level for each docket as an at-a-glance prioritization signal, based on case type, age, status, match level, and court metadata.

Value	Meaning
`high`	Significant legal or financial exposure: bankruptcy, eviction, class action, major financial dispute
`medium`	Cases filed within the last 5 years that are not closed and do not meet high-risk criteria
`low`	Cases filed more than 5 years ago, or small claims cases
`no_risk`	Trademarks, service marks, IP filings, administrative records, or closed cases

risk_level is designed to simplify the complexity of hundreds of case types across thousands of jurisdictions into a single actionable signal. Customers can build their own classification logic on top of it.

For guidance on how to use risk_level in decisioning workflows, see Litigation & Bankruptcy Search: Best Practices.

6.4 Match Level

match_level indicates how closely the case title matched the entity name that was searched. Because most US court systems do not provide reliable business identifiers (such as EINs or registration numbers), docket searches rely primarily on name matching.

Value	Meaning
`EXACT`	Precise match to the searched entity name - high confidence
`SIMILAR`	Close but not exact - may indicate a DBA, trade name, name variant, or related entity

The default recommended approach is to rely on EXACT matches for automated decisioning, and consider SIMILAR matches for deeper due diligence workflows. For the full decision framework, see Litigation & Bankruptcy Search: Best Practices.

7. Where to Go Next

Litigation & Bankruptcy Search: API Quickstart — Step-by-step implementation with full code examples
Litigation & Bankruptcy Search: Best Practices — Risk classification, match level strategy, and decisioning frameworks
Litigation & Bankruptcy Search for Individuals — Searching litigation for sole proprietors, officers, guarantors, and beneficial owners
Litigation, Bankruptcy, and Public Records — Background on court types, bankruptcy chapters, and key terminology