LinkedIn Company URL - Mass Profile Finder By Industry & Size

LinkedIn Company URL Finder — URLs, Firmographics & ICP Verdicts

Turn a plain list of company names into their LinkedIn company URLs, then enrich and screen each one against your Ideal Customer Profile (ICP) — industry, employee-size band, and HQ country — in a single Apify run. Every row comes back as typed JSON: a resolved linkedinUrl, no-cookie firmographics (industry, headcount, followers, HQ, founding year), and an icpMatch verdict with human-readable reasons — not raw HTML you have to parse yourself. No LinkedIn login, no cookies, no manual page-by-page lookups. This guide covers every input and output field, how the ICP screen actually decides true / false / null, and three concrete ways teams run it — real-time enrichment, scheduled monitoring, and bulk list building.

What Does This Actor Do?

LinkedIn Company URL - Mass Profile Finder By Industry & Size takes a bulk list of company names, resolves each to its linkedin.com/company/<slug> page, reads that page's public no-cookie firmographics, and then screens the result against up to three allow-lists you configure — industry, employee-size band, and HQ country. No LinkedIn account, login, or session cookie is used anywhere in the pipeline; the source resolves URLs through a logged-out search and reads only the guest-visible company overview page.

• 🏢 Resolves company names in bulk to canonical LinkedIn company URLs
• 🏭 Reads industry, employee-size band, exact employee count, and follower count from the public overview page
• 🌍 Reads HQ country, HQ city, website, founded year, and the numeric LinkedIn organization URN
• 🎯 Screens firmographics against independent industry / size / HQ-country allow-lists
• 🚮 Drops non-matching companies, or keeps everything and flags it — your choice
• 📭 Emits an aligned row for names with no LinkedIn page, so output order matches input order
• 🛡️ Escalates through a proxy ladder automatically when a request gets throttled

Features & Capabilities

The Actor's job splits into two layers: a URL-resolution engine shared with the base finder, and an ICP-screening layer built on top of it.

Core capabilities, read directly from src/main.py and src/parser.py:

• Bulk name-to-URL resolution via browser-impersonated DuckDuckGo HTML search (impit, Chrome browser profile), one query per company plus the configurable querySuffix, with a small random pre-request delay (0–1.2s) per company so a burst of parallel workers doesn't fire in lockstep
• No-cookie firmographic extraction from the company's public overview page: JSON-LD Organization schema, about-us__* data attributes, and og:/meta tags — three independent sources so a field missing from one still often resolves from another
• Firmographic fields returned per row: industry, employeeSizeBand, employeeCount, followerCount, hqCountry, hqCity, website, foundedYear, companyUrn
• Three independent ICP allow-lists (industry, employee-size band, HQ country), each skipped when left empty, evaluated with case-insensitive partial matching
• icpMatch as a strict three-state verdict — true, false, or null when a needed field simply wasn't published — never guessed
• A proxy ladder (DIRECT → DATACENTER → RESIDENTIAL) shared by both the search request and the firmographics fetch, escalating automatically on a block and then sticking with residential for the rest of the run
• LinkedIn's guest pages are recognized as blocked on the standard throttle codes (202, 403, 429, 500, 502, 503, 504) plus HTTP 999 — a non-standard status LinkedIn itself returns to guest requests it dislikes — so the firmographics fetch treats a 999 the same as any other soft block and escalates the proxy tier
• Live push_data per company — a crash mid-run never loses rows already collected

How this compares to other LinkedIn company URL finders

Feature	This Actor	anchor/LinkedIn-company-url-finder	api-empire & scrapier /linkedin-company-url-mass-profile-finder
Output format	Typed JSON, 16 fields per row	Typed JSON, 4 fields per row	Typed JSON, 4 fields per row
Firmographic enrichment (industry, size, HQ, followers)	✅	❌ (not documented)	❌ (not documented)
ICP allow-list screening (icpMatch + reasons)	✅	❌ (not documented)	❌ (not documented)
Proxy escalation ladder (direct → datacenter → residential)	✅	❌ (not documented)	✅ (documented on their listing)
Login / cookies required	None	None	None
Pricing model	Pay-per-event (row_result)	Flat monthly price	Pay-per-event

