LinkedIn Company URL - Mass Profile Finder

LinkedIn Company URL Finder — Bulk Names to URLs and Titles

LinkedIn Company URL Finder turns a bulk list of company names into canonical LinkedIn company page URLs. Paste one name per line and every input row comes back as typed JSON with four stable keys — mySearch, queryId, linkedinUrl and info — and unmatched names optionally come back as empty rows so your output lines up one-to-one with your input. No LinkedIn account, cookie or session is used. Rows are written live as each lookup lands, so a long run never loses what it has already resolved.

⚠️ This is a name→URL resolver, not a company page scraper. It reads a public web search, takes the first linkedin.com/company/ result it sees, and returns that URL. There is no verification step and no confidence score. Read the constraint section below before you trust the output blindly.

What is LinkedIn Company URL Finder?

LinkedIn Company URL Finder is an Apify Actor that resolves company names to LinkedIn company page URLs in bulk. For each name you submit it runs one public web search, picks the highest-ranked linkedin.com/company/ result, normalises that URL to its canonical form, and pushes a single dataset row carrying the URL, the result title, your original name and its index.

No LinkedIn account, login or cookie is required — and no LinkedIn credential could help, because the Actor never sends a request to linkedin.com at all. It reads a public search engine's HTML results page and extracts the company link from it. The only credential involved is your Apify token.

• Resolve a LinkedIn company page URL for each company name you submit
• Return the search-result page title for the matched page (for example "Tesla - LinkedIn") so you can eyeball whether the match is right
• Return a "not found" row for every name that produced no LinkedIn company page, keeping input and output aligned
• Export as JSON, CSV or Excel, or read the dataset straight through the Apify API
• No proxy account, no session management, no HTML parsing on your side

⚠️ It resolves names to URLs — it does not verify the match

Four things about this Actor are worth knowing before your first run. None of them are hidden in the code; they are just rarely documented.

1. Matching is first-result-wins. Each name is combined with querySuffix (default "linkedin company") into one search query, sent to a public search engine's HTML results endpoint with your region as the locale parameter. The Actor walks the organic results in rank order and returns the first URL matching linkedin.com/company/. There is no name-similarity check, no confidence score, and no second opinion. A generic, ambiguous or shared company name can resolve to a different company's page. The info field is your check: compare it against mySearch before you act on a row.

2. It does not read the LinkedIn page. No employee count, follower count, industry, headquarters, "about" text or logo is returned, because the company page itself is never fetched. Four keys per row is the whole output.

3. A "not found" row and a "lookup failed" row look identical. When includeNotFound is true (the default), both a name with no LinkedIn company page in its results and a name whose lookup exhausted every retry produce the same row shape: linkedinUrl and info set to null. The dataset cannot tell them apart — the run log can, since a genuine miss logs "no LinkedIn company page found" and a failure logs the error.

4. "Not found" rows are charged. The Actor bills one row_result event per row pushed to the dataset, and not-found rows are pushed like any other. If you do not want to pay for misses, set includeNotFound to false and only matched companies are written. If you want the alignment but not the noise downstream, keep it on and filter — the exact filter is in the Output section.

What data does LinkedIn Company URL Finder collect?

Every run produces one row per unique company name, in one of two shapes: a resolved row or a not-found row. Both carry the same four keys.

Data Type	Key Fields	JSON Field Names
Resolved LinkedIn company page	Canonical company page URL, search-result page title	linkedinUrl, info
Input query row	The company name you submitted, its 1-based position after de-duplication	mySearch, queryId
Not-found / failed-lookup row	Same four keys, with the URL and title returned as null	linkedinUrl (null), info (null)

linkedinUrl is normalised before it is written. Whatever the search result points at — uk.linkedin.com/company/google, a /about subpath, a URL carrying tracking parameters — is reduced to https://www.linkedin.com/company/<slug>, with subpaths, query strings and fragments dropped. A linkedin.com link that is not a company page (a login page, a feed link) is deliberately not treated as a match; the Actor keeps scanning results.

info is the title of the matched search result, with HTML entities unescaped and inline markup stripped. mySearch echoes your input string exactly as you typed it. queryId is a 1-based counter over the de-duplicated input list.

Need more LinkedIn data?

This Actor is designed to be the first step in a chain — it produces the URLs that the deeper LinkedIn Actors consume. Once you have company URLs, LinkedIn Jobs Scraper by Multiple Keywords & Locations pulls the roles those companies are hiring for, and LinkedIn Post Comments Scraper with Commenter Profile Details covers engagement on their posts. For people-side research, LinkedIn Similar Profiles Finder and LinkedIn Thought Leader Finder work from profiles rather than company names.

