LinkedIn Company URL - Mass Profile Finder With Firmographics

LinkedIn Company URL Finder — Industry, Size, HQ and Followers

LinkedIn Company URL - Mass Profile Finder With Firmographics turns a plain list of company names into LinkedIn company page URLs plus a full firmographic record — industry, companySize, employeesOnLinkedin, followerCount, headquarters, foundedYear, website and specialties — as typed JSON with no HTML parsing on your side. It runs logged-out: no LinkedIn account, no cookie, no session. Paste your company list, press Start, and export as JSON, CSV or Excel.

⚠️ A company name is resolved by web search, and the first LinkedIn company result wins. Each name is sent to DuckDuckGo's HTML endpoint as <your name> linkedin company, and the highest-ranked linkedin.com/company/ URL on that result page is taken as the match. There is no disambiguation step, no candidate list and no confidence score — a name that matches several companies resolves to whichever page ranks first, silently. The two fields to check are info, the search result's own title, and companyName, the official name read off the resolved LinkedIn page: when either disagrees with mySearch, that row needs a human. Distinctive, unambiguous names resolve cleanly; short, generic, franchised or recently renamed names are exactly where a silent mismatch happens.

What is LinkedIn Company URL - Mass Profile Finder With Firmographics?

It is an Apify Actor that resolves company names to their public LinkedIn company pages in bulk and then enriches each resolved page into a flat firmographic row — up to 23 keys per company, the same shape on every row of every run.

No LinkedIn account, login or cookie is required, and there is no field to supply one. Both the name lookup and the company-page fetch run anonymously over plain HTTP with browser TLS impersonation. Fields LinkedIn only shows to a signed-in visitor — funding, page verification, company phone — are deliberately not returned rather than guessed at.

It is built for sales and RevOps teams enriching account lists, market researchers mapping an industry, and developers or AI engineers feeding company records into their own pipelines.

What LinkedIn company data is publicly available to scrape?

LinkedIn renders a real company overview page to signed-out visitors: the company's name, tagline, About text, industry, size band, headquarters, founded year, website, specialties, logo, follower count and the number of members who list it as their employer. What it withholds from a guest is the money and the people, not the company profile.

Data Category	Public to a signed-out visitor	Needs a LinkedIn login
Company name, tagline, About description	✅	—
Industry, size band, headquarters, founded year	✅	—
Website, specialties, logo, company URN	✅	—
Follower count and employees-on-LinkedIn count	✅	—
Related pages: people also viewed, affiliated, showcase	✅ slugs only	✅ numeric page IDs
Funding rounds and investor list	❌	✅
Page verification badge and company phone number	❌	✅
Employee list — who actually works there	❌	✅
Page administrators and internal page analytics	❌	❌ Never returned

LinkedIn Company URL - Mass Profile Finder With Firmographics only returns publicly visible data — what any visitor sees on the company overview page. Nothing behind a login wall.

What data can I extract with LinkedIn Company URL - Mass Profile Finder With Firmographics?

Every row carries the lookup result, the company's public identity, its firmographic profile and the related-page slugs LinkedIn shows alongside it. Twenty-three top-level keys with both toggles on.

Field Name	Description
mySearch	The company name you submitted, trimmed. Join results back to your source list on this
queryId	1-based index into the de-duplicated input list. Not your spreadsheet row number if your list contained duplicates
linkedinUrl	Canonical https://www.linkedin.com/company/<slug> URL, stripped of subpaths, query strings and fragments. null when no LinkedIn company page was found
info	Title of the search result the URL came from, e.g. "Tesla - LinkedIn". Read from the search results page, not from LinkedIn itself. null on unmatched rows
companyName	Official company name as published on the resolved LinkedIn page — the field to compare against mySearch to confirm a match
companySlug	The slug segment of the resolved URL, lowercased
companyUrn	LinkedIn's numeric organization ID, returned as a string. Stable across renames, so it is the right deduplication key
industry	LinkedIn's own industry label, e.g. "Motor Vehicle Manufacturing"
companySize	LinkedIn's size band exactly as published, e.g. "10,001+ employees"
companySizeRange	Object with start and end integers, parsed from companySize. Always present as an object
followerCount	Integer count of the page's LinkedIn followers
employeesOnLinkedin	Integer count of members who list this company as their employer. A LinkedIn membership figure, not a headcount
foundedYear	Four-digit founding year as an integer. Only some companies publish one
website	The company's own website URL
headquarters	Object with country, state, city, postalCode, line1. null when the page publishes no usable address
specialties	Array of strings, split from LinkedIn's comma-separated specialties list
tagline	The short positioning line under the company name
companyDescription	The full About text
logoUrl	Company logo image URL, rewritten to the 400×400 variant
relatedCompanies	Merged, de-duplicated array of every slug in the three arrays below
similarCompanies	Slugs from LinkedIn's "people also viewed" section
affiliatedCompanies	Slugs of affiliated company pages
showcasePages	Slugs of the company's showcase pages

