Business Entity Search by API: What Exists and What Does Not

Somebody needs to confirm a company is real. Not enriched, not scored: confirmed, the way a registry confirms it, with a filing number and a status. The search that follows is almost always the name of a state and the words entity search, and it is one of the highest-volume company-data queries there is.

This is about what is actually available for that job. Monid is the OpenRouter for agent tools, and the useful thing we can do here is run the endpoints and tell you which parts of the question they answer.

Fair disclosure: you are on the Monid blog, and the honest headline of this post is that the most-searched version of this job is the one we cannot do. The measured result below is the least flattering thing in the guide and it is the reason to read it.

Is there an API for state business entity search?

Not in this catalogue, and it is worth being precise about what that means rather than softening it.

The demand is unambiguous. In our own keyword library, the state-registry cluster totals 55,600 searches a month: Texas at 22,200, New York at 12,100, Oregon at 8,100, plus two more Oregon phrasings. Every one of those rows is currently ranked by a scraping vendor, which tells you how people are solving it.

What a state registry actually holds is different from what any enrichment provider sells:

The filing itself. Entity number, formation date, entity type, and the exact registered name including the suffix. This is the record of legal existence, not a description of a business.

Status. Active, dissolved, forfeited, administratively dissolved for not filing. This is the field people are usually after, and no commercial dataset is authoritative on it.

The registered agent. The person or service accepting legal service, with an address. Frequently the only real address a small entity publishes anywhere.

Officers and filing history, in the states that publish them.

Fifty states, fifty systems, fifty interfaces, no common schema and no shared identifier. That is why there is no single endpoint: the underlying thing is not one dataset, it is fifty, and several of them are still HTML forms with session tokens.

If you need certified registry data, go to the state. Every Secretary of State runs a public search, most publish bulk data, and some sell an API. For a legal or compliance requirement that is the source, and a resold copy is not a substitute for it.

What does the US company endpoint actually return?

SEC filings, which is a much smaller universe than the one you searched for.

There is a US company endpoint in the catalogue, strale /x402/us-company-data, and its description says what it reads: SEC EDGAR. We ran it twice on 2026-08-18 to see where the boundary sits.

A public company, Snowflake:

monid run -p api.strale.io -e /x402/us-company-data \
  --query '{"company":"Snowflake"}' -w

company_name      Snowflake Inc.
cik               0001640147
entity_type       operating
sic               7372  Services-Prepackaged Software
state             DE
address           135 CONSTITUTION DRIVE, MENLO PARK, CA, 94025
ein               460636374
ticker            SNOW
exchange          NYSE
status            active
match_confidence  exact

A clean record, with the state of incorporation, the federal tax number and a provenance block naming the exact EDGAR document it came from. For a registered filer this is good data and it is traceable, which matters more than it sounds.

A private company, Stripe:

monid run -p api.strale.io -e /x402/us-company-data \
  --query '{"company":"Stripe"}' -w
# HTTP 400

Nothing. Not an empty record, not a low-confidence match: an error. Stripe is one of the largest private companies in the United States and it is not in EDGAR, so the endpoint has nothing to return.

Two things follow, and the second is the one that will bite you:

The coverage boundary is SEC registration, not size or importance. Every public company is in there. Almost no private company is, which excludes the overwhelming majority of the entities anyone searches a state registry for.

A miss is a 400, not an empty result. That is a real handling difference. Code that treats a non-200 as a transient failure will retry a company that will never be found, and a batch built that way burns calls on the same permanent misses. Treat 400 from this endpoint as a coverage answer, not an error to retry.

What do you use when the registry is not available?

You separate the question into the two things people are actually asking, because only one of them needs a registry.

"Does this company legally exist, with this exact name and status?" That is a registry question and it has a registry answer. Go to the state, or to a specialist compliance vendor who has licensed the filings. Nothing in a commercial enrichment dataset is authoritative here, and treating it as such in a KYC or contracting workflow is a real risk rather than a shortcut.

"Is this a real, operating business I should deal with?" That is a different question, it is the one most people actually have, and it does have an API answer. Three signals, none of them a filing:

Resolution. Does the name map to a real domain and a real company record. akta /v1/company/search resolves a name to candidates at no cost per call, which makes it the right first step in any batch. We covered the ambiguity cases in finding a company's website from its name.

Firmographics. Headcount, location, industry, funding history from pdl /v5/company/enrich. Not proof of registration, but a company with a hundred employees on record and a funding history is not a shell. The full firmographics walkthrough covers the fields.

Activity. Is anything happening. Hiring, news, a site that resolves and returns content. A dissolved entity does not post jobs, and reading hiring as a signal is a better liveness check than most people expect.

