LinkedIn Jobs Salary Data — Filter by Pay

Scrape public LinkedIn jobs and get the pay as structured data — minimum, maximum, currency, and whether it is hourly or yearly — normalized to a yearly figure so you can filter to jobs paying over a threshold and see the real pay distribution. No login, no cookies.

$1.90 per 1,000 jobs read — 100 jobs cost $0.20 including the run start, so a scheduled run that reads 20 jobs costs about 5 cents. Measured on October 8, 2026: 30 US software-engineer jobs, 28 of them (93%) with pay parsed into numbers — the pay is read from the description and from LinkedIn's own "Base pay range" box; 30 Canadian ones, 24 with pay, all in CAD.

Running it on a schedule? Don't pay for the same job twice. Every job read is charged, and with Posted within left on Any time each run reads the jobs it already gave you. Set Posted within to the shortest window that still covers the time between runs — Past 24 hours for a daily run, Past week for a weekly one — and each run reads mostly new jobs, with nothing posted between runs skipped. Running several times a day, Past 24 hours is the shortest choice, so the same day's jobs are still read again.

What every other jobs scraper leaves you to do

The popular LinkedIn job scrapers hand you the description as a wall of text and let you dig the salary out of it. This one parses the pay into numbers you can sort, filter and average — annualSalaryMin / annualSalaryMax, currency, period, and the original phrase in salaryText — and lets you ask "show me jobs paying over $150k" as an input, with the fill rate reported on every run.

This Actor does that work, honestly:

• Pay as fields. $150K – $220K in the text becomes annualSalaryMin: 150000, annualSalaryMax: 220000, currency: USD, salaryPeriod: year.
• Hourly and monthly normalized. $46 – $50 per hour becomes a yearly figure (× 2080 hours) so a warehouse job and a director job sit on the same axis. The original is kept too.
• Filter by pay. Set a minimum yearly salary and get back only the jobs that reach it.
• The real distribution. Every run reports the median and range of pay across the jobs that stated it.

Run it again and again

• On a schedule — save your input as a task and add a Schedule: the same search every morning, for example at 07:00. Send each run to Google Sheets, Slack or email with an integration on the task.
• Watch for changes — Set Posted within to Past 24 hours: a daily run then reads only the jobs posted since the day before, with their pay.
• In bulk — Raise Max jobs (up to 1,000) to read a whole search in one run.

Honest about what isn't there

About 6 in 10 US jobs state their pay (we measured it live — pay-transparency laws made US postings the most forthcoming; elsewhere it is lower). The rest simply do not write a number down. This Actor does not invent one. Each job is tagged salaryFound: true/false, and the summary tells you the fill rate every run.

And it does not mistake other numbers for salary. Job descriptions are full of dollar figures that are not pay:

Looks like money	What it really is	Handled by
$20M+ raised from investors	funding	rejected — near "raised/funding/series"
$800 billion market	market size	rejected — implausible as a yearly wage
$5,000 signing bonus	one-off bonus	rejected — near "bonus/signing"
Annual maximum out of pocket $200,000	insurance benefit	rejected — near "deductible/insurance/out-of-pocket"
on-target earnings of $175,000	OTE/commission	skipped in favour of the base salary

The rule that catches most of them: normalize to a yearly figure first, and if it lands outside $8,000–$2,000,000, it is not a wage. On top of that, a number is only taken as pay when its own label says so ("salary", "pay range", "per hour"), never a bare figure sitting in a sentence.

What you get

Two kinds of row, tagged by type.

job — one per returned job:

field	meaning
salaryFound	whether the posting stated pay
currency	USD, GBP, CAD, … from the symbol or code used. A bare $ takes the currency of the job's location (a Toronto job is CAD, a Sydney job AUD) unless the posting says USD; then currencyFromLocation is true
salaryPeriod	year / hour / month — how it was originally written
salaryMin, salaryMax	the range in that original period
annualSalaryMin, annualSalaryMax	normalized to a yearly figure for comparison
salaryText	the exact phrase from the posting, so you can check us
title, company, location, postedOn, seniority, employmentType, jobUrl	the posting