How does LinkedIn Company URL Finder differ from the official LinkedIn API?

LinkedIn's official developer surface is partner-gated: the Marketing Developer Platform and the Sales Navigator Application Platform both require you to apply to a programme and be approved before your application can call them. LinkedIn Company URL Finder needs no such approval, because it reads public search results rather than LinkedIn's API.

Feature	LinkedIn partner APIs	LinkedIn Company URL Finder
Approval process	✅ Partner programme application and approval required	❌ None — run it from the Apify Console
Credentials	LinkedIn developer application and OAuth tokens	Your Apify token
Input you supply	Identifiers your application is authorised to query	Free-text company names, one per line
Data returned	Whatever your approved scopes grant	Company page URL and result title — four keys
Rate limits and quotas	Published in LinkedIn's developer documentation	Bounded by your Apify run, maxConcurrency and the retry ladder
Time to first result	Gated on programme approval	Paste names and press Start

Consult LinkedIn's current developer documentation for the exact programmes, scopes and quotas that apply to you; those terms change and are deliberately not reproduced here.

Use the official APIs when you need a sanctioned production integration with contractual footing and access to LinkedIn's own organisation data. Use LinkedIn Company URL Finder when you have a list of company names, need their LinkedIn URLs today, and do not have — or do not want to wait for — partner approval.

Why do developers and teams look up LinkedIn company URLs?

The LinkedIn company URL is a join key. Almost every LinkedIn workflow starts by turning a company name into one, and doing it by hand is the slowest step in the pipeline.

For sales and lead generation teams

A prospect list almost never arrives with LinkedIn URLs attached — it arrives as company names from a conference roster, a funding announcement or an exported CRM view. Paste the name column into queries, run once, and join the result back on mySearch to get a linkedinUrl for every account. From there the URL feeds account research, connection mapping and outreach sequencing. Keeping includeNotFound on means the returned list has exactly as many rows as your source list, so a spreadsheet paste stays aligned without a manual reconciliation pass.

For recruiters and talent sourcers

Target-employer lists are built from company names too. Resolve them in bulk, then use the linkedinUrl values as the entry point for hiring research. Because the Actor never touches a LinkedIn session or cookie, running a large name list does not involve a recruiter's own account at all. Sort on info to spot the rows where the returned title does not resemble the company you meant, and correct those by hand before the list goes into a sourcing tool.

For RevOps and data teams

CRM hygiene is the recurring version of this job. Export the accounts missing a LinkedIn URL, resolve them, and write linkedinUrl back keyed on mySearch. Schedule the run on Apify and point a webhook at your enrichment endpoint, and the backfill becomes a standing process rather than a quarterly project. queryId gives you a stable within-run ordinal for logging, and the null-URL rows tell you exactly which accounts still need manual attention.

For AI engineers and agent builders

An agent asked "find the LinkedIn page for these thirty companies" needs a tool that takes plain names and returns structured output — not one that returns HTML for the model to parse. This Actor is callable over the Apify API as a standard HTTP-triggered run, and every response is typed JSON with four fixed keys. Wire it as a tool definition, branch on whether linkedinUrl is null, and hand the resolved URLs to the next tool in the chain. There is no selector or parsing step inside the agent loop.

How to find LinkedIn company URLs (step by step)

LinkedIn Company URL Finder runs on Apify. Start it from the Apify Console or call it through the Apify API.

1. Open LinkedIn Company URL Finder on Apify and click Try for free
2. Paste your company names into Company Names (bulk input) (queries) — one per line, and the only required input
3. Pick a Search Region (region) — us-en is the default and returns English result titles like "Tesla - LinkedIn"
4. Decide whether Include "not found" rows (includeNotFound) stays on — it is on by default, and it affects both output alignment and what you are charged for
5. Click Start, watch rows stream into the dataset live, then export as JSON, CSV or Excel

Everything under Advanced Settings — querySuffix, requestTimeout, maxRetries, retryBackoff — has a working default. Leave it alone unless a run is misbehaving.

What to do when the search layer changes

The Actor is maintained, and the output schema is fixed at four keys — mySearch, queryId, linkedinUrl, info — so a change to the upstream results page is handled inside the Actor rather than in your integration. Your field names and types do not move on your end.

⬇️ Input

Every parameter below comes from the Actor's input schema. queries is the only required one; everything else has a default that works.