The two nested objects

Field Name	Description
companySizeRange.start	Lower bound of the size band as an integer, e.g. 10001. null when no band was published
companySizeRange.end	Upper bound, e.g. 5000. null for open-ended bands such as "10,001+ employees"
headquarters.country	Country from the page's structured address
headquarters.state	State or region
headquarters.city	City. When only a plain "City, State" label is published, it is split on the first comma
headquarters.postalCode	Postal code, where published
headquarters.line1	Street address, where published

What LinkedIn publishes and what the Actor derives

Most of the row is copied from LinkedIn, not computed. Knowing which is which tells you what to trust when a value looks odd.

Published by LinkedIn, passed through as-is: companyName, companyUrn, industry, companySize, followerCount, employeesOnLinkedin, website, companyDescription, similarCompanies, affiliatedCompanies, showcasePages.

Published by LinkedIn, reshaped by the Actor: specialties is LinkedIn's single comma-separated string split into an array — a specialty that itself contains a comma will split into two entries. foundedYear is the year extracted from LinkedIn's founded field. headquarters prefers the page's structured postal address and falls back to splitting a plain "City, State" label. tagline is cut out of the page's meta description, which is also where followerCount is read from. logoUrl is LinkedIn's logo URL with the size segment rewritten to company-logo_400_400.

Derived entirely by the Actor: companySizeRange is companySize parsed into integers. companySlug is taken from the resolved URL. relatedCompanies is the three slug arrays merged and de-duplicated. queryId is a run-assigned index, and mySearch is an echo of your input.

info is the odd one out: it is the search engine's result title, not a LinkedIn field, which is why its wording can shift with searchRegion while the company itself does not change.

🤖 Add-on: Need additional LinkedIn data?

Once you have linkedinUrl for an account list, LinkedIn Profile Company Enrichment Scraper takes those URLs further into full profile and company records. LinkedIn Jobs Scraper With Salary Range Filters turns the same company list into that company's open roles, which is the fastest read on where a business is actually investing. If you are researching the people rather than the entity, LinkedIn Profile Seniority Title Filter narrows a profile list down to decision-makers.

How company names are matched to LinkedIn pages

This is the part worth understanding before you run 5,000 names through it, so here it is in full.

The lookup. Each name is combined with linkedinQuerySuffix — "linkedin company" by default — into a single query and sent to DuckDuckGo's HTML search endpoint, with searchRegion supplied as the region and language code. The Actor does not use LinkedIn's own search, which is behind a login wall for anonymous callers, and it does not guess slugs from the company name.

The match. The organic results are parsed in rank order and the first URL matching linkedin.com/company/ is taken. A LinkedIn link that is not a company page — a login page, a feed URL, a personal profile — is skipped rather than accepted. The winning URL is then reduced to its canonical https://www.linkedin.com/company/<slug> form, so /about, /jobs and tracking parameters never reach your output.

Ambiguity. There is none handled. The first LinkedIn company result wins and no alternatives are recorded. No score, no candidate array, no ambiguity flag. What you get instead are two verification handles: info, what the search engine titled the result, and companyName, the official name on the page the Actor actually opened. A row where mySearch reads "Apex Logistics" and companyName comes back as "Apex Logistics International" is a plausible match; one that comes back as an unrelated business is a mismatch, and only that comparison will tell you.

