Skip to main content
This guide walks through the full docket search implementation: submitting a search, retrieving results, and requesting case details and documents when needed. Before starting, review Litigation & Bankruptcy Search: Basics for an overview of how the product works, and Litigation, Bankruptcy, and Public Records for court and case terminology.

Prerequisites

  • An active Baselayer API key
  • A completed Business Search: you will need either the business_id or business_search_id from that result
  • Familiarity with Baselayer’s Business Search API: see Business Search: API Basics if needed

Base URL & Authentication

All requests require an API key in the X-API-Key header:

POST /docket_searches accepts three request variants depending on what identifiers you have available.

Option A: Search by business_id


Option B: Search by business_search_id with additional_search_entities

Use the id from a Business Search response. This variant supports additional_search_entities to search linked individuals or alternate business names in the same call.
For full guidance on additional_search_entities, see Litigation & Bankruptcy Search: Best Practices and Litigation & Bankruptcy Search for Individuals.

Option C: Search by person_id

For a full guide on searching individuals, see Litigation & Bankruptcy Search for Individuals.

Scoping to Litigations, Bankruptcies, or Both

By default, Baselayer searches for both litigations and bankruptcy proceedings. Use the options field to scope the search if needed:
Most customers search for both. Scoping to one type is useful when your workflow treats litigation and bankruptcy as separate decisioning steps, or when cost efficiency matters at high volume.

Execution Mode

Docket searches support both synchronous and asynchronous execution. Results are returned directly in the response body on synchronous requests. For async execution, consume results via webhooks (DocketSearch.completed) or by polling /docket_searches/{id}. See Synchronous & Asynchronous Request Execution for setup guidance.

Step 2: Retrieve Results

Synchronous (default): Results are returned in the POST response body. Skip ahead to Step 3: Parse the Response. Asynchronous: Consume results via the DocketSearch.completed webhook or poll /docket_searches/{id} until state is COMPLETED. See Synchronous & Asynchronous Request Execution for full guidance.

Step 3: Parse the Response

A completed search returns a response containing a dockets array. Example response:
Key fields to evaluate on each docket: For full guidance on interpreting and acting on results, see Litigation & Bankruptcy Search: Best Practices.

Step 4: Request Case Details (Optional)

Case details provide the full chronological timeline of a case: all filings, hearings, motions, and court orders.
Most customers do not need case details for standard workflows. Request them selectively for cases that warrant deeper review.
Request details for a specific docket:
This initiates retrieval and emits DocketDetailsSearch.submitted and DocketDetailsSearch.completed webhook events. Retrieve the details:
The response includes an updates array: a chronological record of all case events. Some updates may reference exhibits (court documents) associated with that event.

Step 5: Retrieve Exhibits (Optional)

Exhibits are court documents referenced in case details. Availability varies by court and jurisdiction. Check availability: Each exhibit in the updates array includes an is_available field. Retrieve an available exhibit:
If is_available is false, the document must be ordered explicitly:

Full Example: Business Docket Search (Synchronous)


Where to Go Next