Company Lookup API: Business Intelligence for Applications

TLDR: A company lookup API resolves a messy input (a domain, a partial name, or a DBA) to a canonical company record with a confidence score. The hard part is not the HTTP call but the matching logic underneath: normalization, alias expansion, subsidiary mapping, and deciding what to do when the API returns multiple candidates or nothing at all. A production pipeline needs fallbacks, a freshness check layer, and a clear definition of what counts as a match before you write a single line of integration code.

What a Company Lookup API Does

A company lookup API accepts an identifier and returns a structured company record. Identifiers vary by provider but typically include:

• Website domain (the most reliable identifier for automated pipelines)
• Company name string (the least reliable, because names are ambiguous and inconsistently formatted)
• Professional network profile URL
• A vendor-assigned canonical ID, once you have established the mapping once

The response typically contains a confidence score alongside the record. A score of 1.0 or 100 percent means the system found an exact, unambiguous match. Scores below that signal fuzzy matching, and the right action on a low-confidence result is different from the right action on a high-confidence one. Understanding the response shape, the matching logic behind it, and the sources feeding it is what separates a reliable integration from one that silently mis-routes accounts. Because lookup is the first stage of nearly every enrichment workflow, it connects closely with the broader B2B data API landscape, where firmographic, contact, and technographic records all depend on a correctly resolved entity.

Entity Resolution: The Actual Problem

Looking up a company is an entity resolution problem. The entity (the real-world organization) exists independently of any particular string or identifier your application holds. Your application may have one or many imperfect references to that entity, and the lookup API's job is to resolve those references to a canonical record.

This is harder than it looks for several structural reasons, which are worth understanding before you design your integration.

Legal names and trade names diverge

A company may be incorporated as "Acme Widgets Holdings, LLC" but operate publicly as "Acme" or under a DBA (doing business as) name like "Acme Commerce." Your inbound CRM data will almost never contain the legal name: it will contain whatever the person filling the form typed, which is usually the brand name, often truncated or misspelled. A lookup API that only matches on legal name will miss these records.

Providers that maintain a DBA layer keep a table of alternative names (historical names, trade names, translated names) indexed alongside each canonical entity, each with start and end dates. A match against any alias in that layer returns the canonical record, so a search for "Acme Commerce" resolves to the same entity as "Acme Widgets Holdings, LLC."

Subsidiaries and parent companies create ambiguity

When a prospect fills out a form and types "Google Cloud," the legal entity behind that operation is not "Alphabet Inc." and is not the same entity as "Google LLC." Depending on your sales motion, you may want to match to the subsidiary (Google Cloud, the product division), the operating entity (Google LLC), or the ultimate parent (Alphabet Inc.). A lookup API that returns only one candidate without exposing the hierarchy forces you to make that decision blindly.

Good lookup APIs expose a parent_company field and optionally a full ownership graph. When they do not, the practical workaround is to use the returned domain or LinkedIn URL to query a secondary source that does expose hierarchy.

Common names produce multiple candidates

A name-based lookup for "Atlas" or "Apex Solutions" will return dozens of candidates. The API should rank them by confidence score and, ideally, expose which signals drove the ranking (domain match, location match, industry match). Without that signal breakdown, disambiguating between candidates requires you to apply your own business logic against fields in the response.

Normalization Before You Match

Whether you are calling a lookup API or building internal matching, normalization is the highest-leverage step. Two strings that differ only in whitespace, punctuation, or legal suffix are a false negative from any exact-match system. Apply normalization before sending a name-based query:

import unicodedata, re

def normalize_company_name(raw: str) -> str:
    name = unicodedata.normalize('NFKC', raw)
    name = name.casefold()
    legal_suffixes = [
        'limited liability company', 'incorporated',
        'corporation', 'company', 'limited',
        'inc', 'corp', 'co', 'ltd', 'llc', 'lp', 'plc',
        'holdings', 'group', 'international',
    ]
    for suffix in legal_suffixes:
        if name.endswith(' ' + suffix):
            name = name[:-(len(suffix) + 1)].rstrip(', ')
    name = re.sub(r"[&'.,;:()/\\-]", ' ', name)
    return re.sub(r'\s+', ' ', name).strip()

This pattern, stripping legal suffixes longest-first to avoid partial removal, is well-established in entity-resolution literature and is directly applicable to name-based lookups against any provider. Note that domain-based lookups do not require this step: a domain is already a precise, normalized identifier.

Response Shape Walkthrough

