Public Records API: Matching the Record

A procurement team onboarding a new supplier runs the company name through a public records API and gets back three results: two registered companies with nearly identical names, and a court filing against one of them. Every record is real, public, and correctly retrieved. None of them says which company is actually the supplier, or whether the filing has anything to do with it.

That gap between retrieving a record and knowing it belongs to the right entity is where much of business due diligence goes wrong. Retrieval is easy to automate. Matching, provenance, and review still decide whether the evidence means anything.

In this article, we examine what a public records API actually returns, why third-party exposure makes entity matching a priority, and how a review workflow keeps recorded facts, inferred signals, and final decisions separate.

A Public Record Is Evidence, Not a Verdict

A public records API is a programmatic interface that retrieves structured data from publicly accessible sources, such as court filings, business registries, and government databases, so software can query them instead of analysts searching each source by hand. What comes back is evidence about an entity, and the evidence is only as strong as the match behind it.

Public does not mean unrestricted. Whether a record can be seen and whether it can be reused for a given purpose are separate questions, and there is no single comprehensive public database. Each registry, court system, and agency holds its own slice, with its own authority, coverage limits, and update schedule.

Three failure modes follow from that. A coverage gap means a source was never searched or never held the record. Stale data means the source changed after the last retrieval. A wrong-entity match means a real record was attached to the wrong company. For business risk intelligence, any of the three can change a review outcome while the output still looks complete.

That is why a recorded fact, an inferred signal, and an approved decision need to stay separate. A filing with a date and a source is a fact. A possible link between two companies is a signal. A decision belongs to a person, and a score should never stand in for it.

Different Data Answers Different Questions

Business due diligence usually draws on four categories of public data, and each is built for a different question. Treating them as interchangeable is one of the fastest routes to a confident but wrong conclusion.

Court records. These cover dockets, filed documents, and case outcomes involving a party. A hit shows that a case exists, not what it means, since a claim, a dismissed suit, and a judgment are very different findings that usually require reading the underlying document.

Criminal records. Criminal-history data has a narrower scope and heavier restrictions, and coverage varies by jurisdiction. An arrest, a charge, or an allegation is not a conviction. Where records about an individual inform employment decisions, consumer reporting rules can apply, as the FTC's guidance for employers explains, and any such process needs qualified legal review.

Company registry data and enrichment. A registry is the authoritative source for whether a company legally exists and what it has filed, but registries differ by country and state. SEC filings in the United States cover publicly traded companies and other filers rather than every business, while the Companies House API in the UK covers limited companies and others that fall under the Companies Act 2006. Enrichment fields add context but do not prove registry status, and a company lookup does not show who ultimately owns or controls the business.

Domain registration data. A domain lookup shows who registered a domain and when, which helps corroborate an entity. Since January 2025, the Registration Data Access Protocol has been the definitive source for generic top-level domain registration data, according to ICANN. Personal details are often redacted, though, and a registrant is not automatically the legal business behind a website, especially with subsidiaries, brands, and shared domains.

None of these categories substitutes for another. A clean court search says nothing about registry status, an enrichment record is not proof of incorporation, and a domain match is not proof of ownership. They work as complementary evidence for one review, with each boundary kept visible in the output.

Why Third-Party Exposure Puts Entity Checks at the Center

The urgency behind supplier review is easy to quantify. Third-party involvement reached 48% of confirmed breaches in Verizon's 2026 Data Breach Investigations Report, a 60% increase on the previous year's dataset, according to Verizon's 2026 DBIR executive summary.

That figure measures breaches that involved a vendor, a hosting provider, or a connected supplier. It does not measure failed due diligence, and it says nothing about whether a records check would have changed any of those outcomes. What it shows is where the exposure now sits: in the relationships one organization has with others, which is why third-party risk intelligence has moved from a procurement formality to a security function.

It also raises the bar on a basic question. Every signal that follows, whether a court filing, a registry status change, or a newly registered domain, only matters if it is attached to the right legal entity. A supplier review that starts from a name inherits all the ambiguity of that name, which is why the rest of this article treats matching, not retrieval, as the central problem.

Resolving the Entity Before Retrieving Anything

A workable due diligence automation flow keeps a strict order of operations: establish who the entity is, then retrieve, then review. Four steps carry most of the weight.

Defining the purpose and resolving the entity. Every check starts with why it is being run, since purpose determines which sources are permitted and relevant. The entity is then pinned down with identifiers rather than a name: jurisdiction plus registry number first, with names and domains used only as supporting joins. When more than one candidate fits, the case goes to a manual queue instead of a guess.