Observed on each Actor's Apify Store listing, 2026-07-26. If your use case is feeding structured data straight to an LLM or a scoring rule, the field-depth row is the decision-maker — a bare URL list still leaves you making a second logged-out request per company to get industry or headcount, which is exactly what this variant does for you inline.

When another tool might suit you better: if all you need is the URL — no industry, no size band, no HQ filter — the base anchor/LinkedIn-company-url-finder or its unfiltered sibling in this pipeline return the same four base fields with one request per company instead of two, which is faster and cheaper per row when firmographics add nothing to your workflow.

This Actor covers LinkedIn companies. For LinkedIn profiles, Scrapio's linkedin-profile-credibility-scraper and Linkedin-Phone-Number-Scraper-pay-per-events cover the people side; for LinkedIn posts, linkedin-post-keyword-monitor and linkedin-post-comments-scraper-buying-signal-detection cover content and engagement.

Why do developers and data teams scrape LinkedIn company data?

🏢 Sales development and account-based marketing teams feed a raw list of target-account names in and get back industry, employeeSizeBand, and hqCountry on every row, with icpMatch doing the qualification pass before a lead ever reaches a rep or a CRM field.

📊 AI training data and RAG indexing benefit from industry, employeeSizeBand, and icpMatchReasons specifically — the reasons array is free-text explaining why a company fits or doesn't, which is dense, human-readable signal for retrieval. For RAG enrichment, index companyName + industry + icpMatchReasons as the searchable text; for training data, employeeSizeBand, hqCountry, and icpMatch are the fields with the most consistent structure across rows since they come from a small, LinkedIn-controlled vocabulary.

📱 Competitive and market intelligence teams track employeeCount and followerCount over repeated runs to watch a competitor's headcount growth or audience reach shift over a quarter.

🔬 Research and academic use cases — labor-market and firmographic studies over a named company list — are limited to what LinkedIn publishes to logged-out visitors: no revenue, no private headcount, no non-public data.

🎥 Product and SaaS development teams wire this Actor into a firmographic-enrichment API or account-scoring product, using icpMatch and icpMatchReasons as a drop-in qualification signal instead of building industry/size classifiers from scratch.

🍚 Input Parameters

All 12 parameters accepted by the input schema, in schema order:

Parameter	Required	Type	Constraints	Description
companyNames	No	array	editor: stringList	One company name per line, e.g. Tesla, OpenAI, Stripe. Each is resolved to its LinkedIn company page, then enriched and screened.
industryAllowList	No	array	editor: stringList, default []	Keep only companies whose LinkedIn industry matches one of these (case-insensitive, partial — software matches Software Development). Empty = allow every industry.
sizeBandAllowList	No	array	editor: select, enum of 9 LinkedIn size bands, default []	Keep only companies in these LinkedIn employee-size bands. Empty = allow any size.
hqCountryAllowList	No	array	editor: stringList, default []	Keep only companies headquartered in these countries (case-insensitive, partial — US or United States both match). Empty = allow any country.
dropNonMatching	No	boolean	default true	true: companies that clearly fail a filter are removed. false: every company is kept and flagged with icpMatch + icpMatchReasons. Companies whose firmographics can't be read are always kept with icpMatch = null.
region	No	string	enum, default "us-en"	Region/language for the URL-resolution search. Values: us-en (United States), uk-en (United Kingdom), ca-en (Canada), au-en (Australia), in-en (India), wt-wt (worldwide, no region).
maxConcurrency	No	integer	min 1, max 100, default 10	Companies processed in parallel. Each company makes up to two requests (search + firmographics). Higher uses your proxy pool faster.
includeNotFound	No	boolean	default true	When true, companies with no LinkedIn page still get a row (empty URL, icpMatch = null) so output aligns 1-to-1 with input.
querySuffix	No	string	editor: textfield, default "linkedin company"	Phrase appended to each company name to bias the search toward its LinkedIn page.
requestTimeout	No	integer	min 5, max 120, default 25	Per-request timeout in seconds, applied to both the search and firmographics fetches.
maxRetries	No	integer	min 1, max 12, default 6	Retry attempts on the residential proxy tier before the Actor gives up on a single request.
proxyConfiguration	No	object	editor: proxy, default {"useApifyProxy": false}	Proxy settings. By default the run starts with no proxy; on a block it auto-escalates to Datacenter, then Residential, and stays on Residential for the rest of the run.