Parameter	Required	Type	Description	Example Value
queries	Yes	array	Company names, one per line. A list of strings, a list of { "url": ... } / { "name": ... } objects, or a single comma- or newline-separated string are all accepted. Entries are trimmed, blanks dropped, and duplicates removed case-insensitively.	["Tesla", "OpenAI", "Stripe"]
region	No	string	Region and language used for the lookup. One of us-en, uk-en, ca-en, au-en, in-en, wt-wt (worldwide, no region). Default "us-en".	"uk-en"
maxConcurrency	No	integer	How many company lookups run in parallel. Minimum 1, maximum 100. Default 10.	10
querySuffix	No	string	Phrase appended to each company name to surface its LinkedIn page. Default "linkedin company".	"linkedin company"
includeNotFound	No	boolean	When on, companies with no LinkedIn page still get a row with a null URL, so output lines up 1-to-1 with input. Default true.	true
requestTimeout	No	integer	Per-request timeout in seconds before a lookup is retried on a fresh IP. Minimum 5, maximum 120. Default 20.	20
maxRetries	No	integer	Maximum retry attempts on residential per request before the lookup is marked failed. Minimum 1, maximum 12. Default 6.	6
retryBackoff	No	integer	Base backoff multiplier in seconds applied between retries, growing with each attempt and capped at ~8s. Minimum 1, maximum 10. Default 2.	2
proxyConfiguration	No	object	Proxy settings. The Actor starts every run with no proxy and escalates automatically on a block. Default {"useApifyProxy": false}.	{"useApifyProxy": false}

Common pitfall: leaving includeNotFound at its default true and then treating the row count as a match count. Every unmatched name is still a row, and still a charged row_result event. Either turn it off, or filter on linkedinUrl downstream.

Example input

{
  "queries": ["Tesla", "OpenAI", "Stripe", "Microsoft", "Notion Labs"],
  "region": "us-en",
  "maxConcurrency": 10,
  "querySuffix": "linkedin company",
  "includeNotFound": true,
  "requestTimeout": 20,
  "maxRetries": 6,
  "retryBackoff": 2,
  "proxyConfiguration": { "useApifyProxy": false }
}

⬆️ Output

One dataset row per unique company name, with the same four keys in the same order every time: mySearch, queryId, linkedinUrl, info. No key is ever omitted — an unmatched name returns null for the URL and the title rather than dropping the fields, so downstream code never needs a presence check. Rows are pushed live during the run. Export as JSON, CSV or Excel, or read the dataset through the Apify API.

Resolved company row

{
  "mySearch": "Tesla",
  "queryId": 1,
  "linkedinUrl": "https://www.linkedin.com/company/tesla-motors",
  "info": "Tesla - LinkedIn"
}

Not-found row

Produced when no linkedin.com/company/ result appears for the name, or when the lookup failed after exhausting its retries — and only when includeNotFound is true.

{
  "mySearch": "Notion Labs",
  "queryId": 5,
  "linkedinUrl": null,
  "info": null
}

Filtering out not-found rows

Because both shapes carry the same keys, one truthiness test on linkedinUrl separates them:

matched = [row for row in items if row["linkedinUrl"]]
misses  = [row["mySearch"] for row in items if not row["linkedinUrl"]]

To avoid producing — and paying for — those rows at all, set includeNotFound to false. The Actor bills one row_result event per row it pushes, so suppressing the misses removes them from both the dataset and the bill. Keep them when input/output alignment matters more than row count.

How does LinkedIn Company URL Finder compare to other LinkedIn company URL scrapers?

Checked on the Apify Store on 25 July 2026. The most established alternative is anchor/LinkedIn-company-url-finder; two further listings carrying this same name, api-empire/linkedin-company-url-mass-profile-finder and scrapier/linkedin-company-url-mass-profile-finder, document an input and output shape identical to each other.

Feature	LinkedIn Company URL Finder	Generic alternative (as documented on their listings, 25 July 2026)
Output keys	✅ mySearch, queryId, linkedinUrl, info — documented per key	✅ anchor documents the same four keys
URL normalisation	✅ Every match reduced to https://www.linkedin.com/company/<slug>	❌ anchor's output example shows country-subdomain URLs such as https://uk.linkedin.com/company/google; normalisation not documented
Input flexibility	✅ String list, object list, or one delimited string — all accepted, de-duplicated case-insensitively	❌ anchor's documented input example is a single newline-separated string; de-duplication not documented
Not-found handling	✅ includeNotFound documented, with the exact downstream filter and its billing effect	❌ Not documented on anchor's listing
Block handling	✅ DIRECT → DATACENTER → RESIDENTIAL ladder with documented timeout, retry and backoff defaults	❌ anchor's listing states no LinkedIn session or cookies are needed; a proxy ladder or retry policy is not documented

