We’ve introduced Collateral Statement Templates to make lien filing faster, more consistent, and significantly easier for operations teams.
You can now create and manage multiple pre-filled collateral statements directly in Lien Filing Preferences. These templates can be customized with your preferred language and reused across filings - eliminating repetitive drafting and ensuring standardization across your secured party documents.
During the lien filing flow, you’ll see a new “Select Template” dropdown, allowing you to choose any of your saved statements with a single click. The selected text auto-populates the collateral section, streamlining the filing process and reducing manual entry errors.
This functionality is also available via API, enabling customers to programmatically reference saved templates in automated lien workflows.
Starting Saturday Jan 19, that means:
console.baselayerhq.com -> console.baselayer.com (we will have redirects of course)
docs.baselayerhq.com -> docs.baselayer.com
This awesome step for us also means that some small tweaks might need to be taken on your end to ensure all operations continue to run smoothly:
Update your bookmarks to access our dashboard quickly
Update your password manager (1password, Google, etc.)
api.baselayerhq.com will continue to work normally, so there is no need to update your webhooks or API calls 👏
We have just released v2 of our webhooks schema. Previously, the schema we were returning from the GET routes was misaligned from the webhooks. For example we were returning watchlist_hits as the field name from the GET /searches route and watchlists in the webhook payload.
Going forward this field should always be aligned. We have no plans to deprecate earlier versions of the webhook schema.
In the states of Louisiana, Georgia, and Oklahoma, providing county information is essential for lien filings because these states have specific local requirements that mandate the identification of the county where the property is located. This is necessary to ensure that the lien is properly recorded and recognized within the correct jurisdiction.
We've launched a new Lien Filing API, enabling programmatic creation and management of lien filings through Baselayer. This API supports both machine-to-machine (M2M) communication and can drive user interfaces with its document-like behavior.
What are Lien Filings?
A lien is a legal claim or right against a property, typically used as security for a debt or obligation. The Lien Filing API facilitates the process of creating, managing, and submitting these legal documents.
Key Features of the Lien Filing API
Draft-Like Workflow: Create and gradually populate lien filings over time, mimicking the behavior of working with draft documents.
Flexible Updates: Add or modify information in multiple steps, supporting both automated systems and user-driven interfaces.
Secure Party Masking: Option to protect the identity of secured parties when required.
Attachment Management: Programmatically upload, retrieve, and manage attachments associated with lien filings.
Comprehensive Validation: Built-in checks to ensure all required information is present and correctly formatted before submission.
API Endpoints
The API introduces the following new endpoints:
POST /businesses/{business_id}/lien_submissions: Create a new lien filing submission
GET /lien_submissions: Retrieve a list of lien filing submissions
GET /lien_submissions/{filing_id}: Get details of a specific lien filing submission
PUT /lien_submissions/{filing_id}: Update a lien filing submission
POST /lien_submissions/{filing_id}/submit: Submit a completed lien filing
POST /lien_submissions/{filing_id}/cancel: Cancel a lien filing in "Needs Attention" status
DELETE /lien_submissions/{filing_id}: Delete a draft lien filing submission
Additional endpoints are available for attachment management and secured party masking operations.
Implementation Notes
The API supports both full payload submissions and gradual population of lien filings, accommodating various integration scenarios.
The draft-like behavior makes it suitable for driving user interfaces where users might save work in progress and return later.
For M2M integrations, the API can be used to automate the creation and submission of lien filings based on predefined triggers or data flows.
Proper error handling should be implemented to manage validation responses effectively.
For detailed information on using the Lien Filing API, including request/response formats and best practices, please refer to our updated Lien Filing documentation.
Since the launch of Baselayer, business search has included support for handling retries when the IRS TIN validation service becomes temporarily unavailable. This retry support is transparent and experienced by users as increased latency when the IRS services have intermittent issues on the order of seconds or minutes.
In this release, Baselayer is expanding the IRS Validation retry functionality to handle IRS availability issues on the order of hours or even days long outages. These change enhance the overall resilience of business searches where the TIN matching is a critical component of the lender workflow where processing cannot proceed until the TIN matching has been fully resolved.
What is changing?
Prior to this release, business searches that encountered a long-term TIN verification failure would be reported as a negative tin_matched=False attribute value of the search result. In this release, searches that encounter a long-term TIN verification outage will return with a tin_matched=null value to indicate that TIN verification was unable to complete within the business search execution SLA. These searches will be subject to the retry logic detailed below.
This API change is accompanied by a new badge in the Baselayer Console visually indicating which searches are in this state so that users can immediately identify searches subject to TIN verification retry.
How does TIN verification retry work?
Business searches that cannot complete TIN verification during the initial search execution become queued into a new batch processor that retries them several times a day attempting to complete the search. They remain in the queue being retried every few hours until the IRS TIN verification API becomes available once more and verification completes successfully.
Once the TIN verification has completed, the TIN verification information is used to recompute the Baselayer KYB and Risk scores and the updated results are reported via a new BusinessSearch.updatedwebhook.
The BusinessSearch.updated webhook will contain the final binary tin_matched value and the new scores. The schema is identical to the familiar BusinessSearch.completed payload.
Users who wish to halt their processing workflows can do so by inspecting the search results payload, flagging any searches with tin_matched=nullvalue as being in TIN verification retry, and await the BusinessSearch.updated payload which will contain tin_matched=(true|false)and a refreshed set of KYB and risk scores in the payload.
The state of Delaware has introduced new restrictions on the availability of a subset of fields on the default representation of a corporate registration within the state. In particular, this affects the standing and status fields returned by the Baselayer API.
The standing and status fields are of interest to many Baselayer customers when evaluating lending decisions with entities registered in Delaware. To best support the needs of these customers, Baselayer has introduced a new orderable product called a Registration Enrichment.
Please note that ordering a Registration Enrichment carries with it a $10 pass-through fee from the state of Delaware.
What is a Registration Enrichment?
A registration enrichment is an explicit request issued to Baselayer to retrieve the standing and status fields from a state and make them available within the Registration representation returned via the Baselayer API.
Baselayer pulls the standing by default for all states except Delaware. So while you may use these routes to explicitly request the standing for any registration from any state, you will already have the standing accessible (if available) for everywhere except Delaware. Therefore these API routes will primarily be useful in the situation where one would like to explicitly request the standing for a Delaware registration.
Using the Registration Enrichment API
Registration Enrichment follow the familiar Baselayer API conventions of exposing 3 API routes:
POST /registration_enrichments - Request that Baselayer enrichment a registration. The input is a simple JSON structure containing the ID of the Registration that you would like enriched (e.g., { "registration_id": "D873795F-1064-4D68-8F72-3528E43A6823" }
The returned body will contain the ID of the Registration Enrichment task submitted for processing.
GET /registration_enrichments/{id} - Get the full representation of the Registration Enrichment including status and nested details about the enriched registration.
GET /registration_enrichments/{id}/status - A polling friendly endpoint for monitoring the status of a Registration Enrichment request during processing.
Registration Enrichment Webhooks
As is standard with other Baselayer products, Registration Enrichments emit webhooks notifying API consumers of the status as the task is processed to completion.
RegistrationEnrichment.submitted Emitted with a Registration Enrichment request has been submitted for processing.
RegistrationEnrichment.completed Emitted when a Registration Enrichment request has completed and results are available.
RegistrationEnrichment.failed Emitted with a Registration Enrichment request has failed.
The tin_matched field has been migrated from being an enum with values NO_MATCH or EXACT to a boolean to reduce confusion.
tin_matched was previously an enum to align more closely with the business_name_match and business_address_match, but since there is no SIMILAR match for the tin_matched field, it makes more sense to treat it as a boolean - since the TIN is either a match by the IRS or not.
Users can now use the business_id of any business to initiate a search for litigations & bankruptcies using our new APIs!
1) Initial Docket Search
To start a litigation & bankruptcy search, simply make a POST request to /docket_searches using the business's UUID. We will search for and return up to 50 recent Litigations & Bankruptcies. Additionally, we often find Trademarks and Patent Application history.
After initializing the search, we emit a DocketSearch.submitted webhook event. to indicate that a Litigation & Bankruptcy search has commenced. Upon completion, we emit a DocketSearch.completed webhook event.
In addition to the webhooks, one can also retrieve all Litigations and Bankruptcies through a variety of other methods:
After the initial dockets are retrieved, you may want to learn more about a specific docket, such as viewing docket case history. To see details for a given docket, you must order them explicitly. This can be done using the docket_id and ordering the details with PUT /dockets/{docket_id}/details. The response from ordering docket details will return results from our cache by default. However, if you wish to get the most up-to-date details, you will need to order docket details from the court system itself by setting the param from_court to true.
Initializing a request for docket details will emit a DocketDetailsSearch.submitted webhook event. Once the search for docket details completes, a DocketDetailsSearch.completed webhook event will be emitted.
To retrieve the results, there are three options. You can either:
Retrieve the entire array of dockets using the one of the options in Part 1
Docket details sometimes include documents which may or may not be available for download. To retrieve a document with is_available = False you must also order the document explicitly from the court system.
Both PUT /dockets/{docket_id}/details and PUT /dockets/exhibits/{docket_exhibit_id} allow you to order update for docket details and docket exhibits from the court system directly using the boolean parameter from_court. Depending on the court system, this may involve extra PACER fees, which are passed through directly.
Smaller court systems often have fairly brittle APIs, so ordering from the court system directly can be prone to failure.