No match. When no linkedin.com/company/ URL appears in the results, or the search request itself fails after all retries, the outcome depends on includeUnmatched. With it on — the default — you get a row with linkedinUrl and info set to null and every firmographic field nulled, so your output lines up 1-to-1 with your input. With it off, that name produces no row at all and disappears from the dataset silently. There is no error row, no errorReason key and no status field in either case: a null linkedinUrl is the only signal that a name did not resolve.

Then the enrichment. When enrichFirmographics is on, the Actor opens the resolved page at https://www.linkedin.com/company/<slug>/ and parses it. If that page redirects a guest to a login or auth wall, or comes back without a single recognisable company signal, the URL and slug are kept and every firmographic field is set to null — the row is never dropped and no value is ever invented.

Why not build this yourself?

LinkedIn publishes no public API that resolves an arbitrary company name to a company page. Its Marketing and Talent APIs are partner-gated and scoped to organizations you already administer, so name-to-URL resolution across the open market means reading public surfaces — and that is where the real work sits.

• The resolution step is a search problem, not a scraping problem. LinkedIn's own company search is closed to anonymous callers, so the lookup has to go through a general search engine, with a query suffix tuned to bias LinkedIn's page to the top and a rank-ordered filter that rejects login pages and personal profiles masquerading as matches.
• HTTP 999. LinkedIn's throttle status is neither a 4xx nor a ban, and clearing it needs a genuinely different exit IP plus backoff, not a retry on the same connection. Treat it as a failure and you will report empty firmographics for companies whose pages are perfectly public.
• Guest walls do not arrive as errors. A login or auth-wall page comes back as a redirect or a success status, so the only reliable tests are the final resolved URL and whether recognisable company signals are actually present in the body — which is why this Actor checks for companyName, companyUrn, followerCount, employeesOnLinkedin and industry before trusting a page at all.
• Two different HTTP stacks. The search endpoint and LinkedIn's company page do not tolerate the same client fingerprint. This Actor uses a Rust-backed browser-impersonating client for the search and a Chrome-TLS client for LinkedIn, which is two dependency surfaces to maintain instead of one.
• The parse has to survive redesigns. Firmographics are read most-stable-source-first — the page's JSON-LD Organization node, then Open Graph and meta tags, then the About-us definition list — so a single markup change does not blank a column.
• Proxy economics. Direct requests work most of the time and cost nothing; residential works nearly always and costs money. Getting the escalation order right, and only ever ratcheting it upward, is the difference between a cheap bulk run and an expensive one.

How to use LinkedIn Company URL - Mass Profile Finder With Firmographics

It runs on Apify. Start it from the Apify Console or call it through the Apify API — your Apify token is the only credential involved, and no LinkedIn login is used at any point.

1. Open the Actor on Apify and click Try for free
2. Paste your company names into Company Names to Enrich (companyNames), one per line. This is the only required field
3. Leave Enrich With Firmographics (enrichFirmographics) on for the full record, or turn it off for a URL-only run that returns just four keys per company
4. Optionally set Search Region (searchRegion) to match where your companies are based, and raise or lower Parallel Companies (lookupConcurrency)
5. Decide on Keep Unmatched Companies (includeUnmatched) — on keeps your output aligned 1-to-1 with your input, off drops names that did not resolve
6. Click Start, then export as JSON, CSV or Excel

A run that reaches the Actor with companyNames empty — possible over the API, where the Console form would block it — logs a "No company names provided in input" warning, exits cleanly, and pushes nothing. It is not an error and it is not charged.

Leave the proxy off to begin with. The Actor starts on a direct connection and escalates on its own only when it is pushed back.

How to resolve company names in bulk

Bulk is the default mode, not a special case. companyNames is a list and every name in it is processed in the same run, with up to lookupConcurrency companies resolved and enriched in parallel — 1 to 100, defaulting to 10.

