Fast LinkedIn Jobs Scraper — $0.50 per 1,000

Bulk LinkedIn job listings, cheap and quick: title, company, location, the exact posting date, and links to both the job and the company.

Ten jobs per request. 1,000 jobs is 100 requests, not 1,100.

Why this one is fast

Most LinkedIn job scrapers open every job's own page to read its description and applicant count. That is one HTTP request per job — accurate, and ten times the work.

This Actor reads only the search results, which arrive ten at a time:

	requests for 1,000 jobs
per-job scrapers	~1,100
this one	100

Same job list. A tenth of the requests, a tenth of the time, and a price that reflects it.

If you need applicant counts, use the sibling Actor — LinkedIn Jobs Scraper with Applicant Counts. It opens each job page, so it costs more and takes longer, and in exchange it tells you how many people applied and how fast that number is climbing. Different jobs, different tools.

The date is a real date

LinkedIn's search results show "3 days ago". This Actor reads the machine-readable datetime attribute sitting behind that text and returns 2026-08-20.

Relative dates rot the moment you store them. A dataset full of "3 days ago" is worthless a week later; a dataset full of ISO dates is still true.

What you get

job — one row per job.

field	meaning
title, company, location	the posting
postedOn	exact date, YYYY-MM-DD
activelyHiring	LinkedIn's "Actively Hiring" badge
jobUrl	direct link to the job
companySlug, companyUrl	the company's LinkedIn page — normalised, so a UK posting linking to uk.linkedin.com still comes back as a usable handle
searchKeywords, searchLocation	which of your searches surfaced it

error — anything that failed, written where you will actually see it.

Several searches in one run

{
  "searches": [
    { "keywords": "backend engineer", "location": "Berlin" },
    { "keywords": "data engineer", "location": "Munich" },
    { "keywords": "platform engineer", "location": "Remote" }
  ],
  "maxJobs": 300,
  "datePosted": "past-24-hours"
}

One run instead of three: one start charge instead of three, one rate-limit budget instead of three competing ones.

The same job often appears in several searches. By default you receive it — and pay for it — once, and searchKeywords tells you which search found it first. Set dedupeAcrossSearches: false if you would rather see every occurrence.

Three things it gets right

It never charges you twice for the same job. Deduplication happens before delivery, not after, so the count you are billed for is the count of distinct rows you received.

It stops exactly at maxJobs. Pages arrive ten at a time, so a naive implementation asked for 25 and delivers 30. This one delivers 25.

A failed fetch becomes a row, not a log line. Nobody reads run logs. Failures land in the dataset as error rows, and the run is marked failed when nothing came back at all. A 429 is retried with backoff before it is called a failure, because "too many right now" is not the same as "this search is broken".

No login. Not as a policy — as a property of the code.

This Actor never signs in, never asks you for a session cookie, and never sends one. It reads LinkedIn's public guest job endpoint, the same results an anonymous visitor sees.

That is enforced, not promised:

• The request headers are a frozen object with no Cookie and no Authorization field, and nothing can add one at runtime.
• A guard rejects any attempt to attach a credential header, and the input schema refuses any field whose name looks like cookie, session, token, auth or password.
• Unit tests assert all of the above.

If a competing tool asks you to paste your li_at cookie, it is operating your LinkedIn account on your behalf. This one cannot, by construction.

What you pay for

event	price
Actor start	$0.01 per run
Job	$0.0005 — $0.50 per 1,000

Duplicates and failed fetches are not charged.

Limits worth knowing

• No description, no applicant count, no salary. Those live on each job's own page, and fetching them is exactly what this Actor skips. The sibling Actor gets them.
• Guest search results thin out several hundred results deep; LinkedIn does not serve unlimited pages to anonymous visitors.
• The rate-limit budget persists in a key-value store, so overlapping runs of this Actor share one budget rather than stacking up.

On data and privacy

This Actor collects job postings, not people. No applicant identities, no profiles, no contact details.

It keeps no history — that is part of why it is cheap. The only thing written to storage is the shared rate-limit counter.

Running locally

npm install
npm test          # 22 unit tests, no network, including the no-login guarantees