Retrieving and normalizing records. Records arrive in different formats from different sources, so each is normalized into a common structure that keeps its origin. A trustworthy response carries the source link, the time of retrieval, the time the source itself was last updated, the record type, a match status, and a review status. This list is illustrative, not any specific product's contract. When a timestamp is unavailable, it stays empty, because retrieval speed and data freshness are different clocks, and a source link alone does not prove the match is right.

Reviewing exceptions and preserving evidence. Ambiguous matches, hits on individuals, and anything affecting a decision go to a named reviewer. Findings are logged with their sources so the decision can be audited later, and an empty result is recorded for what it is. No results can mean no record exists, the jurisdiction is unsupported, the entity was not matched, or the request failed, and each calls for a different response.

Monitoring for changes. After onboarding, changes in filings, registry status, or domain data are tracked against the same resolved identity, so a new signal arrives already attached to the right company.

A Scenario: The Supplier With a Twin

Consider a hypothetical scenario. A procurement team is onboarding a supplier called Alderbrook Components, a fictional company. A search for the name returns two registered companies with almost identical names in different states, and one of them has a lawsuit listed against it. The name alone cannot show which company is the supplier. Without a way to tell them apart, the team would have to either reject a possibly legitimate supplier or approve one with an unexamined lawsuit attached.

The team turns to the details the supplier has already provided: the registration number and state on its signed onboarding form, and its website domain. Only one of the two companies has that registration number, and its registered contact details match the website. The lawsuit belongs to the other company, so it is left out of the supplier's file. The supplier is cleared on the lawsuit, and the decision rests on evidence tied to the right entity.

Some months later, a new court filing appears against the correct company. The system does not assign a risk score. It sends the filing to a compliance analyst, who reads the document and finds an open contract dispute with another business, unrelated to the supplier's ability to deliver. The analyst keeps the supplier approved, notes the dispute and its source in the file, and flags the case for legal review if a judgment is ever entered. The decision belongs to a person, and it rests on a document that was read, not a name that matched. All names and events here are invented for illustration.

Where SL API Fits Into Public Records Due Diligence

SL API gives teams structured access to open data from hundreds of sources, including public records and corporate sources, through a single integration. A team can start from the identifiers it already has, such as a company name, a domain, an email address, or a phone number, and pull back the associated records and profiles in a format that can feed an existing system.

For due diligence, the value sits in corroboration. A registry entry becomes far more reliable when the same company can be tied to a domain, contact details, and a wider open-source footprint that agree with each other, and far less reliable when they do not. That cross-checking turns a name match into an entity match, and it is the step most easily skipped when volume rises.

Coverage still varies by jurisdiction and record type, so the sensible first step is to test the specific sources and regions a workflow depends on and to keep final decisions with a human reviewer. SL API supplies the evidence layer. The review, the purpose limits, and the decision stay with the team.

The Takeaway

Using a public records API well comes down to a short order of operations: define the purpose, resolve the entity with identifiers rather than names, retrieve with provenance, and keep review with a person. The data is rarely the bottleneck. With third parties involved in nearly half of breaches, the real risk is attaching the right evidence to the right entity, and being clear about what that evidence does and does not prove.

FAQ

What data can a public records API return?

It depends on the sources behind it, but typically includes company registry details, court filings and case information, regulator filings, and domain registration data. Coverage differs by jurisdiction and record type, so a provider's actual coverage for the relevant courts, registries, and dates should be verified rather than assumed.

Is public record data free to access and reuse?

Access and reuse are separate questions. Many records can be viewed for free, but terms can restrict how they are collected, stored, and used, and the permitted purpose matters, especially when records about individuals inform employment or similar decisions. Conditions should be checked source by source, with legal review where needed.

How do court records differ from criminal records?

Court records describe legal proceedings and can include civil, commercial, and criminal matters, with dockets, documents, and outcomes. Criminal-history data is a narrower category with its own scope limits and use restrictions. In both, an arrest, a filing, or an allegation is not a conviction, and the underlying document usually needs reading.

What does "no results" mean in a diligence workflow?

It is not the same as clean. A search can return nothing because no record exists, because the jurisdiction or record type is unsupported, because the entity was not matched, or because the request failed. A well-designed workflow records which of these happened instead of treating every empty result as a pass.

How current are API records, and how is freshness checked?

Two clocks apply: when the record was retrieved and when the source was last updated. A fast response does not mean fresh data. Checking both timestamps and noting when the source's own update time is unavailable shows how current a record really is.

Want to see how entity-level public record checks can become a repeatable step instead of a manual search? Book a personalized demo to see how SL API helps due diligence and risk teams resolve companies, domains, and contact details against structured public records and corporate sources, corroborate each match, and pass the evidence to reviewers directly within their existing workflows.