The list is de-duplicated case-insensitively before the run starts, keeping the first spelling of each name. Because rows are written the moment each company finishes, dataset order follows completion order rather than input order — sort on queryId if you need your original sequence back. There is no cap on how many names one run accepts; run size is bounded by your Apify usage limits, not by the Actor.

What can you do with LinkedIn company firmographic data?

• 🧲 A demand-gen marketer building an ICP list filters a raw account list on industry and companySizeRange.start to isolate mid-market manufacturers before spending anything on outreach.
• 📊 A RevOps analyst cleaning a CRM backfills missing linkedinUrl, website and headquarters.country values against existing accounts, joining on mySearch and deduplicating on companyUrn so renamed companies do not create doubles.
• 🔎 A market researcher mapping a category seeds one run with three known players, then feeds the returned similarCompanies and affiliatedCompanies slugs back in as the next run's input to expand the map outward.
• 🤖 An AI engineer building a company-research agent indexes companyDescription, tagline and specialties into a vector store, so the agent answers "which of our accounts sell into logistics" from real page text rather than from a guess.
• 📈 A growth analyst tracking momentum re-runs the same account list weekly and diffs followerCount and employeesOnLinkedin per companyUrn to spot which targets are actually growing.

Every one of these is callable from an agent framework over the Apify API, since the Actor is a standard HTTP-triggered run returning typed JSON.

How does it handle rate limits and blocking?

Three mechanisms, all automatic, and all applied to both the name lookup and the LinkedIn company-page fetch.

A proxy ladder that only ratchets upward. Every run starts DIRECT with no proxy at all. The first time a request is blocked or throttled, the run escalates to an Apify datacenter proxy; the next time, to Apify residential — and it stays on residential for the rest of the run rather than dropping back. The ladder is run-global and shared by every parallel worker, so one company hitting a wall raises the floor for all of them.

HTTP 999 handling. LinkedIn's throttle status is added to the retryable set for the company-page fetch, alongside 202, 403, 429, 500, 502, 503 and 504. Each retry requests a fresh exit IP. Attempts per request are capped at maxRetries plus four, and once the run is on residential it stops after maxRetries further attempts. Backoff grows with the attempt number, capped at 8 seconds, with up to 0.6 seconds of random jitter on top. Each company also starts with a random delay of up to 1.2 seconds, which is what keeps a 100-way concurrent run from arriving as a burst.

Soft-block detection on the lookup. A search response that returns HTTP 200 with no organic results is treated as a soft block, not as "this company has no LinkedIn page", and triggers the same escalate-and-retry path. On the LinkedIn side, a redirect to a login or auth-wall URL is recognised as an authentication gate rather than a block, so the Actor stops retrying it and nulls the firmographics instead of burning residential bandwidth on a page it will never be shown.

There is no CAPTCHA solving and no headless browser — requests are plain HTTP with browser TLS impersonation. When a company still cannot be read after all of that, the row is written with nulls rather than dropped, provided includeUnmatched is on.

⬇️ Input

Read straight from the Actor's input schema. companyNames is the only required parameter.

Parameter	Required	Type	Description	Example Value
companyNames	Yes	array	Company names to resolve, one per line. Each is matched to a LinkedIn company page and, when enrichment is on, enriched with firmographics.	["Tesla", "OpenAI", "Stripe"]
enrichFirmographics	No	boolean	Opens each resolved company page and adds the 15 firmographic keys. Off returns the four lookup keys only. Default true.	true
includeRelatedCompanies	No	boolean	Adds similarCompanies, affiliatedCompanies, showcasePages and the merged relatedCompanies array. Only takes effect when enrichFirmographics is on. Default true.	true
searchRegion	No	string	Region and language for the name lookup: "us-en", "uk-en", "ca-en", "au-en", "in-en", or "wt-wt" for worldwide. Default "us-en".	"uk-en"
lookupConcurrency	No	integer	Companies resolved and enriched in parallel. Minimum 1, maximum 100, default 10.	20
includeUnmatched	No	boolean	Keeps a null-filled row for companies with no LinkedIn page so output aligns 1-to-1 with input. Off drops them entirely. Default true.	true
linkedinQuerySuffix	No	string	Phrase appended to each name to surface its LinkedIn page. Default "linkedin company".	"linkedin company"
requestTimeout	No	integer	Per-request timeout in seconds, for both the lookup and the company-page fetch. Minimum 5, maximum 120, default 20.	20
maxRetries	No	integer	Retry attempts per request before giving up, each on a fresh proxy IP. Minimum 1, maximum 12, default 6.	6
retryBackoff	No	integer	Base multiplier in seconds for the exponential backoff between retries. Minimum 1, maximum 10, default 2.	2
proxyConfiguration	No	object	Apify Proxy settings. Default {"useApifyProxy": false}. See the note below on what is actually read from it.	{"useApifyProxy": false}