The following is a representative response shape from a domain-based company lookup, modeled on published API documentation from providers in this space. The exact field names differ by vendor, but the structure is typical.

{
  "matched_on": "stripe.com",
  "match_type": "domain",
  "confidence_score": 1.0,
  "company_data": {
    "canonical_id": "810670",
    "basic_info": {
      "name": "Stripe, Inc.",
      "primary_domain": "stripe.com",
      "all_domains": ["stripe.com", "stripe.dev"],
      "company_type": "Privately Held",
      "year_founded": 2010,
      "employee_count_range": "5001-10000"
    },
    "social_profiles": {
      "linkedin_url": "https://linkedin.com/company/stripe",
      "professional_network_id": "2916362"
    }
  }
}

Key fields to inspect in any response:

• match_type: tells you whether the match was exact (domain) or fuzzy (name). A name match at a lower confidence score warrants a manual review step in your pipeline before acting on the record.
• confidence_score: treat scores below 0.8 as candidates requiring human review or a fallback query, not as confirmed matches.
• all_domains: useful for deduplication. If a company has multiple domains (brand domain plus product subdomain, for example), matching on any of them should resolve to the same canonical record. Store the canonical ID, not the domain you queried with.
• canonical_id: the vendor's stable identifier for this entity. Use this as your foreign key for subsequent enrichment calls, not the domain, which may change.

Freshness Problems with Stale Records

Static company lookup databases are refreshed on a schedule, typically weekly to monthly for major providers. This creates a class of errors that are silent and hard to detect:

• A company acquired last month may still appear as an independent entity.
• A company that rebranded may return under the old name only.
• A recently dissolved entity may return a record with no dissolution flag.
• A startup founded two months ago may return no match at all, even though they have a live website and active LinkedIn presence.

The most consequential of these for a sales or risk workflow is the dissolution case: a "successful" lookup against an entity that no longer exists is a worse outcome than a failed lookup, because it silently routes work toward a dead end.

Providers that expose a last_verified timestamp in the response give you a signal you can act on. If the timestamp is more than 60 days old and the account is high-value, trigger a freshness check. If no timestamp is exposed, treat the record age as unknown and assume it may be stale.

Building a Lookup Pipeline with Fallbacks

A production company lookup pipeline should never rely on a single call to a single provider. The following architecture handles the common failure modes.

Tier 1: Domain-based lookup

Always try domain first. A domain is unambiguous, and domain-based match rates are consistently higher than name-based match rates across every provider tested in published benchmarks. Parse the domain from the company's email address or website field before calling the API.

from urllib.parse import urlparse

def extract_domain(url_or_email: str) -> str:
    s = url_or_email.strip().lower()
    if '@' in s:
        return s.split('@')[-1]
    parsed = urlparse(s if '://' in s else 'https://' + s)
    return parsed.netloc.lstrip('www.')

Tier 2: Name-plus-location lookup

When no domain is available or the domain lookup returns no match, fall back to name matching. Add a city or country field if you have it: most providers accept multi-field queries and use the location to disambiguate between companies with identical or similar names.

Tier 3: Live-web verification

When the structured lookup fails entirely, or returns a low-confidence result you cannot act on, a real-time web search can surface current information about the company. Submit the company name plus city (or a distinctive keyword) as a search query and parse the top results for the official domain. Once you have a domain, you can retry Tier 1 with it.

You.com's web search API returns LLM-ready web results and is well-suited for this pattern. A query like "Acme Commerce" fintech "San Francisco" site:linkedin.com OR site:crunchbase.com will typically surface the correct entity's profile in the top results, giving you a canonical domain or LinkedIn URL you can feed back into Tier 1.

For more complex cases (recent acquisitions, rebrands, newly public companies), the real-time web search API can synthesize a cited answer from multiple live sources, which is more reliable than parsing a single search result for a company that has recently changed status.

Tier 4: Human review queue

Records that fail all automated tiers should enter a human review queue rather than being silently dropped or written with a null company ID. Set a volume threshold: if more than five percent of your lookups are hitting this tier, the problem is likely in Tier 1 or 2 (poor domain extraction or normalization), not in the coverage of your providers.

Handling Subsidiaries and DBA Names in Practice

The subsidiary and DBA cases require explicit decisions before you code them, not after.

Decision 1: Which entity level do you want? Define this per use case. For account-based marketing, you usually want the operating subsidiary (the entity that signs contracts). For financial risk assessment, you want the ultimate parent (the entity with the balance sheet). Some lookup providers let you request a specific hierarchy level; others return only one entity and expose the parent as an attribute.

