Business entity verification data, straight from state registries
Business entity verification starts with one question: does the company in front of you exist the way it says it does? The answer lives in state business registries — the public record of formation, status, registered agent, and filing history. Recordpipe collects that record and delivers it to your team as structured business entity data, in your schema, on your cadence.
This is a data service, not a decision tool. You bring the KYB policy, the risk rules, and the approval workflow. We bring the verified registry fields those rules need, captured at source and stamped with when they were observed. Nothing is inferred, modeled, or scored on our side.
The scope is set in a $500 scoping: which states and entity types, which fields, how you want to receive them, and how often. You get a feasibility read, a sample of real records, and a fixed quote within 5 business days. Contracts run from $5,000 to $3 million, and the scoping fee is credited when you proceed.
A business verification API built for your own KYB process
Teams searching for a business verification API usually want a lookup they can call at onboarding and a feed they can reconcile against later. We deliver both from the same pipelines. During onboarding, a request with a legal name, state, and registration number returns the registry record as a structured response. For your existing book, bulk files or warehouse loads re-verify every entity on schedule.
The API is hosted by us and shaped to your contract — your field names, your response format, your authentication. It sits behind the same managed automation that keeps over one million public records processing nightly, so a lookup that requires submitting a query per entity is handled end to end and returns a row, not a screenshot.
Delivery options cover the rest of the stack: webhook pushes when a monitored entity changes status, scheduled CSV, JSON, or Parquet drops, or direct loads into your data warehouse. Details on the hosted option are on the Custom Data API page. The schema stays stable across all of them, so your ingestion does not churn.
Know your business data: what registries publish, and what they don't
Know your business data has a hard boundary, and it is worth being precise about it. State registries publish formation records, entity status, registered agents, and — in many states — officers, directors, members, or managers as named in filings. UCC filings, published liens, and licensing records add signals about how a business operates. All of that is public, and all of it is in scope.
Beneficial ownership data is different. Federal beneficial ownership reporting is not a public record, and no vendor can lawfully deliver it as one. What we can deliver is the public layer beneath it: the officers, organizers, and managers a state publishes, plus the registered agent trail across affiliated entities. Your KYB process decides what that layer proves.
The same applies to business credit data. We do not produce scores or credit files. We deliver the public inputs — filings, liens, judgments where courts publish them, status history — that a credit model consumes. Raw public data, not consumer reports; we are not a CRA, and eligibility use cases get compliance review at intake.
Business registration data on cadence: verification doesn't end at onboarding
Business registration data changes after you approve the account. Entities dissolve, go delinquent, get administratively revoked, reinstate, change agents, or amend their names. A KYB program that only verifies at onboarding is looking at a photograph of a company that has since moved. Recordpipe runs verification as a standing pipeline instead.
Your portfolio is re-verified on the cadence you set — nightly, weekly, or monthly — and each cycle produces a delta: which entities changed status, which filed amendments, which appeared in new UCC or lien records. The delta arrives as a webhook event, a file, or an API response, whichever your case system consumes. Every record carries a capture date and a source category so your audit trail is defensible.
Maintenance is ours. When a registry changes what it publishes, the workflow is repaired, gaps are backfilled, and you receive a written change notice. Your compliance team reads about the change; it does not work the ticket. Related coverage: Financial services & compliance and Trust & safety.
What an engagement delivers
| Deliverable | Description |
|---|---|
| entity_record | Legal name, entity type, jurisdiction of formation, and registry identifier, normalized to your schema. |
| registry_status | Current standing as published — active, delinquent, dissolved, revoked, reinstated — with the date the status was observed. |
| formation_details | Formation date, filing type, and any published conversion, merger, or domestication history. |
| registered_agent | Agent name and address as filed, with change history where the registry publishes it. |
| principals | Officers, directors, members, or managers as named in public filings, where the state publishes them. |
| name_and_address_match | Structured comparison of the applicant-supplied name and address against the registry record, flagged for your rules to act on. |
| lien_and_ucc_signals | Related UCC filings and published liens matched to the entity, with secured party and filing date. |
| status_change_events | Per-cycle delta of entities that changed status, amended filings, or dropped from the registry. |
| lookup_response | Hosted API request and response for single-entity verification at onboarding, in your response format. |
| capture_metadata | Per-record observation timestamp, source category, and run identifier for audit. |