Company Lookup API vs Company Search API: Which Do You Need?

Executive Summary: Two products get sold under nearly the same name, and they solve opposite problems. A company lookup API takes an identifier you already hold and returns one authoritative record. A company search API takes a messy string from a credit application and returns a ranked list of candidates that might be the borrower. Buying the wrong one costs you either match rate or precision, and in alternative lending both failures land in the same place: a funded deal on an entity nobody actually confirmed. This guide separates the two call types, explains the retrieval mechanics behind each, and shows where each belongs in an underwriting flow.

What Is the Difference Between a Company Lookup API and a Company Search API?

The distinction is not marketing language. It shows up as two different endpoints in almost every registry API that publishes documentation.

Companies House, the UK registry, is the clearest public example. Its search endpoint takes a single parameter `q`, described in the specification as "The term being searched for," and returns a paginated result set.^[1] Its profile endpoint is a different call entirely: `GET https://api.company-information.service.gov.uk/company/{companyNumber}`, which requires a company number as a path parameter and returns one profile resource.^[2] Same registry, same data, two access patterns.

OpenCorporates draws the same line. Its single-company endpoint is `GET companies/:jurisdiction_code/:company_number`, which resolves an exact jurisdiction plus number pair with no fuzzy matching involved. Its search endpoint behaves the opposite way, and the documentation says so plainly: "the search is deliberately quite loose, requiring the returned companies to have all the searched-for words (in any order)."^[4]

Which Inputs Does Each Call Accept?

• Lookup input: a durable identifier. A state-assigned entity ID, a registry file number, or a 20-character LEI, which GLEIF defines as "a unique 20-character alphanumeric code that enables anyone, anywhere in the world, to access clear, unique identification data about a legal entity."^[10]

• Search input: a human-entered string. A DBA, a truncated legal name, a name with the entity suffix dropped, or a name a broker retyped from a bank statement.

• Lookup output: zero or one record. Either the identifier resolves or it does not.

• Search output: a ranked candidate list. Relevance ordering, often with a score, and no guarantee the top hit is the borrower.

• Lookup failure mode: false negative. A stale or mistyped ID returns nothing even though the entity exists.

• Search failure mode: false positive. A confident-looking top hit that belongs to a different company with a similar name.

Those two failure modes carry very different costs in a lending file, which is why the selection question matters more than the feature comparison.

Why Does the Naming Confusion Persist?

Vendors use "lookup" loosely. Some call a name search a lookup because the end user experiences it as one action. When you evaluate a provider, ignore the product name on the pricing page and read the parameter table. If a single endpoint accepts both an identifier and a free-text name, as Cobalt's SOS Search does, you are buying one endpoint with two retrieval behaviors, and you need to know which behavior your request triggers. The pillar guide to Secretary of State API solutions covers the broader provider landscape; this post is about which call to make once you have picked one.

When Should a Lender Use Exact-Match Lookup Instead of Fuzzy Search?

Use lookup whenever you already possess the identifier and the answer needs to be defensible.

Three moments in a lending workflow qualify. The first is re-verification. Once you have funded a merchant and stored the state entity ID, every subsequent check should resolve that ID directly rather than re-searching the name. Names change. Entity IDs do not. The second is renewal and portfolio review, where you are checking hundreds of known entities and a search-based sweep would introduce candidate ambiguity into a batch job that has no human in the loop. The third is any file that will be examined later, because a lookup produces a one-to-one link between your record and the state record.

What Happens When You Search a Name You Should Have Looked Up?

You inherit the registry's tokenization rules. Search engines analyze text before matching. Elasticsearch documents this directly: "The text provided is analyzed and the analysis process constructs a boolean query from the provided text," with the default operator being OR, so "capital of Hungary" is interpreted as "capital OR of OR Hungary."^[6] Applied to business names, an OR-joined query on "Atlas Freight Logistics LLC" will happily return "Atlas Roofing LLC" and "Freight Masters Logistics" alongside the entity you wanted.

OpenCorporates normalizes before it matches, "removing non-text characters (e.g. dashes, parentheses, commas), common 'stop words' (e.g. 'the', 'of'), and normalising common company types."^[4] That normalization is what makes search usable at all, and it is also what makes "Smith & Sons, Inc." and "Smith and Sons Incorporated" collapse toward each other. Helpful when they are the same firm. A problem when they are two unrelated registrants in the same state.

The moment a name search returns three plausible candidates, the decision has moved from your API to your operations team. Every one of those handoffs is measurable, and most lenders have never measured it.

Which Signals Tell You an Identifier Is Available?

Check the application intake path before you assume you only have a name. Many lenders already collect a state entity ID on the application, capture it from a formation document, or hold it from a prior funding. Cobalt's SOS Search accepts `sosId` for exactly this case and treats it as the most precise of its four supported search methods, ahead of business name, person name, and address filters.

How Does Fuzzy Company Search Actually Work Under the Hood?

Fuzzy matching is not one technique. It is a family of them, and knowing which one a vendor uses tells you how the system will fail.

