LinkedIn Company Employee Scraper

Scrape visible LinkedIn company employees from one or more LinkedIn company URLs. This Apify actor returns clean employee profile rows with profile URLs, visible names, headlines, titles, company metadata, source confidence, and filter matches.

The actor is built for account mapping, recruiting research, lead sourcing, enrichment pipelines, and AI-agent workflows that need structured LinkedIn profile URLs from company pages.

In auto mode, the data-source chain is:

1. ScrapeCreators LinkedIn company API
2. SociaVault LinkedIn company API
3. Authenticated LinkedIn /people/ tab when LINKEDIN_COOKIES is configured
4. Public search discovery as a last-resort filler path

What It Does

• Normalizes LinkedIn company URLs such as https://www.linkedin.com/company/apify/posts/
• Extracts visible employees from ScrapeCreators and SociaVault company-page APIs
• Uses SociaVault as a secondary provider when ScrapeCreators does not fill the requested cap
• Continues with the LinkedIn company /people/ tab when cookies are configured and more rows are needed
• Falls back to public search discovery only after provider and cookie-backed paths cannot fill the cap
• Supports optional title, location, and search-query filters
• Deduplicates profile URLs across companies and providers
• Emits source and confidence fields so agents and downstream systems can decide how to handle each row

When Agents Should Use This Actor

Use this actor when an automation or MCP client needs visible employee profile URLs for a known LinkedIn company page. It is a good fit for account research, CRM enrichment preparation, recruiting lists, competitor mapping, partner discovery, or creating seed datasets for profile enrichment.

Call this actor when the input is one or more LinkedIn company URLs and the desired output is a list of LinkedIn profile URLs with names, titles, snippets, company metadata, and source quality signals.

Do not call this actor when the task requires private LinkedIn data, guaranteed complete company rosters, email addresses, phone numbers, personal contact enrichment, or profile details that are not visible from the selected source path. For emails or deep profile enrichment, use this actor first to collect profileUrl values, then pass those URLs to a separate compliant enrichment workflow.

Input

{
  "companyUrls": ["https://www.linkedin.com/company/apify/"],
  "maxEmployees": 100,
  "maxEmployeesPerCompany": 100,
  "mode": "auto",
  "jobTitles": ["Engineer", "Product"],
  "locations": ["Prague"],
  "includeProfileDetails": false
}

Input Fields

Field	Type	Description
companyUrls	string[]	LinkedIn company page URLs to process. Required.
maxEmployees	integer	Global cap across the whole run.
maxEmployeesPerCompany	integer	Per-company cap for balanced multi-company runs.
mode	string	auto, publicSearch, or linkedinPeopleTab.
searchQuery	string	Optional extra words for public search discovery.
jobTitles	string[]	Optional title keywords used to filter or boost visible matches.
locations	string[]	Optional location keywords used to filter or boost visible matches.
includeProfileDetails	boolean	Authenticated mode only. Visits discovered profiles for more visible details.
maxConcurrency	integer	Number of companies to process in parallel.
proxyConfiguration	object	Apify proxy settings. Residential proxies are recommended for LinkedIn fallback paths.

Modes

auto is the recommended mode. It tries ScrapeCreators first, SociaVault second, authenticated LinkedIn people-tab scraping when LINKEDIN_COOKIES exists, and public search last.

linkedinPeopleTab only uses LinkedIn company /people/ pages. This mode requires the LINKEDIN_COOKIES secret environment variable and is more sensitive to LinkedIn limits.

publicSearch never opens LinkedIn. It queries public search engines for LinkedIn profile URLs related to the company. Use it only when provider and cookie-backed paths are not available, because narrow filters or weak indexing can return zero rows.

Provider API Keys

Set provider keys as Apify secret environment variables:

SCRAPECREATORS_API_KEY=...
SOCIAVAULT_API_KEY=...

SOCIALVAULT_API_KEY is also accepted as a compatibility alias. Provider keys are intentionally not accepted in actor input because run input can be visible in Console history.

LinkedIn Cookies

Set LINKEDIN_COOKIES in Apify Console as a secret environment variable only if you want the owned LinkedIn people-tab fallback path.

Accepted cookie string format:

li_at=...; JSESSIONID=...; bcookie=...

Accepted browser-exported JSON format:

[
  {
    "name": "li_at",
    "value": "...",
    "domain": ".linkedin.com",
    "path": "/",
    "secure": true
  }
]

Credentials are not accepted in actor input. Keep cookies in secret environment variables.

Output Fields