⚠️ proxyConfiguration is read for one value only: the proxy country. Whatever you set for useApifyProxy or for proxy groups, the run still starts DIRECT and climbs the datacenter-then-residential ladder on its own — switching Apify Proxy on in the form does not start you at the datacenter rung. A country selection does carry through, and is applied to both fallback rungs.

Five further behaviours worth knowing, all from the Actor's own input handling:

• Undocumented aliases are accepted. companyNames also answers to queries, linkedinQuerySuffix to querySuffix, searchRegion to region, includeUnmatched to includeNotFound, and lookupConcurrency to maxConcurrency. An input JSON written for a base-model company URL finder runs here unchanged, and the schema-named key wins when both are present.
• companyNames tolerates more than an array. A single newline- or comma-separated string is split into names, and objects carrying a url or name property are unwrapped, so list-style input from an upstream step does not need reshaping.
• Names are de-duplicated case-insensitively before the run starts, keeping the first spelling seen. queryId indexes the de-duplicated list, so it is not your original row number if your input contained repeats.
• retryBackoff has a different fallback in code than in the schema. The Console always sends the schema default of 2. Omit the key entirely over the API and the Actor falls back to 1.5.
• lookupConcurrency and maxRetries are clamped in code, to 1–100 and 1–12 respectively, so an out-of-range value sent over the API is corrected rather than rejected. requestTimeout is bounded by the schema in the Console but passed through as given over the API.

Example input

{
  "companyNames": ["Tesla", "OpenAI", "Stripe", "Microsoft", "Notion Labs"],
  "enrichFirmographics": true,
  "includeRelatedCompanies": true,
  "searchRegion": "us-en",
  "lookupConcurrency": 20,
  "includeUnmatched": true,
  "linkedinQuerySuffix": "linkedin company",
  "requestTimeout": 20,
  "maxRetries": 6,
  "retryBackoff": 2,
  "proxyConfiguration": { "useApifyProxy": false }
}

⬆️ Output

One row per company name, written to the dataset the moment that company finishes, so a long run never loses collected work. Values that could not be read arrive as null or [] rather than as a guess. Export as JSON, CSV or Excel, or read the dataset through the Apify API.

Row width is set by your toggles, and keys are omitted rather than nulled when a toggle is off:

• Both toggles on, the default: 23 keys — 4 lookup keys, 15 firmographic keys, 4 related-slug arrays.
• includeRelatedCompanies off: 19 keys. relatedCompanies, similarCompanies, affiliatedCompanies and showcasePages are absent from the row entirely, not empty arrays.
• enrichFirmographics off: 4 keys — mySearch, queryId, linkedinUrl, info. Every firmographic and related key is absent, and includeRelatedCompanies has no effect at all.

One edge case to be aware of: if the enrichment HTTP engine cannot start at all, the run logs that it is falling back to URL-only and completes with 4-key rows instead of failing. The run log states this explicitly, so a narrower-than-expected export is always explained there.

Every row that reaches the dataset is charged, including unmatched ones. This Actor pushes exactly one kind of row and fires the row_result charged event on all of them. There is no uncharged accounting row, no isError, errorReason, status, type or success key, and therefore no filter expression that separates real results from failures. A company name that resolved to nothing still costs a row_result when includeUnmatched is on. If you would rather not pay for names that do not resolve, set includeUnmatched to false — those names then produce no row at all, at the cost of your output no longer lining up 1-to-1 with your input list. Client-side, the only test for a failed lookup is linkedinUrl being null; for a lookup that succeeded but whose page could not be enriched, linkedinUrl is populated while companyName and companyUrn are null.