If you are building an AI agent or a RAG pipeline, the output-format row is the decision-maker — parsing HTML inside an agent loop is a reliability failure mode, not a feature. And if you are joining results back onto a spreadsheet, the not-found row is the one that decides whether your join lines up.

How many company URLs can you find with LinkedIn Company URL Finder?

There is no hard cap in the Actor itself. queries has no maximum length in the schema, and the Actor creates one task per unique name and runs them all — the number of rows you get back is the number of unique names you submitted, or the number that matched if includeNotFound is off.

What controls the pace is maxConcurrency: 1 to 100 parallel lookups, default 10, clamped to that range in code before the semaphore is created, so the schema maximum is the real maximum. Each worker also waits a short random moment before its first request so a burst of workers does not all fire at once. Higher concurrency finishes sooner but concentrates requests, which makes a block — and therefore escalation up the proxy ladder — more likely.

Duplicate names are collapsed before any lookup runs, and the comparison is case-insensitive, so Tesla and tesla produce one row rather than two. Practical run size is governed by your own Apify account's compute and dataset limits.

Integrate LinkedIn Company URL Finder and automate your workflow

LinkedIn Company URL Finder works with any language or tool that can send an HTTP request.

REST API integration

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/linkedin-company-url-mass-profile-finder").call(run_input={
    "queries": ["Tesla", "OpenAI", "Stripe"],
    "region": "us-en",
    "maxConcurrency": 10,
    "includeNotFound": True,
})

for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    if row["linkedinUrl"]:
        print(row["mySearch"], "->", row["linkedinUrl"], "|", row["info"])
    else:
        print(row["mySearch"], "-> no LinkedIn company page found")

Works in Python, Node.js, Go, Ruby, cURL.

Automation platforms (n8n, Make, LangChain)

In n8n, use the Apify node — or an HTTP Request node pointed at the Apify run endpoint with your token — and pass the same JSON input shown above; a Google Sheets node on either side turns it into a name-in, URL-out sheet workflow. In Make, the Apify module supports run-and-wait, so the dataset items can be mapped straight into an Airtable or HubSpot step. In LangChain or any other agent framework, wrap the run endpoint as a tool that takes a list of company names and returns the four-key rows unchanged — no output parser needed.

Apify schedules and webhooks

Put the Actor on an Apify schedule to re-resolve a growing account list on a fixed cadence, and attach a webhook on run success so your own service is notified the moment the dataset is ready. Both are configured on the Actor in the Apify Console, with no code.

Is it legal to look up LinkedIn company URLs?

Resolving a company name to its public LinkedIn company page URL is broadly treated as permissible: the URL is a public web address, and the Actor only reads results a search engine already publishes to anonymous visitors.

The output is company-record data. It contains no person-level fields — the four keys are the name you submitted, its index, a company page URL and that page's result title — so the personal-data regimes that govern profile scraping do not attach to this output the way they would to a people scraper. What does apply is contractual and database-related: LinkedIn's terms of service, the search engine's terms, and any local database or unfair-competition rules covering systematic reuse of a compiled list.

Consult legal counsel for commercial use cases involving bulk personal data, or before reselling a resolved company list as a standalone product.

❓ Frequently asked questions

Does LinkedIn Company URL Finder work without a LinkedIn account?

Yes, and a LinkedIn account would not help. The Actor never sends a request to linkedin.com — it reads a public search engine's HTML results page and extracts the company link from it. No login, no cookie, no session. The only credential you need is your Apify token.

How does it actually match a company name to a page?

It appends querySuffix (default "linkedin company") to your name, sends that one query to a public search engine's HTML results endpoint with region as the locale parameter, then walks the organic results in rank order and returns the first URL matching linkedin.com/company/. That is the whole matching logic: first result wins. There is no name-similarity scoring and no verification pass, which is why info is returned — it is your check on the match.

What happens when a company name matches nothing, or matches the wrong company?

Two different outcomes. Nothing matched: if no linkedin.com/company/ URL appears anywhere in the results, and includeNotFound is true, you get a row with linkedinUrl and info set to null; with it false, no row is written for that name. Wrong company matched: the Actor cannot detect this, because it does not compare the result back to your input. A generic name, an acronym, or a name shared across industries can resolve to a different organisation's page. Compare info against mySearch for each row — a mismatched title is the signal. Adding a disambiguating word to the input name (a city, a suffix like Inc) usually fixes it, and querySuffix can be adjusted if a whole batch resolves badly.