No parameter in this schema is marked isSecret — there is no API key or credential field to configure; the Actor authenticates to nothing.

Example input:

{
  "companyNames": ["Tesla", "OpenAI", "Stripe", "Shopify", "Notion Labs"],
  "industryAllowList": ["Software Development", "Financial Services"],
  "sizeBandAllowList": ["1,001-5,000 employees", "10,001+ employees"],
  "hqCountryAllowList": ["US"],
  "dropNonMatching": true,
  "region": "us-en",
  "maxConcurrency": 10,
  "includeNotFound": true,
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"] }
}

Supported input formats and matching behavior

• companyNames accepts a list, one string per company — the schema editor is stringList, so the Console renders it as a plain textarea, one name per line.
• The source code also normalizes a comma-separated string into the same list and de-duplicates names case-insensitively before running, so Tesla, Tesla, OpenAI becomes two lookups, not three. Internally, the same code path also accepts the base finder's queries key as a fallback if companyNames is absent, though only companyNames is exposed in this Actor's published input schema.
• industryAllowList and hqCountryAllowList match on partial, case-insensitive substrings in both directions — an allow-list entry of US matches a published United States, and an entry of Software matches Software Development.
• sizeBandAllowList is a closed select — you can only choose from LinkedIn's own nine published bands: 0-1 employees, 2-10 employees, 11-50 employees, 51-200 employees, 201-500 employees, 501-1,000 employees, 1,001-5,000 employees, 5,001-10,000 employees, 10,001+ employees. There is no free-text or numeric-range option here — if you need a custom numeric cutoff, filter post-run on employeeCount instead.
• Leaving all three allow-lists empty runs the Actor as a pure URL-and-firmographics finder: every company is enriched and returned with icpMatch = true.
• requestTimeout and maxRetries are the only retry knobs exposed in the input schema. The backoff multiplier between retries (retryBackoff, effectively 1.5) is read from the same internal config dict but has no corresponding schema property, so it cannot currently be changed from the Console or the API — only the timeout and retry-count ceilings are user-configurable.

📦 Output Format

Every kept company produces exactly one flat JSON record — the URL, the firmographics, and the ICP verdict are not separate objects; they are merged into a single row per the code in parser.build_icp_record(). The dataset's default 🎯 ICP-Screened Companies view surfaces all 16 fields the Actor writes; nothing is held back from the view.

The Console's table view formats each column for readability rather than showing raw JSON: linkedinUrl renders as a clickable "View Company" link, website as a clickable "Open" link, employeeCount and foundedYear as right-aligned numbers, icpMatch as a boolean chip, and every other field as plain text — mySearch, info, companyName, industry, employeeSizeBand, hqCountry, hqCity, companyUrn, and icpMatchReasons. This affects only the Console preview; the underlying dataset item is the same flat JSON object regardless of which view or export format you read it through.

Example record:

{
  "mySearch": "Stripe",
  "queryId": 3,
  "linkedinUrl": "https://www.linkedin.com/company/stripe",
  "info": "Stripe - LinkedIn",
  "companyName": "Stripe",
  "industry": "Software Development",
  "employeeSizeBand": "5,001-10,000 employees",
  "employeeCount": 8123,
  "followerCount": 1450233,
  "hqCountry": "US",
  "hqCity": "South San Francisco",
  "website": "https://stripe.com",
  "foundedYear": 2010,
  "companyUrn": "1943091",
  "icpMatch": true,
  "icpMatchReasons": [
    "Industry: 'Software Development' matches allow-list ('Software Development').",
    "HQ country: 'US' matches allow-list ('US')."
  ]
}

