Company Name to Domain and LinkedIn Resolver: Batch, Clay

🪪 What can Company Identity Resolver do?

Give it a company name, and it returns the company's primary domain and LinkedIn company URL. Give it any combination of name, domain or LinkedIn URL, one company or a batch list, and it returns one canonical company identity per row: 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.

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?

⚔️ 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 (the domain stem, its hyphenated form such as orlando-weekly, and the name plus a legal suffix such as europa-science-ltd), then a DuckDuckGo search fallback, then an optional Serper (Google results API) backup that runs only when every free step came back empty. A row with no LinkedIn page is marked degraded: true and degradation_reason names the steps it tried.

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

📋 What data can Company Identity Resolver extract?

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

⚠️ 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.

⚠️ false and null mean different things on every row. false is a measurement: the actor looked and the answer was no. null is the absence of one: the actor could not look. When something it needed fails, the row comes back with degraded: true, a plain-language degradation_reason, and every field it could not measure set to null rather than to a confident false or 0. Filter on degraded before you trust a negative.

🛠️ 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.

📚 Batch mode: a list of names or domains in one run

Put company names in company_names, domains in domains, or both, one per line, and click Start. Every entry runs the same resolution path as a single lookup and writes its own row, in input order, with its own confidence_score and match_method. A row that fails returns a degraded row with degradation_reason set and the rest of the batch continues.

{
  "company_names": ["Stripe", "Notion", "Figma", "Linear", "Vercel"],
  "batchSize": 2
}

Returns five rows, one per name:

(Measured on a live run of build 0.0.27, 2026-09-19, batchSize 5, 19 seconds for the five rows.)

When company_names and domains have the same number of entries, name 1 is resolved with domain 1, name 2 with domain 2, and so on, which is the shape of a spreadsheet with both columns. When the lengths differ, each list contributes its own rows, names first. batchSize is how many companies resolve at the same time (default 2, maximum 10; the LinkedIn check runs through a residential proxy with a 5 second ceiling, and more concurrency means more timeouts, so raise it for speed only if you accept more unresolved rows). When either list has at least one entry, batch mode takes precedence over the single fields. The price per row is the same as a single lookup; a batch pays the Actor start event once per run instead of once per company. From the API, the same input works with POST /v2/acts/mambalabs~company-identity-resolver/runs.

🧪 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.

There is also an Actor start event at $0.00005, charged once per run per GB of memory. A batch run pays it once for the whole list.

The optional Serper backup search bills on your own Serper account, not through Apify: at most 2 queries per company, and only when the free steps found no LinkedIn page. Serper's published pricing (serper.dev, read 2026-09-17) is 2,500 queries free on signup, then $50 for 50,000 credits ($0.001 per query), with lower unit prices on larger packs. One credit per successful response.

💳 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.

⚠️ A cached repeat lookup is served instantly but is still billed. This actor prices per result row, and Apify charges that event for every row written to the dataset, whether the answer came from the network or from the 7 day cache. Corrected 2026-08-12: an earlier version of this section said repeat lookups inside the cache window were not charged. They are, and they always were. Measured on 2026-08-12, an identical lookup 16 minutes after the first was charged one result event. The cache saves you the wait and the platform usage, not the per-row price.

⌨️ Input

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

📤 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,
  "degraded": false,
  "degradation_reason": null,
  "run_date": "2026-06-21T09:36:04Z"
}

degraded is true when no LinkedIn company page was found, and degradation_reason lists the steps tried in order, for example

no LinkedIn company page found; steps tried: slug_pattern, duckduckgo_search, serper_search (skipped: no Serper key); last step: serper_search (skipped: no Serper key)

💡 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 come from the cache, so re-running a list is fast; every row is still billed, cached or not (see the cost section).
• Have a list already? Put it in company_names or domains and run once. One row per entry, same price per row, one Actor start event instead of one per company.

⚠️ 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 resolve many companies in one run?

Yes. Put names in company_names or domains in domains (one per line in the Console, a JSON array from the API) and every entry gets its own row. A failed row is marked degraded and does not stop the batch.

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.

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.

⚖️ Unofficial

This actor is unofficial. It is not affiliated with, sponsored by, or endorsed by LinkedIn, Microsoft or DuckDuckGo. It reads publicly available pages only, with no account and no authenticated session.

Built by Mamba Labs.