Example output

A fully resolved and enriched company:

{
  "mySearch": "Tesla",
  "queryId": 1,
  "linkedinUrl": "https://www.linkedin.com/company/tesla-motors",
  "info": "Tesla - LinkedIn",
  "companyName": "Tesla",
  "companySlug": "tesla-motors",
  "companyUrn": "15564",
  "industry": "Motor Vehicle Manufacturing",
  "companySize": "10,001+ employees",
  "companySizeRange": { "start": 10001, "end": null },
  "followerCount": 9184233,
  "employeesOnLinkedin": 142897,
  "foundedYear": 2003,
  "website": "https://www.tesla.com",
  "headquarters": {
    "country": "US",
    "state": "Texas",
    "city": "Austin",
    "postalCode": "78725",
    "line1": "1 Tesla Road"
  },
  "specialties": [
    "Electric Vehicles",
    "Energy Storage",
    "Solar Energy",
    "Autonomous Driving"
  ],
  "tagline": "Accelerating the world's transition to sustainable energy",
  "companyDescription": "Tesla designs and manufactures electric vehicles, battery energy storage systems and solar products, with the goal of accelerating the world's transition to sustainable energy.",
  "logoUrl": "https://media.licdn.com/dms/image/v2/D560BAQGCJ0K2vQxRZQ/company-logo_400_400/0/1730926842103",
  "relatedCompanies": ["rivian", "lucidmotors", "spacex", "tesla-energy"],
  "similarCompanies": ["rivian", "lucidmotors"],
  "affiliatedCompanies": ["spacex"],
  "showcasePages": ["tesla-energy"]
}

A name that could not be resolved, with includeUnmatched on — this row is charged exactly like the one above:

{
  "mySearch": "Northgate Holdings",
  "queryId": 4,
  "linkedinUrl": null,
  "info": null,
  "companyName": null,
  "companySlug": null,
  "companyUrn": null,
  "industry": null,
  "companySize": null,
  "companySizeRange": { "start": null, "end": null },
  "followerCount": null,
  "employeesOnLinkedin": null,
  "foundedYear": null,
  "website": null,
  "headquarters": null,
  "specialties": [],
  "tagline": null,
  "companyDescription": null,
  "logoUrl": null,
  "relatedCompanies": [],
  "similarCompanies": [],
  "affiliatedCompanies": [],
  "showcasePages": []
}

How does it work?

Each company name is turned into a search query, sent to a public HTML search endpoint through a Rust-backed browser-impersonating HTTP client, and the first linkedin.com/company/ result is canonicalised into a bare company URL. When enrichment is on, that URL is opened over a second HTTP client using Chrome TLS impersonation — one shared session for the whole run, no headless browser, no cookie.

The page is then parsed most-stable-source-first: the JSON-LD Organization node, then Open Graph and meta tags, then the About-us definition list. Because each field has more than one source, a LinkedIn redesign that moves one of them usually leaves the column populated. If none of the recognisable company signals survive the parse, every firmographic field is nulled rather than half-filled.

Only publicly visible company data is returned. The output keys stay the same across runs and across LinkedIn's front-end changes, so downstream mappings do not need revisiting when the page does.

Integrations

It is an Apify Actor, so it works with anything that can call the Apify API or read a dataset.

Calling it from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/linkedin-company-url-mass-profile-finder-with-firmographics").call(run_input={
    "companyNames": ["Tesla", "OpenAI", "Stripe"],
    "enrichFirmographics": True,
    "lookupConcurrency": 20,
})

rows = list(client.dataset(run["defaultDatasetId"]).iterate_items())
matched = [r for r in rows if r.get("linkedinUrl")]

for r in matched:
    print(r["mySearch"], "->", r["linkedinUrl"], r.get("industry"), r.get("companySize"))