Three techniques account for nearly every implementation you will encounter behind a company search endpoint.

• Edit distance. The Elasticsearch fuzzy query "Returns documents that contain terms similar to the search term, as measured by a Levenshtein edit distance," where that distance is "the number of one-character changes needed to turn one term into another."^[5] It catches typos well and abbreviations badly, since "Northwest" and "NW" are one token apart semantically and eight edits apart mechanically.

• Character n-grams. PostgreSQL's `pg_trgm` extension compares strings by trigrams, "a group of three consecutive characters taken from a string," scored by a `similarity()` function whose range runs "from zero (indicating that the two strings are completely dissimilar) to one (indicating that the two strings are identical)." The default similarity threshold is 0.3, permissive enough that a naive deployment will surface unrelated names.^[7]

• Probabilistic record linkage. The Fellegi-Sunter model behind the Splink library scores agreement field by field using an m probability (agreement given the records match) and a u probability (agreement given they do not), combining them into a match weight that is "a measure of the relative size of m and u," with weights additive across fields.^[8]

The third approach is the one that lets a system conclude that names disagree slightly while the registered agent and formation date agree strongly, so the pair is still a match. The first two cannot reach that conclusion because they only see the name string.

Why Do Expansion Limits Matter for Match Rate?

Fuzzy engines cap how many term variants they will consider. Elasticsearch's fuzzy query sets `max_expansions` with a stated default of 50.^[5] In a state with tens of thousands of entities beginning with a common word, a capped expansion silently truncates the candidate pool before scoring. Your borrower can be absent from the results not because the registry lacks the record but because the retrieval stage stopped early. When a vendor reports a match rate, ask whether misses of this kind are counted as misses.

What Do Match Rates Look Like for Lookup Versus Search, and Why?

Treat them as two separate metrics with two separate denominators. A blended "match rate" number that mixes identifier resolution and name resolution is not usable for capacity planning.

Lookup resolution is close to binary. Either the identifier exists in the registry and resolves, or it does not, and the small residual failure population is dominated by administrative causes: an entity ID reassigned after a merger, a number transcribed with a leading zero dropped, or a record for an entity that was administratively dissolved and purged from the searchable index. Search resolution is a distribution. It has a top-hit accuracy rate, a rate at which the correct entity appears anywhere in the returned set, and a rate at which the correct entity is absent entirely.

Which Three Numbers Should You Actually Track?

• Identifier resolution rate. Lookups that returned exactly one record, divided by lookups attempted. A drop here usually means your stored IDs are aging, not that the vendor degraded.

• Search top-hit precision. Cases where the highest-ranked candidate was the correct entity, confirmed by a human or a secondary field check.

• Search recall. Cases where the correct entity appeared anywhere in the candidate list, including position 8. This is the ceiling on what any downstream scoring can recover.

• Manual review rate. The share of searches that produced a candidate list a human had to adjudicate. This is the operational cost line, and it is the one most vendors never quote.

• Silent miss rate. No-result responses that were later shown to be resolvable. Sampling 50 of these per month will tell you more about a provider than any published benchmark.

Methodology for building the test set behind those numbers sits in the match-rate benchmarking guide, which covers name-variant construction and false-negative cost weighting.

How Does Volume Change the Calculus?

Application volume in small business lending has been steady rather than shrinking. The Federal Reserve's Small Business Credit Survey, fielded across more than 6,500 small employer firms, reported that the share of firms applying for loans, lines of credit, or merchant cash advances remained steady overall, with roughly half of firms having their funding needs met.^[13] Steady volume with a persistent funding gap means the marginal file matters, and a two-point difference in manual review rate becomes a headcount question rather than a rounding error.

How Do You Combine Both Calls in One Underwriting Workflow?

The sequence that works is search once, store the identifier, then look up forever after.

Stage one is resolution. On a new application where you hold only a name and a state, issue a name search, narrow with address filters when the applicant supplied an address, and adjudicate the candidate set. Stage two is capture. Persist the returned state entity ID against your borrower record the moment a match is confirmed. Stage three is every subsequent check, which becomes a direct identifier lookup with no ambiguity, no candidate list, and no reviewer.

What Does the Resolution Call Look Like?

Cobalt's SOS Search takes the name path with optional address filters that narrow results in states with many matches:

curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=true&screenshot=true' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'

The response carries both the resolved record and the ambiguity signal in the same payload:

{
  "status": "complete",
  "statusCode": 200,
  "requestId": "abc123-def456",
  "results": [
    {
      "title": "ACME CORPORATION",
      "filingDate": "2015-03-15",
      "stateOfFormation": "Delaware",
      "status": "Active",
      "entityType": "Corporation",
      "registeredAgent": {
        "name": "CT Corporation System",
        "address": "1209 Orange St, Wilmington, DE 19801"
      },
      "sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
      "screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
    }
  ],
  "possibleAlternatives": []
}

The `possibleAlternatives` array holds up to 10 close matches when the exact match is uncertain, which handles name variations, abbreviations, and common misspellings. An empty array on a live lookup is itself a signal: the retrieval stage found no competing candidate worth showing you. A populated array is your queue for human review, and its length over time is the operational metric from the previous section.