The honest framing: these tell you a business is operating, not that an entity is in good standing. They are different claims and they fail in different directions. A company can be operating and administratively dissolved for a missed filing, and a company can be in perfect standing and dormant for three years.

What the free resolution step actually returns

Worth running before you plan a batch, because the output shape decides how much human review a list needs. We ran it on 2026-08-18:

monid run -p akta -e /v1/company/search   --query '{"query":"Perplexity AI"}' -w

Twenty-five candidates, each carrying four fields:

name              Perplexity
website           perplexity.ai
product_category  AI-powered search and answer engine
company_status    Private
uuid              the handle to pass to enrichment

The first row was correct. The rest of the list is the part worth looking at, because it shows what the match is doing:

Perplexity Fund     perplexityfund.ai     Venture Capital
Perplex             perplex.ch            Custom Acrylic Manufacturing
Paperplane          paperplane.ch         Graphic Design Services

The search is fuzzy and it does not pretend otherwise. A venture fund with a similar name, an acrylic manufacturer, and a company that merely shares some letters all came back for one query. That is the correct behaviour for a resolver, whose job is to offer candidates rather than to guess, and it is the reason product_category is in every row: it is what lets you eliminate the acrylic manufacturer without opening a page.

Two things follow for a batch:

Never take row one unread. It was right here and it will not always be. Score the candidate on category and website plausibility before you spend an enrichment call on it, because enriching the wrong company produces a confident record about somebody else.

company_status is not registry status. It says private or public, which is a market classification. It is not active, dissolved or forfeited, and reading it as good standing is exactly the mistake this whole post exists to prevent.

The step costs nothing per call, which is what makes it the right first pass on a list of any size: you can resolve everything, discard what does not match, and only pay on the survivors.

📖 See also the provider comparison, where a record's self-reported size band disagreed with its own counted headcount.

Which countries do have a registry endpoint?

Three, measured with monid discover on 2026-08-18, and the pattern behind them is instructive.

UK        strale /x402/uk-company-data        Companies House
Sweden    strale /x402/swedish-company-data   Bolagsverket
Germany   strale /x402/german-company-data    Handelsregister

All three countries run a single national registry with a public API. One system, one identifier, one schema, which is what makes an endpoint possible at all.

The United States has no national business registry. Incorporation is a state function, so there is no federal equivalent of Companies House and no number that identifies an entity nationally. EDGAR is the closest thing and it is a securities-filing system that happens to contain companies, which is why its coverage looks arbitrary from the outside.

There is also strale /x402/company-id-detect, which identifies the type and country of a company identifier. Useful in a pipeline receiving mixed international input: work out what an identifier is before deciding which registry, if any, can resolve it.

Which endpoint should I use for which job?

Verified present on 2026-08-18 with monid discover. The billing column gives the shape rather than a figure; monid inspect prints the current figure for free.

That last row is the honest workaround and it comes with a warning. State search pages are public and readable, and reading them is a scrape against a government system with its own terms, its own rate limits and no obligation to keep its markup stable. It works for a handful of lookups and it is a poor foundation for anything you have to keep running.

When should you not use Monid?

You need certified or legally sufficient registry data. Go to the state, or to a licensed compliance vendor. A resold record is not a certificate of good standing and no amount of convenience changes that.

Your workflow is US state registry lookup at volume. That is the job this catalogue does not do, and the measured Stripe result is the proof rather than a hedge. Buy a specialist, or build against the states you actually need.

You need officers, registered agents or filing history. None of the endpoints above return them. EDGAR carries filings for registered filers and nothing for anyone else.

And the caution about us. The US endpoint returned a 400 for one of the largest private companies in the country. That is not a defect in the endpoint, it is EDGAR's coverage showing through, and it is a good illustration of the rule that holds across this catalogue: metadata describes intent, a run describes behaviour. Run your own hardest case before you size a batch.

Conclusion

The most-searched version of business entity search, a state registry lookup by API, does not exist in this catalogue and mostly does not exist as a product, because the underlying data is fifty separate systems with no shared identifier. Anyone selling you one national US registry API is selling you a scraper with a search box on it.

Two things matter more than which vendor you try. Coverage is defined by SEC registration, not by size, and our measured proof was blunt: Snowflake returned a full record and Stripe returned a 400. And a coverage miss arrives as an error rather than an empty result, so code that retries non-200 responses will burn calls forever on companies that will never be there.

Start with the free part: company resolution costs nothing per call, so you can separate the names that resolve from the ones that do not before spending anything on enrichment. Then run your hardest known case, private and unlisted, and see what comes back. Begin at monid.ai.

FAQ

Last updated August 2026.