Skip to main content
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:
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: 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:

​
6.1 Docket Object Fields

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

​
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: 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. 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. 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