Works in Go, Ruby, Node.js, cURL — any language that can make an HTTP request. Filtering on linkedinUrl is how you separate resolved companies from unmatched ones, since there is no error flag to branch on.

No-code tools (n8n, Make, LangChain)

In n8n, use the Apify node — or an HTTP Request node pointed at the Actor's run endpoint with your token — and pass the same JSON input shown above; an IF node testing whether linkedinUrl is empty then routes unmatched companies into a manual review branch. In Make, the Apify module supports run-and-wait, so a weekly account-list refresh can feed a Google Sheets, Airtable or CRM step directly. In LangChain, wrap the run call as a tool function and hand the rows to your agent as context — they are already typed JSON, so no output parser is needed.

Is it legal to scrape LinkedIn company pages?

Scraping publicly accessible pages is broadly treated as permissible where no authentication is bypassed, and this Actor returns only what a signed-out visitor sees on a company overview page. What matters here is which regime applies, and for this output it is not the one people usually reach for.

Every field returned is business data, not personal data. Company name, industry, size band, headquarters, founded year, website, specialties, follower count, logo, company URN and related-page slugs are corporate records about a legal entity. No output key names, identifies or describes an individual: there is no founder, no employee, no page administrator, no contact name, no email and no phone number anywhere in the row. employeesOnLinkedin is a count of members, not a list of them. Because of that, GDPR and the CCPA do not attach to this output the way they would to a LinkedIn profile scraper — there is no data subject in a company record, so there is no lawful basis to establish for the rows themselves, no Article 14 notice to send and no erasure request to service.

The regimes that do apply are contractual and database rights. LinkedIn's Terms of Service govern automated access to its pages, and EU database rights and their equivalents elsewhere can cover substantial extraction from a compiled collection. Keep your use proportionate and do not present LinkedIn's compiled dataset as your own product. Note also that if you later join these company records to named individuals from another source, the combined dataset does become personal data and the personal-data regimes apply from that point on. Consult legal counsel if your use case involves bulk storage of personal data, redistribution, or AI training corpora.

❓ Frequently asked questions

What LinkedIn company fields does it return?

The five most used are linkedinUrl, industry, companySize, employeesOnLinkedin and headquarters. Every enriched row also carries companyName, companyUrn, followerCount, foundedYear, website, specialties, tagline, companyDescription, logoUrl and the related-page slug arrays — 23 top-level keys in total with both toggles on. See the data fields table above.

Does it require a LinkedIn account, login or cookie?

No, and there is no input field to supply one. Both the name lookup and the company-page fetch run anonymously over plain HTTP with browser TLS impersonation. Your Apify token is the only credential involved. The trade-off is that fields LinkedIn renders only to a signed-in visitor — funding rounds, page verification, company phone number — are not returned at all rather than being guessed. If a specific company page redirects guests to an auth wall, that row keeps its URL and slug and returns null firmographics.

How many company names can I resolve in one run?

There is no cap in the Actor. companyNames accepts a list of any length, and up to lookupConcurrency companies — 1 to 100, default 10 — are resolved and enriched in parallel. Run size is bounded by your Apify usage limits and by how hard you want to push the proxy ladder, not by the Actor. Raising concurrency makes a run finish sooner and consumes proxy bandwidth faster once the run has escalated off a direct connection.

What happens when a company name cannot be resolved, or matches several companies?

Two different outcomes, and only one of them is visible.

If nothing resolves, you get a null-filled row when includeUnmatched is on — linkedinUrl and info are null, every firmographic field is null or [] — or no row at all when it is off. There is no error code and no status field; linkedinUrl being null is the signal.

If several companies match, you get one of them with no warning. The first linkedin.com/company/ result in the search ranking wins, and no alternatives are recorded anywhere in the output. Verify by comparing mySearch against companyName and info, and treat short, generic or franchised names as needing review. Adding a distinguishing word to the input name — a city, a country, a legal suffix — is the practical fix, since the name you submit is what forms the query.

Are unmatched companies charged?

