Skip to main content

LexisNexis Bankruptcies

The LexisNexis Bankruptcies block combines a business bankruptcy search with its detailed report.

What the service returns

The search can return multiple candidates. The report is based on identifiers from the first search record, so review the search match before relying on the report.

Requirements

Report

Run the services

Call Enrich Business Credit Application at PUT /api/applications/{application_id}/enrich. Search:
Report:
Run the search before the report. If report identifiers are not stored, the report service automatically performs a search first. It then requires both BusinessId and TMSId from the selected search record. Search settings are fixed by Lendflow: up to 20 records from record 1, nickname and phonetic matching enabled, also-found records included, and all bankruptcy chapters. The report requests all bankruptcies. Callers cannot override these settings through options.

Retrieve results

Poll GET /api/applications/{application_id}/commercial_data through Get Commercial Data with both service IDs in services[]. Get Commercial Data returns the latest statuses, dates, commercial_data, and request_data values for each requested service ID.

Asynchronous behavior

Each enrichment call queues a job; {"data":{"onqueue":true}} is not a provider result. Poll each service independently until its commercial-data status is Success or contains an error. Rerunning a report reuses stored match IDs unless they are absent, in which case a new search is performed.

Example response

Search result:
Report result:

Response fields

Only fields shown in the fixture are defined here. LexisNexis can return additional provider fields.

Data Orchestration

The block is available under Bankruptcies → LexisNexis. Data Orchestration bankruptcy conditions use the search service, not the report service. Run lexis_nexis_bankruptcy_search before any dependent condition.

Errors

FAQ

Yes, but it automatically runs search when stored bankruptcy IDs are absent. Running and reviewing search first makes the selected match explicit.
No. The current implementation uses fixed search settings and exposes no options.
No. The first search record must provide both a TMS ID and business ID, and the report request can still fail independently.
No. It confirms only the service or services in that request were queued.