summary — one per run: how many jobs stated pay (salaryFillRatePct), how many were returned or dropped, and the pay distribution (annualSalaryMedian, min, max) across the jobs that stated it, plus a breakdown by currency and period.

Sizing and cost

maxJobs is how many jobs to examine, not how many come back. Pay lives on the job page, so every job is opened and read. You are charged per job page opened — that is your cost ceiling. With a minimum-salary filter on, fewer jobs match, so raise maxJobs to get more matches.

requests ≈ ceil(maxJobs / 10)  +  maxJobs

Pay per event, charged only for real work:

event	price	when
Actor start	$0.01	once per run
Job listed	$0.0004	one job seen in the listing
Job examined	$0.0015	one job page opened and read for pay

Together that is $1.90 per 1,000 jobs read. A daily run of 50 jobs costs about $3 a month.

Our own running cost is about **$0.023 per 1,000 rows** of Apify platform usage at 256 MB (same 30-job search before and after, 11 October 2026; it was $0.113 at 512 MB in September — [how it was measured](https://dev.to/apify/i-measured-what-my-11-actors-cost-to-run-the-96x-spread-was-mostly-one-config-field-hoj)) — already included in the prices above; nothing is billed on top.

A failed fetch is never charged. The $0.01 run-start fee is the one charge every run pays, even one that returns nothing.

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

This Actor never signs in, never asks for a session cookie, and never sends one. The request headers are a frozen object with no Cookie and no Authorization, and nothing can add one at runtime; a guard rejects any credential header, and the input schema refuses any field that looks like cookie, token or password. Unit tests assert all of it. The line the courts draw is whether you logged in (Meta v. Bright Data, 2024) — this Actor cannot, by construction.

Input

{
  "keywords": "software engineer",
  "location": "United States",
  "datePosted": "past-week",
  "minSalary": 150000,
  "maxJobs": 200
}

Leave minSalary empty (and onlyWithSalary off) to get every job, each tagged with whether pay was found and, where it was, parsed into fields.

On data and privacy

This Actor collects job postings, not people. It does not read, store or return applicant identities, profiles, names or contact details. It keeps no history between runs — the only stored state is this run's rate-limit budget. Company logos are not redistributed.

Running locally

npm install
npm test          # unit tests, no network, including the no-login guarantees and the salary parser's traps

**Something broke or looks wrong?** Open an issue on this Actor's Issues tab and I'll look at it. **Found it useful?** A short review on the Store page helps other people find it.

For AI agents

This Actor works well as an agent tool: the input schema is small and fully described, every run returns structured rows, and failures come back as data rather than silent gaps. Use it when you need to:

• scrape LinkedIn jobs with the salary parsed into numbers
• find LinkedIn jobs paying over a yearly salary threshold
• get the salary distribution (median, range) for a job search

How the salary parser was tested

The write-up of the six ways it was quietly wrong on real postings, and the fixes, is published under the Apify organisation on DEV: I scraped 89 job postings to find out how my salary parser was lying to me

The parser and every regression test in that post are open source, with no dependencies: northbell-dev/honest-scraping

---

More no-login scrapers by northbell

Every one of these reads only public pages — no login, no cookies — and most of them record the numbers that cannot be back-filled if you don't capture them today.

LinkedIn jobs

• LinkedIn Jobs Scraper with Applicant Counts — jobs plus how fast applicants are arriving
• LinkedIn Jobs Scraper — Filters That Actually Work — the experience/workplace filters LinkedIn silently ignores, applied for real
• LinkedIn Jobs Salary Data — Filter by Pay — salary parsed into numbers so you can filter by yearly pay
• Fast LinkedIn Jobs Scraper — bulk job listings, cheap and quick
• LinkedIn Company Jobs Scraper — every open role at a company you name

LinkedIn companies

• LinkedIn Company Scraper with Headcount Growth — the real headcount and how fast it's growing
• LinkedIn Company Posts + Engagement — a company's posts with exact reaction and comment counts

App stores

• App Store Rank & Rating Scraper — iOS keyword rank and rating changes over time
• Shopify App Reviews Scraper — Filter & Sort by Rating — exact per-star review counts, filter and sort
• Google Play Rating & Review Tracker — an Android app's rating tracked day by day