Field	Description
mySearch	The company name exactly as submitted.
queryId	1-based index matching your input order.
linkedinUrl	Canonical linkedin.com/company/<slug> URL, or null if no page was found.
info	The search-result page title, e.g. "Stripe - LinkedIn".
companyName	Company name as published on its LinkedIn overview page (null if the page couldn't be enriched).
industry	LinkedIn industry label, or null if not published.
employeeSizeBand	LinkedIn's own headcount band string, e.g. "1,001-5,000 employees".
employeeCount	Exact employee count from the page's structured data, or null if absent.
followerCount	LinkedIn follower count.
hqCountry	Headquarters country.
hqCity	Headquarters city.
website	Company website, read from JSON-LD sameAs or the about-us website link.
foundedYear	Founding year — published for some companies only, null otherwise.
companyUrn	Numeric LinkedIn organization id (from urn:li:organization:<id>).
icpMatch	true = passed every active filter, false = failed at least one, null = a needed field wasn't published so the criterion couldn't be judged.
icpMatchReasons	Array of one human-readable string per evaluated criterion (or a single note when no filters are configured).

Two fields the parser computes but never writes to the row: parser.extract_firmographics() also derives universalName (the bare slug, redundant with linkedinUrl) and employeeRange (a numeric {start, end} parsed from employeeSizeBand, e.g. 1,001-5,000 employees → {start: 1001, end: 5000}), plus about-us fields organizationType and specialties. None of these reach build_icp_record() — if you need numeric size buckets or specialties for filtering, you currently have to parse employeeSizeBand or scrape the page yourself.

Charging and schema stability

Only rows actually written to the dataset are charged, via the row_result event — one charge per pushed row, no exceptions found in the source. Companies excluded by includeNotFound: false (no page found) or dropped by dropNonMatching: true (failed an active filter) are never pushed and never charged. Field names come from a fixed extraction pipeline (JSON-LD schema.org Organization, about-us__* attributes, and og:/meta tags), so they stay stable independent of LinkedIn's visual redesigns; a field LinkedIn stops publishing simply returns null rather than breaking the schema. Results are available for export from the dataset in JSON, CSV, Excel, HTML, XML, or RSS, or read live via the Apify API.

💡 Strategy Guide

Strategy 1 — Real-time enrichment pipeline. Trigger a run whenever a new account lands in your CRM or spreadsheet: pass its name as a single-item companyNames list, call the Actor via the Apify API, and write industry, employeeSizeBand, hqCountry, and icpMatch back onto that record the moment the run finishes. With maxConcurrency: 1 and a small input, a single-company run resolves and screens before the caller's request would otherwise time out. Because dropNonMatching defaults to true, a webhook listening for ACTOR.RUN.SUCCEEDED only needs to check whether the dataset actually contains a row — an empty dataset means the account failed your ICP outright, no extra logic required on your side.

Strategy 2 — Scheduled monitoring and alerting. Set up an Apify Schedule to re-run the same target-account list weekly or monthly, then diff each run's dataset on employeeSizeBand, icpMatch, and followerCount against the previous run's export. An account whose employeeSizeBand moves into your sizeBandAllowList, or whose icpMatch flips from false/null to true, is the delta worth alerting sales on; a steady followerCount climb across scheduled runs is a lightweight proxy for audience or hiring momentum without needing a dedicated monitoring tool. Set dropNonMatching: false for monitoring runs specifically, so an account that later re-enters your ICP is still present in the diff instead of having disappeared from the dataset entirely.

Strategy 3 — Bulk dataset build. Feed a list of thousands of company names with dropNonMatching: false so every company is kept and flagged rather than silently removed, raise maxConcurrency toward its documented ceiling of 100 to speed the run within your proxy budget, and export the full dataset as CSV once complete for a segmentation database or a BI import. Because every row carries icpMatchReasons, the export doubles as an audit trail explaining every inclusion and exclusion decision — useful when a stakeholder asks why a specific account didn't make the final segment.

Strategy	Best for	Run pattern	Output format
Real-time enrichment	Single new lead or account	One run per event, single-item companyNames	JSON via Apify API
Scheduled monitoring	Watching a fixed account list over time	Recurring run on an Apify Schedule, diffed between runs	Dataset export, diffed externally
Bulk dataset build	Segmenting a large raw account list	One large run, dropNonMatching: false	CSV / Excel export

🌴 Related LinkedIn Scrapers & Tools

This Actor covers LinkedIn companies. The rest of Scrapio's LinkedIn coverage handles people and posts; the two business-data scrapers below cover the same firmographic/reputation angle on other platforms.

Scraper	What it extracts
LinkedIn Jobs Scraper: Exact Posting Dates & Reposts	LinkedIn job postings, with exact post dates and repost detection
LinkedIn Post Keyword Monitor	LinkedIn posts matching brand/keyword mentions, diffed run over run
LinkedIn Post Comments Scraper By Keyword & Engagement Filter	Comments on LinkedIn posts, filtered by keyword and engagement
LinkedIn Profile Credibility Scraper	Public LinkedIn profiles, scored for credibility from recommendations and network reach
Linkedin Phone Number Scraper	Phone numbers surfaced on public LinkedIn profiles
Linkedin Profile Phone Deduper & Exporter	Deduplicated profile-to-phone-number exports
Google Maps Scraper: Rating, Review & Open-Status Filter	Business listings on Google Maps, with rating and open-status filters
Facebook Pages Scraper: Review Sentiment Analysis	Facebook business pages, with review sentiment scoring

How to integrate this Actor with your stack

This Actor works with any language or tool that can call the Apify API — there is no separate signup, credential, or API surface beyond your Apify account token.

Python

from apify_client import ApifyClient
import csv

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run_input = {
    "companyNames": ["Tesla", "OpenAI", "Stripe", "Shopify"],
    "industryAllowList": ["Software Development"],
    "hqCountryAllowList": ["US"],
    "dropNonMatching": True,
}

run = client.actor("<YOUR_USERNAME>/linkedin-company-url-mass-profile-finder-by-industry-size").call(run_input=run_input)

with open("companies.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f)
    writer.writerow(["mySearch", "linkedinUrl", "industry", "employeeSizeBand", "hqCountry", "icpMatch"])
    for item in client.dataset(run["defaultDatasetId"]).iterate_items():
        writer.writerow([item.get("mySearch"), item.get("linkedinUrl"), item.get("industry"),
                          item.get("employeeSizeBand"), item.get("hqCountry"), item.get("icpMatch")])

Node.js

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });

const run = await client.actor('<YOUR_USERNAME>/linkedin-company-url-mass-profile-finder-by-industry-size').call({
    companyNames: ['Tesla', 'OpenAI', 'Stripe', 'Shopify'],
    sizeBandAllowList: ['1,001-5,000 employees', '10,001+ employees'],
    dropNonMatching: true,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const item of items) {
    console.log(item.mySearch, item.linkedinUrl, item.icpMatch);
}

Async and scheduled pipelines

For large lists, start the run with client.actor(...).start() instead of .call() and poll the run status, or configure an Apify webhook on the ACTOR.RUN.SUCCEEDED event to push a notification once the dataset is ready — there is no separate delivery mechanism beyond the dataset and the standard Apify webhook/API surface. For recurring jobs, use an Apify Schedule rather than an external cron.

Who Needs This Data? (Use Cases & Industries)

🏢 Sales development reps paste a raw target-account list, set sizeBandAllowList and industryAllowList to their ICP, and get back only the accounts worth a first-touch outreach — icpMatchReasons doubles as call-prep notes explaining exactly why an account qualified, so a rep opens the call already knowing the account's industry and size band instead of looking it up manually.

📊 RevOps and marketing operations teams run this on their full CRM account list nightly or weekly and use icpMatch as a scoring field feeding lead-routing rules, instead of hand-tagging industry and size in a spreadsheet. Because dropNonMatching can be toggled per run, the same input list can produce either a clean "keep only qualified" export for routing, or a fully-flagged export for a data-quality audit of the whole account base.

📱 Competitive intelligence analysts track a fixed list of named competitors' employeeCount and followerCount across scheduled runs to spot headcount or audience growth before it shows up anywhere else, and cross-reference hqCountry/hqCity when a competitor opens a new regional office.

🔬 Researchers studying firmographic distributions across a named company set — industry mix, size-band distribution, geographic concentration — get a structured export limited to what LinkedIn publishes to logged-out visitors, with no private or non-public fields. icpMatch = null rows are preserved rather than dropped, which matters for research: a silently-dropped "unknown" row would understate the true population size of a study.

🎥 Enrichment product builders wire this Actor into a firmographic-enrichment API or an account-intelligence product, using icpMatch and icpMatchReasons directly as a qualification signal instead of training a separate industry/size classifier from scratch.

Is it legal to scrape LinkedIn company data?

Scraping publicly accessible data is generally lawful in the United States: in hiQ Labs, Inc. v. LinkedIn Corp., 938 F.3d 985 (9th Cir. 2019), reaffirmed on remand in 2022, the Ninth Circuit held that scraping data LinkedIn makes publicly available does not violate the Computer Fraud and Abuse Act. That case concerned public LinkedIn profile data specifically, and it does not immunize every use of scraped data — it addresses the CFAA question, not contract or data-protection law.

Separately, LinkedIn's Terms of Service prohibit automated scraping; violating a ToS is a civil contract matter, not a criminal one, but it is a real basis for account or IP action against a scraper.

This Actor returns business firmographic data — industry, headcount band, follower count, HQ location, website, founding year — not personal data about identifiable individuals, so GDPR's and CCPA's personal-data obligations do not attach to what it collects.

This Actor extracts only publicly accessible data. What you do with that data is your responsibility — consult legal counsel for commercial applications, especially any that combine this data with personal information from elsewhere.

❓ Frequently asked questions

Does this Actor work without a LinkedIn account? Yes. Nothing in the source uses a LinkedIn session, cookie, or login — company URLs are resolved through a logged-out DuckDuckGo search, and firmographics are read from LinkedIn's public no-cookie company overview page.

How does it handle LinkedIn's anti-scraping measures? With browser-grade HTTP impersonation (impit, Chrome profile) on every request, a proxy ladder that starts with no proxy and escalates to Datacenter then Residential the moment a request is throttled or blocked, and per-request retries with exponential backoff (min(backoff * attempt, 8.0) seconds, plus jitter) up to maxRetries residential attempts.

Can I run this at scale without getting blocked? maxConcurrency accepts 1–100 parallel lookups; higher concurrency reaches the platform's blocking threshold and the residential-proxy fallback faster, since every company still makes up to two requests. Each individual request gets up to maxRetries + 4 total attempts before the Actor gives up on that one company and moves on — a single stubborn company never blocks the rest of the run. No uptime or success-rate figure is published for this Actor — plan proxy usage around your own list size rather than an assumed rate.

What if I don't configure any ICP filters at all? Every company is still resolved and enriched with firmographics, and every row is kept with icpMatch: true and a single reason string noting that no filters were configured — the Actor still works as a plain bulk URL-and-firmographics finder with all three allow-lists left empty.

How fresh is the data? Fully live — every run performs its own search and firmographics fetch; nothing is cached or reused between runs.

What happens when a company can't be matched to a LinkedIn page? With includeNotFound: true (the default) you still get a row with an empty linkedinUrl and icpMatch: null, so your output count matches your input count. Set it to false to drop those rows entirely.

Why is icpMatch sometimes null instead of true or false? Because the field a filter needs — industry, size band, or HQ country — wasn't published on that company's no-cookie overview page, so the criterion genuinely can't be evaluated. These rows are always kept and flagged, never guessed and never silently dropped.

Are dropped or unmatched companies charged? No. Only rows actually pushed to the dataset are charged, via the row_result event. A company dropped by dropNonMatching: true, or excluded by includeNotFound: false, is never pushed and never billed.

Which fields work best for AI training and RAG indexing? For RAG, index companyName, industry, and icpMatchReasons — the reasons array is free-text explaining the match decision. For training data, employeeSizeBand, hqCountry, and icpMatch are the most structurally consistent fields, since they draw from LinkedIn's own closed vocabularies. Every field returns as a typed JSON primitive — string, integer, boolean, or array of strings — with no HTML to strip before use.

Does this Actor work with Claude, ChatGPT, and other AI agent tools? There is no MCP server for this Actor. It is callable as a standard Apify Actor run through the Apify API or the apify-client SDK by any agent framework that can make an HTTP request; every response is typed JSON, ready to drop into an LLM context window without a parsing step.

How does this Actor compare to other LinkedIn company URL finders? As observed on their Apify Store listings on 2026-07-26, anchor/LinkedIn-company-url-finder returns the same base four fields (mySearch, queryId, linkedinUrl, info) on a flat monthly price and documents a proxy-free, cookie-free approach; api-empire and scrapier's identically-named linkedin-company-url-mass-profile-finder variants add the same proxy-escalation ladder on a pay-per-event model but, per their published READMEs, stop at the same four base fields. None of the three document firmographic enrichment or ICP screening — this Actor's ninth output field onward (industry through icpMatchReasons) is the addition none of them show.

ℹ️ Disclaimer

This Actor extracts only publicly available data from LinkedIn's logged-out search and company pages. It is intended for lawful use cases only. Users are responsible for complying with LinkedIn's Terms of Service and applicable data protection laws in their jurisdiction.