Decision 2: How do you handle a DBA match? When a lookup returns a match via the DBA name layer rather than the legal name, the confidence score is usually lower. Decide in advance whether a DBA match at a given score threshold is sufficient for automated processing or requires human review.

Decision 3: What do you store? Store the vendor's canonical ID, not the name or domain you queried with. When a company rebrands, a canonical-ID-based lookup will return the updated name and domain; a name-based storage key will break. If you use multiple vendors, maintain a local canonical entity table with a UUID and store vendor-specific IDs as foreign keys, so you can switch or augment providers without re-keying your database. Pipelines that depend on filling every field for high-value accounts benefit from pairing the company lookup API with a waterfall enrichment strategy, so each missed field passes to the next provider rather than being left blank.

Verifying Lookups Against Live Web Data

A lookup API tells you what a vendor's database says about a company. The live web tells you what is true right now. For high-value records, these two sources should be compared, not just chained.

A practical verification pattern:

1. Retrieve the company record from your static lookup API. Note the primary domain and the last-verified date.
2. Fetch the contents of the company's own website homepage using a contents API. You.com's Contents API returns clean Markdown from any URL, which you can parse or pass to an LLM for structured extraction (you.com/docs, 2026-09-04).
3. Compare the fetched content against the database record. Discrepancies in company description, product focus, or employee count signal a record that needs re-enrichment or flagging.
4. Run a news search for the company name to detect recent events (acquisitions, leadership changes, funding rounds, shutdowns) that the static database may not yet reflect.

import requests

def verify_company_record(domain: str, api_key: str) -> dict:
    # Fetch live homepage content
    resp = requests.post(
        "https://ydc-index.io/v1/contents",
        headers={"X-API-Key": api_key},
        json={"urls": [f"https://{domain}"], "formats": ["markdown"]},
        timeout=30
    )
    resp.raise_for_status()
    pages = resp.json()
    live_markdown = pages[0].get("markdown") or "" if pages else ""
    return {"domain": domain, "live_content": live_markdown[:2000]}

Common Integration Mistakes

• Using name as a primary key. Company names are not unique. Two companies named "Atlas Software" can exist in the same city. Always resolve to a canonical ID and store that.
• Ignoring confidence scores. Treating a 0.6-confidence match the same as a 1.0-confidence match produces silent data corruption. Route low-confidence matches to a review step.
• Not extracting domains before querying. If your input record contains an email address or website URL, extract the domain before calling the API. A domain-based query will match more reliably and more cheaply than a name-based query.
• Caching without expiration. A lookup result cached indefinitely will become wrong. Set a TTL appropriate to the record type: 30 days for company-level firmographics, 7 days for contact titles, shorter if you have access to a last-verified timestamp that tells you when the source data was checked.
• Assuming the first result is correct. When a lookup returns multiple candidates, the first result is the highest-confidence candidate, not necessarily the correct one for your use case. If your input was a partial name, inspect the full list before selecting.

Compliance Notes for Contact-Level Data

Company-level firmographic data (headquarters, industry, employee count) is generally low-risk from a privacy perspective because it describes an organization, not an individual. Contact-level data returned alongside a company lookup (employee names, work emails, phone numbers) is a different matter.

Under the GDPR definition of personal data, a work email address identifies a natural person and is therefore personal data, even in a B2B context. The CCPA, as amended by Proposition 24, similarly applies to personal information about California residents regardless of whether the context is commercial. If your lookup API returns contact records, apply the same data handling discipline you would apply to any other personal data: document your lawful basis, implement deletion request handling, and set retention limits.

Choosing a Provider

Factor	What to evaluate
Domain match rate	Test against your own domain list, not a vendor benchmark. Expect 80-95% for a modern provider on well-established companies.
Name disambiguation quality	Submit 20 ambiguous company names. Does the API return ranked candidates with confidence scores, or just one result?
Hierarchy exposure	Does the response include parent company and subsidiary fields? Is the ownership graph queryable?
DBA and alias coverage	Test with 10 known trade names or brand names that differ from the legal entity. How many resolve correctly?
Last-verified timestamp	Is a freshness indicator included in the response? Without one, you cannot apply a targeted re-enrichment strategy.
Rate limits	What are the per-minute and per-day limits? Do batch endpoints have higher or lower limits than single-record endpoints?
Canonical ID stability	Does the vendor's entity ID remain stable across rebrands, mergers, and data updates? A changing canonical ID breaks downstream foreign keys.