Yes. The Actor fires the row_result charged event on every row it pushes, and an unmatched company with includeUnmatched on is a pushed row. There are no uncharged accounting rows in this Actor and no marker key to filter them by. Set includeUnmatched to false if you would rather not pay for names that do not resolve — those names then produce nothing, and your output no longer aligns 1-to-1 with your input list. A run that starts with an empty companyNames exits without pushing anything and is not charged.

Can I resolve multiple company names at once?

Yes — bulk is the default mode. companyNames is a list, and it also accepts a single newline- or comma-separated string. The list is de-duplicated case-insensitively before the run, and rows are written as each company completes, so dataset order follows completion rather than input order. Sort on queryId to restore your sequence, and join back to your source list on mySearch.

Does it work with Claude, ChatGPT and other AI agent tools?

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 with no parsing step. There is no separate signup and no separate API key — the Apify token you already have is the only credential.

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 used of the three; its listing documents four output fields — info, mySearch, linkedinUrl and queryId — takes its input as a newline-separated queries string, states that no LinkedIn session or cookies are needed, and links a video tutorial and an official n8n template. api-empire/linkedin-company-url-mass-profile-finder and scrapier/linkedin-company-url-mass-profile-finder publish identical listings documenting the same four output fields, the input keys queries, maxConcurrency, region, querySuffix, includeNotFound, maxRetries, requestTimeout, retryBackoff and proxyConfiguration, a DIRECT to DATACENTER to RESIDENTIAL proxy ladder, and pay-per-event billing on row_result.

What this Actor documents that those three listings do not: the 15 firmographic fields and 4 related-page slug arrays on top of the same four lookup keys, and a written account of how resolution actually behaves on an ambiguous or failed name. None of the three listings documents firmographic enrichment; where a listing is silent on something, that is not documented rather than not supported. Because this Actor also accepts the base input keys those listings use, an input JSON written for any of them runs here unchanged.

Does it return data in a format LLMs can use directly?

Yes. Typed, normalized JSON with consistent field names across runs. Strings are strings, counts are integers, specialties and the slug arrays are arrays, and headquarters and companySizeRange are plain nested objects. No HTML parsing, no selectors. Pass a row straight into an LLM context window, index it into a vector store, or hand it to an agent tool.

What happens when LinkedIn changes its layout or anti-bot system?

The Actor is maintained, and the output keys stay stable on your side regardless of what changed upstream. Two design choices reduce the exposure: every firmographic field is read most-stable-source-first across JSON-LD, meta tags and the About-us list, so a markup change to one source is usually covered by another; and a page that yields no recognisable company signal returns nulls rather than partial garbage. Anti-bot pushback is handled as throttling rather than failure — fresh exit IP, backoff with jitter, retry — and the proxy ladder escalates on its own without a config change on your side.

Which fields work best for AI training data and RAG indexing?

For RAG indexing: companyDescription carries the bulk of the information in a company record and chunks cleanly one row per chunk, with tagline and specialties as short high-signal metadata and linkedinUrl as the citation anchor. For training data and analytics: industry, companySize, companySizeRange.start, employeesOnLinkedin, followerCount and foundedYear are the most structurally consistent fields across records, and companyUrn is the stable join key since it survives company renames. All values return as typed primitives, arrays or plain nested objects, so no normalization pass is needed before indexing.

🔗 Related scrapers

Scraper Name	What it extracts
LinkedIn Profile Company Enrichment Scraper	Full profile and company records from a LinkedIn profile URL
LinkedIn Jobs Scraper With Salary Range Filters	Public job postings with salary-range filtering
LinkedIn Profile Seniority Title Filter	Profile lists narrowed to decision-makers by seniority and title
LinkedIn Post Scraper	Post body, author and post-level engagement counts
LinkedIn Post Comments Scraper	Comment text, commenter identity and reaction counts
LinkedIn Phone Lead Scorer	Contact-quality scoring across a LinkedIn lead list

💬 Your feedback

Found a bug, or a firmographic field LinkedIn publishes on a company page that is not in the output? Open an issue on the Actor's Issues tab. Reports that include the exact input JSON and the company name that misbehaved are the fastest to reproduce and fix.