Resolve one company entity from a domain before accepting its profile or
headcount.
Normalize the website without losing evidence
Preserve the submitted value and extract the hostname with a URL parser. Separate paths and tracking parameters from the company identifier. A product URL such ashttps://example.com/products/widget may identify the same website as its homepage. It does not establish the legal entity or sales account that owns the product.
Keep meaningful subdomains until your identity policy establishes that they can be collapsed. Do not derive the registrable domain by taking the final two labels: domain suffix structures vary. Use a maintained domain parser when that distinction matters.
Reject consumer mailbox domains as employer evidence when they came only from an email address. For trial signups with uncertain employers, use the signup enrichment workflow.
Ask for the company entity you need
Define the target entity explicitly. For example, request the operating company associated with the website. Alternatively, request the parent account already used in your CRM. Without that distinction, two sources can return different entities and both appear correct. People Data Labs’ company enrichment API describes matching an input company to a company profile. Treat the returned record as evidence to evaluate against your target entity, rather than letting a filled response settle every identity question.Find a company profile URL by domain
Use the domain as the search or enrichment input, then inspect the candidate company profile’s associated website and context. Prefer an explicit provider field when the contract supplies one. If research is required, retain the source URL and the evidence that connects the profile to the website. Do not build a professional-network URL by guessing a slug from the business name. A plausible URL is not an identity match. Return unresolved when the evidence cannot distinguish two candidates. If the provider returns no profile URL, search for the company name and domain together, then check the candidate profile’s website field. Record an unresolved result when no candidate establishes the connection. A search-result snippet alone is insufficient when similarly named companies remain plausible.Interpret employee counts before using them
An employee count needs a definition. Ask whether the field represents an estimated total, a size range, profiles associated with a company, or another documented measure. Preserve that definition with the source and observation time. Do not turn a range into an exact number or a missing value into zero. When two providers disagree, compare entity scope and freshness before calculating anything. Averaging parent-company and subsidiary counts produces a number with no clear meaning. For a threshold-based routing rule, define how a range that crosses the threshold is handled. A range spanning two sales segments should go through the team’s ambiguity rule, not whichever segment happens to be evaluated first.Worked account: accept the profile, hold the segment
A fictional CRM account represents the operating company Example Labs atexample.com. A lookup returns a profile with that website and the same operating-company name. It also returns an employee range of 51–200. Your routing policy assigns companies below 100 employees to one team and companies at or above 100 to another.
Choosing the midpoint, 125.5, would invent precision and route the account using a number nobody reported. A second result of 1,400 employees for a parent company does not resolve the ambiguity either. It describes a different entity.
Store identity acceptance separately from field acceptance. That lets a correct profile link proceed without forcing an unsupported segment decision. Before writing, resolve the existing CRM account ID and apply its field-ownership rules.