LinkedIn Company & People Scraper

Scrape LinkedIn company pages and public profiles without a login, a cookie, a session or a browser. Point it at a company or a person, and it returns the page as structured columns — and, if you ask it to, everything that page links to.

Every number on this page was measured from Apify's cloud on 2026-09-17 and is checkable by running python3 tools/verify_readme.py.

What you get

62 distinct columns — 36 on a company row, 39 on a person row.

For a company:

Identity	name, LinkedIn's own numeric company ID, slug, URL, tagline, logo, cover image
About	full description, website, industry, specialties
Size	LinkedIn's size band, plus the band split into a low and a high number, plus the exact employee count LinkedIn publishes
Address	street, city, region, postal code, country — split, not one label
More	company type, founding year, followers, office locations, jobs page
Neighbours	similar companies, affiliated pages, the employees the page names
Posts	recent posts and articles with their text and dates

For a person:

Identity	name, first and last name, headline, photo, cover image, badges
About	about text, location, country
Work	current title, current company with its LinkedIn slug and start date, and the full experience list with start and end dates
Study	education with start and end dates
Reach	followers, connections
Neighbours	similar profiles
Posts	recent posts and articles with their text and dates

The address and the dates are the part worth looking at twice. A company row carries street_address, city, region, postal_code and country as five separate columns, and an experience entry carries start and end, because "South San Francisco, California" in one cell cannot be filtered and "Microsoft" without a date cannot be sorted.

One seed becomes a neighbourhood

LinkedIn closed its signed-out people search. Measured on 2026-09-17 from the cloud, on four spellings each: /search/results/people/ answers HTTP 200 and returns the login page, /pub/dir/ answers HTTP 999, /directory/people-s-1/ answers HTTP 999. There is no public query endpoint left to wrap, and this Actor does not pretend there is.

What is open is every page's own links to its neighbours, and they are dense:

A page of this kind	links out to	measured on
company	10 similar companies	4 of 4 company pages
company	up to 7 affiliated pages	Microsoft: 7, Zalando: 2, Notion: 1
company	1-4 named employees	4 of 4 company pages
profile	10-20 similar profiles	3 of 3 profiles

So set Expand depth to 1 and one company seed becomes itself plus the companies and people it links to; set it to 2 and each of those expands again. The walk is breadth-first, so if a run hits your row limit it has spent it on the rows closest to what you asked about. Every run also reports neighbours_reachable — how many more entities the pages it fetched point at — so you can see what raising the depth would buy before you pay for it.

No proxy, and that is measured

25 company pages in a row, one request per second, from one Apify address with no proxy at all: 25 answered, 23 with data and 2 with HTTP 404 for slugs that do not exist. Zero blocks. 19 profile pages the same way: 16 answered with data and 3 answered HTTP 999 — and the request after each 999 succeeded, so it is a per-request refusal that a retry clears, not a wall.

The pace is the one that was proven rather than a guess at a faster one: a default of 1 second between requests, which is what those 44 consecutive pages were fetched at.

The same pages through Apify's UNBLOCKER proxy return the same bytes and cost about $0.001 each. This Actor therefore runs direct by default. A proxy group is there in the input if your own runs ever start being refused, and it is off until you turn it on.

The trap this Actor is built around

Five public LinkedIn paths answer HTTP 200 with half a megabyte that is the login screen, not the page you asked for:

Path	Answer	Body
/company/<slug>/about/	200 — login page	488 084 bytes
/company/<slug>/people/	200 — login page	491 287 bytes
/company/<slug>/posts/	200 — login page	490 985 bytes
/company/<numeric id>/	200 — login page	484 081 bytes
/search/results/people/	200 — login page	52 486 bytes

Neither the status code nor the body size can tell them apart from a real page — a real company page measured anywhere from 100 549 to 484 513 bytes. The only honest signal is the og:url meta tag, and this Actor reads it on every response. A page that turns out to be the login screen is reported as login_wall in the run report instead of being parsed into a row of blanks.

The same applies to what you paste in: if you copy an address while sitting on a company's People tab, the tab is stripped back to the company root, which does carry data.

Honest limits

• The full employee list is not available. /company/<slug>/people/ is behind the login for everyone who is not signed in. What a company page gives a signed-out reader is 1-4 named employees, measured on four companies. No signed-out scraper can do better; anything claiming a complete employee roster is using a logged-in cookie.
• Keyword search does not exist here. See above — the endpoints are closed. The filters in this Actor run on rows it has already fetched, and they say so.
• LinkedIn masks some fields for signed-out readers. Measured on /in/jaycarney: all 11 job titles came back as asterisks. They are dropped rather than delivered, and counted in masked_job_titles so you know it happened.
• connections is a floor, not a count. LinkedIn prints "500+" for most people. The numeric column holds 500 and connections_label holds the string exactly as printed.
• Slugs are not brand names. tesla and intel both answer HTTP 404 — those companies sit on other slugs. Copy the address from the page.
• founded and specialties are often absent. Microsoft publishes no founding year; Stripe and Notion publish no specialties.

Running it on a schedule

Turn on Monitor mode and the Actor remembers what it already delivered, in a named key-value store that survives between runs. The next run returns only pages that are new or whose details moved, each labelled NEW or UPDATED with changed_fields naming what was there before.

Follower and connection counts are deliberately not watched: they drift hourly, and watching them would label every row UPDATED on every run, which is the same as having no monitor mode at all.

This matters more than it sounds in this niche. harvestapi/linkedin-company shows 10 897 785 runs against 21 293 users — 512 runs per user (Apify Store API, 2026-09-17). People schedule this kind of scraper, and without memory a daily run bills them for the same rows every morning.

When a run returns nothing

It tells you why, in the log and in RUN_REPORT: which addresses answered 404, which came back as the login page, which filter removed how many rows, or that monitor mode found everything unchanged. A successful run with an empty dataset and no explanation is the worst thing a paid scraper can do.

Output shapes

• Compact rows replaces the long lists with their lengths — a company row measured at 14 KB becomes under 2 KB.
• Drop empty fields leaves out what is blank on a given row while keeping the identifying columns. For AI agents and anything paying per token.

Verification

• python3 -m tests.test_logic — 222 checks on 11 real responses saved from the cloud on 2026-09-17, no network needed.
• python3 tools/verify_readme.py — every number on this page traced back to the code or the saved responses.
• python3 tools/prove.py — breaks the Actor on purpose, 42 different ways, and fails if any break goes unnoticed.