Am I charged for "not found" rows?

Yes. The Actor bills one row_result event for every row it pushes to the dataset, and not-found rows are pushed like any other when includeNotFound is true. Set it to false to write — and pay for — matched companies only. If you need the 1-to-1 alignment, keep it on and filter downstream with row["linkedinUrl"].

How often is the scraped data updated?

Every run is a live lookup. Nothing is cached between runs and no stored index is consulted — each company name triggers a fresh search at the moment the run executes. Re-run whenever you need current results.

Can I look up private or login-gated LinkedIn content?

No. The Actor returns a public company page URL and the title of the search result that pointed at it. It does not open the company page, so nothing behind LinkedIn's login wall — employee lists, follower counts, page analytics, private company data — is reachable, and no such field exists in the output.

Does it deduplicate my input, and does queryId match my spreadsheet row numbers?

It deduplicates. Names are trimmed, blanks dropped, and repeats removed case-insensitively with the first occurrence kept, so Tesla and tesla produce one row. That means queryId is a 1-based index into the de-duplicated list, not into your original file — if your input contained duplicates, the numbers will not line up. Join on mySearch instead, which echoes your input string exactly as submitted.

How does LinkedIn Company URL Finder handle blocking and rate limiting?

Through a one-way proxy ladder plus per-request retries. Every run starts DIRECT, with no proxy at all, and requests are sent with browser-grade HTTP impersonation rather than a default client signature. The first time a request is blocked or throttled — a 202, 403, 429, 500, 502, 503 or 504, a timeout, or a 200 that comes back with no organic results at all — the run escalates one rung to a datacenter proxy, and on a further block to a residential proxy. Escalation is one-way and run-global: once the run reaches residential, every remaining request stays there. Each attempt draws a fresh IP. On the residential rung the Actor retries up to maxRetries times (default 6), backing off retryBackoff seconds (default 2) multiplied by the attempt number, capped at ~8s, plus a small random jitter; each individual request is abandoned after requestTimeout seconds (default 20). A lookup that still fails is logged and, if includeNotFound is on, written as a null row — the run continues with everything else.

Do I need to configure a proxy?

No. proxyConfiguration defaults to {"useApifyProxy": false} and the run always begins with no proxy, which is the cheapest and fastest rung. The datacenter and residential configurations used for fallback are prepared automatically at startup from Apify Proxy; the only value read from your proxyConfiguration input is apifyProxyCountry, which localises those fallback rungs. If a rung is unavailable to your account, the Actor logs a warning at startup and works with what it has.

Does it work for AI agent workflows and LLM pipelines?

Yes. It is callable as a standard HTTP endpoint through the Apify API, so LangChain, CrewAI, n8n or a hand-written tool definition can invoke it and receive typed JSON. Every row has the same four keys with the same types on every run, so an agent branches on whether linkedinUrl is null and passes the URL to the next tool — no HTML, no selectors, no parsing step before the model sees it.

How does it compare to other LinkedIn company URL finders?

Checked on the Apify Store on 25 July 2026: anchor/LinkedIn-company-url-finder is the most established, documents the same four output keys, links a video tutorial and an n8n template, and states on its listing that no LinkedIn session or cookies are needed. Its documented input example is a single newline-separated string, and its output example shows country-subdomain URLs such as https://uk.linkedin.com/company/google. The listings at api-empire/linkedin-company-url-mass-profile-finder and scrapier/linkedin-company-url-mass-profile-finder document an input and output shape identical to each other. What this README documents that the others do not: canonical www.linkedin.com/company/<slug> normalisation, case-insensitive input de-duplication and its effect on queryId, the not-found row's billing consequence with the exact filter, and the DIRECT → DATACENTER → RESIDENTIAL ladder with its real defaults.

🔗 Related scrapers

Scraper Name	What it extracts
LinkedIn Jobs Scraper by Multiple Keywords & Locations	Job listings across several keyword and location combinations
LinkedIn Post Comments Scraper with Commenter Profile Details	Post comments together with each commenter's profile detail
LinkedIn Similar Profiles Finder	Profiles LinkedIn associates with a given profile
LinkedIn Thought Leader Finder	Active voices and their posts in a topic area
Google Maps Scraper with Lead Contact Enrichment	Local business records with contact enrichment

💬 Your feedback

Found a bug, or a company name that resolves to the wrong page? We want to know. Open an issue on the Actor's Issues tab — reports that include the exact input list and the row you got back are the fastest to reproduce and fix. Field requests are welcome too, and so is a note about which region setting worked best for your market.