How Does the Identifier Path Differ Once You Have Captured It?

The same endpoint accepts `sosId` instead of `searchQuery`, and the confidence score returned with every result gives you the automation threshold. Scores of 0.8 to 1.0 are high confidence and most customers auto-accept, 0.5 to 0.79 is moderate and gets flagged for human review, and below 0.5 is likely a different entity. Wiring those bands into a decision table is covered in the confidence scoring guide.

Where Does Each Approach Fail, and What Should You Log?

Both paths fail quietly, which is the real problem. A no-result response looks identical whether the entity does not exist, the name was entered differently, or the state system timed out.

State registries are the constraint underneath every vendor. Delaware's public entity search returns records for both active and inactive entities, with the state noting that a result is "not an indication of the current status of an entity," and the free tier is limited to entity name, file number, formation date, and registered agent details, with "additional information can be obtained for a fee."^[11] Delaware also states that "Use of automated tools in any form may result in the suspension of your access to utilize this service," which is one reason lenders buy an intermediary rather than scraping.^[11] Oregon splits its public interface into a basic business name search and a separate advanced name search under a different application entirely.^[12]

What Are the Honest Limits on the Cobalt Side?

Response time varies by state, and that variance is real. Most states respond in 10 to 30 seconds on a live lookup, Delaware runs 15 to 30 seconds, and Oregon can take up to five minutes. Requests that exceed 30 seconds return async, either through a `retryId` you poll or a `callbackUrl` you register. Delaware status checks also carry a state-imposed fee, $10 for the basic status tier or $20 for the tier that adds recent filings and franchise tax detail, passed through at cost, and New Jersey status data is restricted by statute.^[14] Officer data availability varies by state because Cobalt returns what the state publishes and nothing more. A search API that promises uniform sub-second responses across 50 states is describing a cache, not a live registry read.

Which Fields Belong in Your Log Line?

• The `requestId`. Full response logging keyed to this value is what makes a decision reconstructable during an examination.

• The retrieval path used. Identifier versus name, recorded per call, so your match-rate metrics stay separable.

• The candidate count. Length of `possibleAlternatives` at decision time, not after a human pruned it.

• The confidence score. Stored as returned, not rounded into a pass or fail flag.

• The `screenshotUrl` contents. Screenshot URLs are valid for 3 to 30 days only, so download and store the image in your own system of record rather than persisting the link.

Guidance on interpreting the status field itself, rather than the retrieval mechanics, sits in how to verify business registration status via API.

How Should You Evaluate a Vendor's Lookup and Search Behavior Before You Buy?

Run the evaluation against your own declined and disputed files, not the vendor's sample data.

Build a test set of 200 real applicant names your team has already resolved manually, including the ugly ones: DBAs, hyphenated names, names with ampersands, entities that moved states, and at least 20 that you know are unregistered. Send each through the name path and score top-hit precision and recall separately. Then take the 200 confirmed entity IDs and send them through the identifier path a week later to measure resolution stability. The gap between those two numbers is the value of capturing identifiers at onboarding.

Which Vendor Questions Separate Real Answers From Marketing?

Ask which matching technique the search path uses, because "proprietary" is not an answer when the underlying options are edit distance, n-gram similarity, and probabilistic linkage, each with published behavior.^[5][7][8] Ask whether the candidate list is truncated before scoring and at what limit. Ask whether name normalization is applied to both sides of the comparison or only the query. Ask what a no-result response means and whether it is distinguishable from a source timeout. GLEIF, for reference, publishes that its API supports "full-text and single-field searches of legal entity and ownership data" plus "fuzzy" matching of fields such as names and addresses, which is the level of specificity a buyer should expect.^[9]

What About Filtered Search as a Middle Path?

There is a third pattern between loose search and exact lookup: filtered search. Companies House exposes `GET https://api.company-information.service.gov.uk/advanced-search/companies` with filters including `company_name_includes`, `company_name_excludes`, `company_status`, `company_type`, `incorporated_from`, `dissolved_from`, `location`, and `sic_codes`.^[3] The equivalent on the SOS side is pairing `searchQuery` with `street`, `city`, or `zip` filters to narrow results in high-volume states. Filtered search cuts candidate lists sharply when the application carries a verified address, and it is the cheapest precision improvement available to most lending teams.

What Should You Decide This Quarter?

If your intake already captures a state entity ID, the identifier path should be the default and search should be the exception. If it does not, the highest-return change is not a vendor switch. It is persisting the entity ID from the first successful resolution so that every later check stops being a search problem. Field-level detail on what a validation call actually returns is in what an entity validation API validates, and the build-versus-buy math behind maintaining 50 state integrations yourself is in the in-house cost comparison.

Cobalt Intelligence sits in the verification stack as a data source rather than a decisioning engine. It returns the state record, the normalized status, the confidence score, and the timestamped screenshot. What you do with a 0.62 confidence match is your credit policy, not an API response.