Field	Type	Description
companyName	string	Company name returned by the provider or derived from the LinkedIn slug.
companySlug	string	LinkedIn company slug, useful for dedupe and joins.
companyUrl	string	Normalized LinkedIn company URL.
employeeName	string/null	Visible employee name when available.
profileUrl	string	Normalized LinkedIn profile URL. Use this as the main join key.
headline	string/null	Visible LinkedIn headline, role text, or provider title.
title	string/null	Best-effort job title when the source exposes it separately.
location	string/null	Best-effort location when the source exposes it separately.
snippet	string/null	Source text used to build the row.
source	string	Extraction path: scrapecreators_company, sociavault_company, linkedin_people_tab, public_search, or profile_detail.
confidence	string	high, medium, or low, based on source and filter match quality.
matchedFilters	string[]	Input filters found in the visible employee text.
scrapedAt	string	ISO timestamp for the emitted row.

MCP Output Contract

Agents should treat the default dataset as the primary result. Each item is one unique LinkedIn employee profile row.

Use profileUrl as the stable identifier. Use companySlug for grouping, dedupe, and joins back to the original target account. Use source and confidence before taking automated action: provider and cookie-backed rows are usually stronger than public-search rows, especially when title and location filters are narrow.

The actor also writes RUN_SUMMARY to the key-value store. Agents should read it when they need provider health, fallback behavior, warning counts, duplicate counts, or row counts by source.

Run Summary

RUN_SUMMARY includes:

• companies requested and processed
• rows from ScrapeCreators
• rows from SociaVault
• rows from LinkedIn people-tab fallback
• rows from public search fallback
• duplicate profile count
• profile-detail visits
• warnings from provider or fallback paths

This makes the actor easier to monitor in production workflows. A run can succeed with fewer rows than requested when available visible data is exhausted or filters are too narrow.

Reliability Strategy

The actor is designed to avoid brittle single-source scraping. ScrapeCreators is used first because it gives the lowest-cost provider path for company-page employee data. SociaVault is used second as redundancy. If provider rows do not fill the requested cap, the actor can continue with owned fallback paths.

Every row includes source and confidence, so downstream workflows can choose whether to auto-enrich, review manually, or discard lower-confidence rows. Public search is intentionally treated as a fallback, not as proof of complete employee coverage.

Margin And Pricing

Pay-per-event schema:

• $0.00005 actor start
• $0.015 per unique employee profile row

The row price is set for provider-safe economics. ScrapeCreators and SociaVault charge per provider request, not per final employee row, so larger company runs have stronger margins. The price also protects small runs: even if both providers are probed before one paid row is returned, the actor is priced to keep more than 60% gross margin after provider costs and Apify's marketplace commission.

Pay-per-usage can be enabled alongside PPE in Apify Console. Usage billing helps heavy users with larger runs, while PPE keeps agent and workflow costs predictable.

Example: Account Mapping

{
  "companyUrls": [
    "https://www.linkedin.com/company/shopify/",
    "https://www.linkedin.com/company/openai/"
  ],
  "mode": "auto",
  "maxEmployees": 25,
  "maxEmployeesPerCompany": 15,
  "jobTitles": ["Product", "Engineering", "Sales"],
  "locations": []
}

Example: Public Search Only

{
  "companyUrls": ["https://www.linkedin.com/company/apify/"],
  "mode": "publicSearch",
  "maxEmployees": 10,
  "searchQuery": "engineer data scraping",
  "jobTitles": ["Engineer"]
}

Public search is a last-resort mode. It depends on search-engine indexing and may return zero rows for narrow filters. For production workflows, use auto so provider APIs are tried first.

FAQ

Does this return every employee at a company?

No. It returns visible employees from provider company-page data and optional fallback discovery. Complete LinkedIn employee directories depend on login state, account limits, geography, visibility settings, and LinkedIn product changes.

Do ScrapeCreators or SociaVault use my LinkedIn cookies?

No. Both providers are API-based public-data providers. They do not accept LinkedIn login cookies. Cookies are only used by the actor's owned LinkedIn /people/ fallback path.

Why did a run return fewer rows than maxEmployees?

The cap is a maximum, not a guarantee. The actor stops when available visible rows are exhausted, filters remove candidates, providers return no employees for that company, or fallback discovery cannot find confident profile URLs.

How should I use the results downstream?

Use profileUrl as the stable join key. Use source and confidence to decide whether a row should be auto-enriched or reviewed first. If you need emails, feed the profile URLs into a separate compliant enrichment workflow.

Legal And Responsible Use

Only scrape and process data you are allowed to use. Respect LinkedIn's terms, privacy laws, platform limits, and applicable outreach rules. This actor is intended for public business research, recruiting research, enrichment workflows, and account mapping. It should not be used for spam, harassment, discrimination, or privacy-invasive profiling.