LinkedIn Company Jobs Scraper

Give it a company. Get every role that company has open right now.

Most LinkedIn job scrapers take a search query. This one takes a company. Paste linkedin.com/company/stripe, get all of Stripe's open roles.

No login. No cookies. No account. Public pages only.

---

What you get

One row per open role:

Field	Meaning
title, location	The role and where it is
postedOn	The real posting date, not "3 days ago"
activelyHiring	Whether LinkedIn flags the company as actively hiring
jobUrl	Direct link

And one summary row per company: openJobs, byLocation, the resolved companyId, and collectionComplete (see below).

---

How complete is the list?

LinkedIn's public job listing does not paginate the way you would expect. Asking for start=20 does not return "results 21–30" — it returns a different random sample. Fetch the same company twice with naive paging and 40–60% of the job IDs differ. Offsets of 1000 or more are rejected outright.

So a naive scrape of a large company returns a sample, not the roster. Measured on a company with 880 open roles: naive paging returned 660 — a quarter of the roles silently missing, with no indication anything was wrong.

This Actor keeps sampling and measures its own coverage. Splitting the requests into two independent halves and comparing the overlap gives an estimate of the true total — the same mark-and-recapture method used to count fish in a lake. It keeps going until the estimated coverage reaches your target.

Every company row carries the result:

Field	Meaning
openJobs	Roles actually collected
estimatedTotal	Estimated true number of open roles
coverage	Fraction collected (e.g. 1.0)
estimatedMissing	Roles believed still unseen
requestsUsed	What it cost to get there

Verified against that 880-role company: 880 collected, 880 estimated, coverage 1.0, in 452 requests.

---

Optional: what changed since last run

Closed roles vanish from LinkedIn and leave nothing behind, so "what disappeared" cannot be reconstructed after the fact — only recorded. Turn on trackChanges and each run compares against the last.

This is only reported when the comparison is sound. Two runs, both at full coverage, sixty seconds apart, on that same 880-role company:

opened: 0   closed: 0   changeMarginOfError: 0

Which is the correct answer — nothing changed in a minute. An earlier version of this Actor reported "170 opened, 159 closed" for exactly that case, because it was comparing two different samples. It now refuses to answer unless coverage is high, and reports changeMarginOfError so you can see how much of any number could be measurement noise.

Opened/closed come back as null, with a reason, when: it is the first run, coverage did not reach the target, or you changed the filters between runs (which changes which roles were in scope). Hiring pace additionally needs 7 days of observation.

Cost of certainty: full coverage of a 880-role company took ~450 requests and about 9 minutes. You are charged per job returned, not per request, so this costs you time rather than money. Set targetCoverage lower (default 0.99) if you would rather have speed.

---

Input

{
  "companies": [
    "https://www.linkedin.com/company/stripe/",
    "anthropicresearch",
    "1035"
  ],
  "maxJobsPerCompany": 1000,
  "location": "United States",
  "datePosted": "past-week",
  "workType": "remote"
}

• companies — company URL, slug, or numeric ID. Country subdomains (uk.linkedin.com/...) work too.
• location, keywords, datePosted, workType, experience — optional filters, applied on top of the company filter.
• maxJobsPerCompany — default 1000, max 5000. Set it above the company's real number of open roles. You are charged per job returned, not per request, so a generous ceiling costs nothing extra for a smaller company.
• trackChanges — off by default. See above for when it is worth turning on.

---

Pricing

Pay per event. You are charged for what you receive.

Event	Price
Run started	$0.01
Per company	$0.01
Per job	$0.0008 ($0.80 / 1,000)

Job rows are priced the same as a plain listing scrape, because that is what they are.

Failed company lookups are not charged. A company with zero open roles still returns a company row — "they are not hiring right now" is an answer, not a failure.

---

How it works

Reads only LinkedIn's public, logged-out job listing pages — 10 roles per request. Because each request returns a fresh sample rather than a fixed page, the Actor keeps requesting until several rounds in a row bring nothing new, then stops. A 670-role company took about 93 requests this way.

The company ID is resolved from the public company page using two independent markers that must agree. If they disagree, the Actor returns an error instead of a guess — returning another company's jobs under your company's name would be worse than returning nothing.

The line this Actor does not cross

Logging in is a design decision, not a promise:

• Request headers are a frozen object. Cookie and Authorization cannot be attached at runtime.
• Input fields that look like credentials (cookie, session, token, li_at, password) are rejected.
• Both are covered by unit tests.

---

Related Actors

Actor	Use it when
LinkedIn Jobs Scraper with Applicant Counts	You want applicant counts and how fast they grow
Fast LinkedIn Jobs Scraper	You want volume and speed, by search query
LinkedIn Company Scraper with Headcount Growth	You want employee counts and growth
LinkedIn Company Posts Scraper	You want what a company publishes and how it lands

Pair this with the headcount scraper: headcount tells you how big a company is, open roles tell you where it is going next.