> ## Documentation Index > Fetch the complete documentation index at: https://docs.baselayer.com/llms.txt > Use this file to discover all available pages before exploring further. # Litigation & Bankruptcy Search: Basics > How Baselayer's Docket Search product works: what it searches, how results are returned, and what the response contains. 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](/docs/litigation-and-bankruptcy-records) before reading this guide. For step-by-step API implementation, see [Litigation & Bankruptcy Search: API Quickstart](/docs/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](/docs/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](/docs/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](/docs/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`, `EXECUTING`, `COMPLETED`, `FAILED`, `CANCELLED`) | | `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](/docs/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](/docs/litigation-bankruptcy-search-best-practices). *** ## 7. Where to Go Next * **[Litigation & Bankruptcy Search: API Quickstart](/docs/litigation-bankruptcy-search-api-quickstart)** — Step-by-step implementation with full code examples * **[Litigation & Bankruptcy Search: Best Practices](/docs/litigation-bankruptcy-search-best-practices)** — Risk classification, match level strategy, and decisioning frameworks * **[Litigation & Bankruptcy Search for Individuals](/docs/litigation-bankruptcy-search-for-individuals)** — Searching litigation for sole proprietors, officers, guarantors, and beneficial owners * **[Litigation, Bankruptcy, and Public Records](/docs/litigation-and-bankruptcy-records)** — Background on court types, bankruptcy chapters, and key terminology This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.