Company Identity Resolver Name Domain LinkedIn Match Clay

🪪 What can Company Identity Resolver do?

Give it any combination of company name, domain or LinkedIn URL and it returns one canonical company identity: name, primary domain and LinkedIn company URL, each with a 0 to 100 confidence score.

Give it whatever you have. It resolves the missing fields, cross-checks the ones you supplied, and flags disagreements rather than silently merging them.

📦 What you get	⚙️ Features and integrations
🪪 A canonical name, domain and LinkedIn URL 💯 Per-field and overall confidence, 0 to 100 ⚔️ Conflict detection, never a silent merge 🧾 13 flat fields, snake_case, one row per entity	🔄 Any input, any direction, name, domain or slug 🧬 Canonical name from the company's own JSON-LD 🧊 7 day cache, repeat lookups are free ⬇️ Export to JSON, CSV, Excel, HTML or XML

Bought by Clay users, RevOps teams, outbound agencies and agent builders who need a reliable dedupe and join key for company records. It is the join primitive the rest of a GTM stack hangs off.

🚫 This resolves identity, it does not enrich. It will not tell you headcount, industry or revenue. For that, join on the domain it returns and use Company Firmographic Enricher.

💡 Why use Company Identity Resolver?

If you want	Read these fields
A stable join key across systems	domain
The company's real name	name, name_confidence
Their LinkedIn page	linkedin_url, linkedin_confidence
To know whether to trust the match	confidence_score, match_method
To catch bad merges before they happen	match_method = "conflict"
What you originally supplied	input_company_name, input_domain, input_linkedin

⚔️ Conflicts are surfaced, never merged

When your inputs disagree, a domain that says one company and a LinkedIn slug that says another, the row comes back with match_method: "conflict" and a capped score.

That is the single most valuable thing this actor does. A resolver that quietly picks one side writes a bad join key into your CRM and you find out months later. This one hands the disagreement back to you.

🧭 How resolution works

1. Anchor the domain, which is the canonical key. A provided domain is validated by DNS. With no domain, a search bridges the name or LinkedIn slug to the company's own domain, ranking candidates by result position and stem similarity and excluding aggregator hosts.
2. Confirm identity on the homepage. The resolved homepage is fetched and its schema.org/Organization JSON-LD is read for the self-declared canonical name and the sameAs LinkedIn URL.
3. Anchor the LinkedIn URL. Preference order: the one you provided, then the homepage sameAs link, then a login-free slug pattern match validated by a HEAD request, then a search fallback.

Aggregator domains (LinkedIn, Crunchbase, Bloomberg, Wikipedia and the like) are excluded as candidate domains. Common names, holding companies and recent rebrands are scored down rather than guessed at.

▶️ Ready-to-run examples

Example	What it does
Company Name to Domain Finder	Resolve a company name to its primary domain
Same Company Conflict Checker	Check whether two records refer to the same company
Domain to LinkedIn Company URL Lookup	Resolve a domain to its LinkedIn company page
CRM Dedup Key Builder	Generate a dedupe key for CRM company matching
LinkedIn Slug to Company Domain	Reverse-resolve a LinkedIn slug back to the domain

📋 What data can Company Identity Resolver extract?

13 fields per entity, flat and snake_case, no nested objects.

Field	What it holds
name	The canonical company name, preferring the company's own declaration
domain	The primary domain, the canonical key
linkedin_url	The LinkedIn company URL
confidence_score	Overall 0 to 100 blend
domain_confidence, linkedin_confidence, name_confidence	Per-field scores
match_method	How the identity was resolved, including conflict
resolved	Whether a usable identity came back
input_company_name, input_domain, input_linkedin	Echoed back, so the row is self-describing
run_date	When the run happened

⚠️ Threshold on confidence_score rather than on resolved. Name-to-domain resolution is inherently ambiguous for very common names, holding companies and recent rebrands. The actor puts that ambiguity in the score instead of hiding it, which only helps if you read it. For a high-trust pipeline, gate on the score and route the rest to manual review.

🛠️ How to resolve a company to a canonical identity

1. Open the Input tab and supply whatever you have: company_name, domain, linkedin_url, or any mix.
2. Click Start.
3. Read domain as your join key and confidence_score as your gate.
4. Route any row with match_method: "conflict" to review rather than into your CRM.

🧪 Using it in Clay

Add an Apify enrichment column and map whichever columns you have. Every input is accepted as a string, which is what Clay sends.

Supplying more than one identifier is better, not worse: extra inputs are cross-checked rather than overridden, and a conflict between them is exactly the signal you want before a merge.

🔑 Using it as a dedupe key

Run it across two systems and join on domain. Because the domain is DNS-validated and aggregator hosts are excluded, it is stable in a way a name never is. Gate on domain_confidence when the domain came from a search rather than from your own input.

💵 How much does it cost to resolve a company identity?

You are charged once per entity resolved.

Plan	Per entity	Per 1,000 entities
Free	$0.007	$7.00
Bronze	$0.00665	$6.65
Silver	$0.0063	$6.30
Gold	$0.00595	$5.95

There is also an Actor start event at $0.00005, charged once per run per GB of memory.

💳 A low-confidence or conflicted result is still billed. The actor did the resolution work and a flagged conflict is a real, useful answer, often the most useful one it produces. Repeat lookups inside the 7 day cache window return instantly and are not charged.

⌨️ Input

Everything is on the Input tab. Supply at least one of the first three.

Field	Type	Default	What it does
company_name	string	none	The company name, however you have it written.
domain	string	none	Bare domain. Validated by DNS when supplied.
linkedin_url	string	none	A LinkedIn company URL or slug.
skipCache	string	"false"	"true" forces a fresh resolution.

📤 Output

One flat row per entity, exportable as JSON, CSV, Excel, HTML or XML.

{
  "input_company_name": "Stripe",
  "input_domain": null,
  "input_linkedin": null,
  "name": "Stripe",
  "domain": "stripe.com",
  "linkedin_url": "https://www.linkedin.com/company/stripe",
  "confidence_score": 96,
  "match_method": "search_then_jsonld",
  "domain_confidence": 95,
  "linkedin_confidence": 98,
  "name_confidence": 96,
  "resolved": true,
  "run_date": "2026-06-21T09:36:04Z"
}

💡 Tips

• Supply every identifier you have. Cross-checking is free and a surfaced conflict is worth more than a confident wrong answer.
• Join on domain, not on name. Names change; domains rarely do.
• Route match_method: "conflict" rows to a human. That is what the flag is for.
• Repeat lookups inside 7 days are free, so re-running a list to pick up new rows costs only the new ones.

⚠️ Known limits

Name-to-domain resolution is inherently ambiguous for very common names, holding companies and recent rebrands. The actor surfaces this in the confidence score rather than hiding it. Threshold on confidence_score for high-trust pipelines.

LinkedIn is a corroborating anchor, not a content source. It is validated login-free by HEAD request, slug pattern and public search. No personal profiles are read and no page content is extracted.

Public data only. No Crunchbase, no LinkedIn login, no paid third-party API.

Resolution quality depends on the search stage when you supply no domain. If you already have a domain, supply it: it is the canonical key and providing it skips the least certain step entirely.

Results are cached for 7 days. Set skipCache to "true" to force a fresh resolution.

❓ FAQ

What does match_method: "conflict" mean?

Your inputs disagreed. A domain pointed at one company and a LinkedIn slug at another. The score is capped and the row is handed back to you rather than merged.

Which field should I use as a join key?

domain. It is DNS-validated and aggregator hosts are excluded, so it is stable across systems in a way a company name is not.

Does it read LinkedIn profiles?

No. LinkedIn is validated login-free and no personal profile is ever read.

Why is confidence low on a company I recognize?

Usually a common name, a holding company or a recent rebrand. Supplying the domain removes the ambiguity entirely.

Can I give it just a LinkedIn slug?

Yes. It reverse-resolves the slug back to the company's own domain.

🧩 Want other GTM data?

Mamba Labs builds custom actors for B2B go-to-market teams. The public versions of that work live here on the Store, so our users get the same tooling we build under contract.

🧑‍💼 GTM Hiring Signal Scraper	🧱 Tech Stack Detector
📡 B2B Buying Signals Aggregator	🔑 Job Board Keyword Scanner
🔗 Domain to LinkedIn URL Resolver	🎯 ICP Fit Scorer
📋 Job Posting Monitor	📬 Domain Deliverability Checker
🏢 Company Firmographic Enricher	🌐 Company Social Presence Mapper
💰 Funding and Press Signal Scanner	🔄 Company Change-Event Feed
👤 People Finder and Email Verifier	🚀 Prospect Engine
🤖 AI Tooling Detector	📮 Outbound Stack Detector
📝 Publishing Frequency Tracker	✉️ Work Email Waterfall Finder
⏩ Sequencer Lead Push	🏅 Workplace Program Detector
👥 Team Page People Extractor	🧭 Company Discovery List Builder

Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything.

🛠️ Need something custom built for you or your team? Tell us what you are trying to find and we will build it. Talk to Mamba Labs.

🆘 Support

Something wrong, or a company the actor resolves incorrectly? Open an issue on the Issues tab with the inputs and the row, and we will look at it.

ℹ️ Sourcing and legal. This actor uses public data only: DNS, the company's own homepage and its schema.org JSON-LD, and login-free public search. No LinkedIn login, no personal profiles, no paid third-party API. You are responsible for how you use the output.

Built by Mamba Labs.