LinkedIn Jobs Scraper

Collect public LinkedIn job listings without a LinkedIn account. Search by keywords and location, or paste public LinkedIn Jobs search URLs. Each useful delivered job has a stable jobId and canonical URL. Optional detail collection adds descriptions, salaries, application information and company fields when LinkedIn makes them available.

Start with five jobs, inspect the data, then increase your result limit. This actor collects a public search sample; it does not promise every matching job or a complete LinkedIn inventory.

Quick start

{
  "keywords": "software engineer",
  "location": "United States",
  "maxResults": 5,
  "maxPages": 5,
  "deepFetchAll": false,
  "outputPreset": "recruiting"
}

To collect descriptions and compensation, enable deepFetchAll. To collect company details, enable includeCompanyDetails; this also requests the job detail page to find the actual company URL. Company enrichment visits at most 25 distinct companies per run.

For a pasted search URL:

{
  "workflow": "searchUrls",
  "urls": "https://www.linkedin.com/jobs/search/?keywords=python&location=Berlin&f_TPR=r604800",
  "maxResults": 5,
  "deepFetchAll": true,
  "outputPreset": "full"
}

Use one URL per line, up to 20. Legacy API lists are also accepted. In Auto mode URLs take precedence over keywords; Keyword Search ignores URLs. Invalid entries alongside valid URLs appear in ERRORS; invalid-only URL input fails instead of silently changing the search.

Search and coverage

Collection uses LinkedIn's public guest jobs endpoint through direct HTTP. Offsets advance by 10. Cards can overlap; deduplication uses job ID, preserving distinct jobs with the same title, company and location. maxPages limits pages across all searches in the run. Searches are visited in input order; later searches are visited after earlier ones return an empty page. Narrow queries or run separate searches when you want balanced coverage across locations.

URL parameters keywords, location, geoId, distance, f_TPR / f_TP, f_C, f_AL and f_EA are forwarded. Legacy experience, job-type and workplace filters become search words. The remote, experienceLevel and jobType selections are search preferences, not guaranteed structured filters. LinkedIn controls ranking and may broaden or reinterpret a query; inspect returned titles and locations. Unsupported URL filters are not implemented.

onlyRemote, onlyWithSalary, minRecruiterScore and deduplicateCompanies are local filters applied before delivery and charging. Salary and remote filters request job detail pages. Work mode is heuristic: unknown and hybrid jobs are excluded by onlyRemote. A description mentioning remote work is not an employer guarantee.

Source access varies by region and datacenter. No proxy or external scraping key is configured. Login walls, HTTP errors and rate limits are reported, never disguised as a successful empty search. Network failures can retry within the time budget; access denials and rate limits do not retry. An incomplete detail page leaves its valid search card available, with detailFetched=false and detailFailures in the summary. Missing company fields stay absent.

Example workflows

These small inputs can be copied into the Console or API:

Goal	Input
Quick discovery	{"keywords":"software engineer","location":"United States","maxResults":5,"outputPreset":"compact"}
Description and company research	{"maxResults":2,"deepFetchAll":true,"includeCompanyDetails":true,"outputPreset":"full"}
Disclosed compensation sample	{"maxResults":2,"maxPages":2,"onlyWithSalary":true,"outputPreset":"full"}
Remote language sample	{"keywords":"remote software engineer","maxResults":2,"maxPages":2,"onlyRemote":true,"outputPreset":"full"}
One job per company, CSV	{"maxResults":4,"maxPages":2,"deduplicateCompanies":true,"exportFormat":"csv"}

Results and analysis

The Dataset contains only useful jobs identified by source ID, title, company and location before field selection. Available fields include:

Group	Fields
Identity	jobId, jobCanonicalUrl, jobUrl, jobTitle, companyName, location
Search facts	postedDate, companyLogo, salaryRawText when present
Optional detail	description, descriptionHtml, jobType, seniorityRaw, industries, application information, available applicant and poster fields
Optional company	companyWebsite, companyIndustry, companyDescription, companyEmployeesCount
Heuristic analysis	annualized salary, work mode, skills, benefits, seniority, category, freshness, DEI text signals, recruiter score
Provenance	scrapedAt, detailFetched, sourceUpdatedAt=null, freshnessVerified=false, analysisIsHeuristic=true

scrapedAt is collection time, not a verified source update. Posting age is calculated from the observed date; it does not prove a job is still open. Salary USD figures are approximate annualized calculations: 40 hours/week, 52 weeks/year, 22 days/month and fixed approximate currency factors. A missing period is assumed yearly. salaryCalculation labels these assumptions. For company size ranges, companyEmployeesCount is a lower bound labeled by companyEmployeesCountBasis.

Recruiter score is a heuristic 0–100 sum: observed hiring count (up to 25 points), posting age (15), disclosed compensation (15), skills (10), benefits (10), seniority (10), remote language (5) and visa language (3), bounded at 100. Hiring counts refer to the running delivered sample, so scores depend on input order. They do not prove budget, buying intent or company-wide vacancy counts. recruiterScoreScope records this limitation.

Outreach assets are neutral drafts and search links. They do not assert your track record, candidate network or business relationships. extractPayTransparencyLaw is retained for input compatibility but returns payTransparencyAssessment=not_assessed and null compliance/state. This actor does not make legal compliance determinations.

Output controls and continuation

outputPreset selects Compact, Recruiting (default) or Full JSON. exportFormat=csv creates flat records that Apify can export as CSV. Raw-field and analysis switches apply to both formats. Identity and provenance are always included. Analysis can use observed fields even if the raw field is hidden from the output.

The key-value store always contains:

• SUMMARY: delivered count, status, page offsets, new job IDs, filtered/duplicate counts, source limits and nextInput.
• ERRORS: safe input/source diagnostics outside the paid Dataset.

writeSummary=false disables optional aggregate statistics and TOP_HIRING_COMPANIES / TOP_JOBS; operational SUMMARY and ERRORS remain available. Company aggregates refer only to delivered jobs.

To resume, use the complete object in SUMMARY.nextInput as the next run's input. It contains a search cursor and previously seen IDs, bound to the same search/filter settings. You may change page/result/time limits. Search order can change between runs, so continuation prevents duplicate IDs but cannot guarantee gap-free coverage. A stalled source has no usable continuation. A result/page/time cap is not complete coverage; check searchComplete.

The collection timeout is a shared run budget. Requests are capped by remaining time. maxConcurrency is an upper bound; current scheduling is sequential to reduce source throttling. deepFetchTopN collects one representative job for each of the first N distinct observed companies, not ranked companies.

Pricing

Provider price: $0.90 per 1,000 useful delivered jobs, plus $0.00005 per actor-start event (one per GB, minimum one). Apify platform resource usage is paid by the user in addition to provider events. Check the Pricing tab for the applicable current rates and platform estimate.

Only delivered useful rows trigger result events. Errors, duplicate IDs, rejected filters and summary records do not trigger result events. maxResults and Apify's maximum total charge limit control paid delivery; the actor checks charge capacity before source requests and respects the accepted charged count.

MCP and AI agents

Use the hosted Apify MCP tool apivault_labs--linkedin-jobs-scraper. Start with maxResults=5 and Compact output. Read the Dataset, SUMMARY and ERRORS before treating the search as complete. Enable detail fetching when descriptions or salaries are needed; treat derived fields as heuristic and missing fields as unknown.

API name: apivault_labs/linkedin-jobs-scraper. The same input contract is used by API, Console and MCP clients.

LinkedIn job-market research workflows

This LinkedIn job scraper helps recruitment operations teams and researchers turn public search results into a linked, structured review file. Start with cards for a compact vacancy sample, then request detail pages only when the question needs descriptions, compensation or company information. Public access can be incomplete even when the same listing is visible in your logged-in browser.

Question	Useful starting point	Keep the limitation visible
Which openings match this role/location?	Compact card search	Source ranking and bounded page coverage
What skills are mentioned?	Detail fetch and full output	Keyword heuristics depend on available text
Which postings disclose parsable pay?	onlyWithSalary	Unknown/unparsed pay is excluded
Which companies occur in the sample?	Company deduplication or aggregates	Counts are sample-specific
What can I export to a spreadsheet?	CSV output	Provenance and heuristic labels still matter

Compact role and location discovery

This three-job request avoids optional detail and company fetches. It is a good first step before deciding whether deeper collection is necessary.

{
  "workflow": "keywordSearch",
  "keywords": "data analyst",
  "location": "London",
  "maxResults": 3,
  "maxPages": 1,
  "deepFetchAll": false,
  "outputPreset": "compact"
}

A small compensation research sample

The local pay filter uses available parsable salary evidence. It is not a minimum-salary filter or evidence that missing salaries are zero. Review source salary text and calculation assumptions before comparing annualized USD values.

{
  "keywords": "software engineer",
  "location": "United States",
  "maxResults": 3,
  "maxPages": 2,
  "onlyWithSalary": true,
  "deepFetchAll": true,
  "outputPreset": "full"
}

Company-level spreadsheet review

Keep one encountered opening per company to reduce repetitive rows in an account research file. The resulting sample is not a full count of each company's jobs. Optional company-page collection may add fields but cannot guarantee them.

{
  "keywords": "product manager",
  "location": "United States",
  "maxResults": 3,
  "maxPages": 1,
  "deduplicateCompanies": true,
  "includeCompanyDetails": true,
  "exportFormat": "csv",
  "outputPreset": "full"
}

Reuse a public search URL

Use a public LinkedIn Jobs search rather than a signed-in collection or private URL. Changing supported search parameters changes discovery; it does not bypass source access restrictions. This example requests a small recent Python sample.

{
  "workflow": "searchUrls",
  "urls": "https://www.linkedin.com/jobs/search/?keywords=python&location=Berlin&f_TPR=r604800",
  "maxResults": 3,
  "maxPages": 1,
  "outputPreset": "compact"
}

Interpreting and handing off hiring signals

Separate source observations from derived fields. A title, canonical job URL and observed employer support a vacancy research citation. A heuristic work mode, skill match, salary calculation or recruiter score supports prioritizing manual review under the stated assumptions. These values are not candidate assessments and should not be used to automate employment decisions.

For compensation reporting, retain salaryRawText alongside any computed figures. For freshness reporting, keep scrapedAt, postedDate and freshnessVerified rather than replacing missing publication dates with collection time. For company research, keep missing company information as unknown and record the sample size alongside a company aggregate.

Read stored results with the Dataset ID returned by the run. Exporting those rows as CSV does not require another Actor run. When continuing discovery, copy the complete SUMMARY.nextInput rather than constructing offsets by guesswork. The source can reorder results between runs; continuation deduplicates observed IDs but does not turn a changing search into a gap-free historical database.

LinkedIn Jobs scraper FAQ

Do I need a LinkedIn login? The Actor uses public guest access. No LinkedIn account is required as input; an Apify account/token is needed for authenticated API automation. Public access limits still apply.

Will more concurrency improve coverage? Current scheduling is sequential to reduce throttling. Narrower queries, small limits and clear page diagnostics are more useful than assuming concurrency means a complete inventory.

Why are description or company fields missing? Detail access can fail while a valid search card remains useful. Check detailFetched and the summary's failure counts; do not treat missing fields as negative business facts.

How much do ten jobs cost? Ten delivered jobs have $0.009 in result events, plus the applicable start event and user-paid platform resources. Detail and company requests can increase resource usage without increasing delivered rows. Use a small maxResults and the run's charge controls before increasing scale.

Daily company job monitoring

Recruitment agencies and B2B teams can follow a fixed list of companies and receive only job IDs this monitor has not delivered before. This mode uses the same Actor; ordinary searches keep their existing behavior.

{
  "monitorKey": "my-clients",
  "companyIds": ["1035"],
  "keywords": "software engineer",
  "location": "United States",
  "postedWithin": "week",
  "maxPages": 2,
  "maxResults": 5
}

The first run returns a paid baseline of the bounded search sample. Repeat the same input on subsequent days: every search restarts at page zero, known job IDs are skipped, and newly observed jobs go to that run's ordinary Dataset. You can schedule runs using Apify scheduling; this Actor does not create a schedule automatically. A repeat with no unseen jobs has zero job-result events, but Actor start and platform storage/compute charges still apply.

Where the history lives

History lives in the running user's Apify account, under Storage → Key-value stores. It is an automatically created named store, not the temporary default store of one run. Its name is linkedin-jobs-monitor- followed by a hash of your monitorKey; SUMMARY.monitor contains the actual name and store ID. It stores delivered job IDs, their first-observation times and recovery metadata. Job data remains in each run's Dataset. No separate server or database is required.

A matching named Request queue ending in -lock is used only for an exclusive writer lock; its placeholder URL is never crawled. Keep both storages for repeat runs. Access is scoped by the Apify credentials of the run. Grant the Actor the storage permissions required by Apify; it cannot fall back to the developer's account if those permissions are denied. Named storage incurs platform charges.

Different monitor keys have independent history. Changing company IDs, keywords, location, filters or output settings under an existing key fails with MONITOR_SETTINGS_CHANGED; use a new key for a new monitor. Result/page/time/retry limits may change. Company IDs are sorted and deduplicated. Pasted search URLs and continuation are excluded from monitoring; ordinary mode still supports them.

Delivery safety and limits

• Searches visit companies in rounds within the global maxPages/maxResults limits. Small limits may leave companies or deeper pages unchecked; inspect SUMMARY.pages. No complete LinkedIn inventory or gap-free monitoring is claimed.
• firstSeenAt is the time this monitor first delivered the job, not the publication date. Old or reposted listings can appear as newly observed.
• A concurrent run for the same monitor fails with MONITOR_BUSY before job delivery. Different keys can run independently. After an uncertain interruption, allow up to six minutes for the retained lease to expire, then start a new run. Do not resurrect/reboot an interrupted run in place.
• State advances after a successful Dataset delivery. A durable pending marker covers an interrupted write: after the retained lease expires, the next run checks the previous Dataset before sending that job again. Dataset-item billing is managed by Apify. Push requests are bounded to 30 seconds; state writes and delivery check the queue lease. This is recovery, not an atomic transaction across billing and storage. Missing/deleted evidence fails closed with MONITOR_RECOVERY_REQUIRED; keep the previous Dataset until reconciliation. With Limited permissions, an interrupted delivery first stops with MONITOR_RECOVERY_ACCESS_REQUIRED. Copy SUMMARY.monitorRecovery.retryInput for one recovery run: recoveryDatasetId is a read-only Apify storage picker granting access only to that previous Dataset. Remove it after successful recovery. Ordinary daily repeats do not need this field. No account-wide permission change is needed, and previous run metadata is not read.
• History remembers up to 10,000 delivered job IDs without automatic expiry or silent eviction. At capacity, new delivery stops with MONITOR_STATE_FULL. A new key starts another billed baseline; it does not preserve old deduplication.
• To remove a monitor, stop its scheduled/active runs and delete its named KVS and lock queue in Apify Console. Deleting history or choosing a new key allows old jobs to be returned and billed again. Never delete active monitor storage.
• Descriptions, salary, external apply URLs and company websites remain optional source-dependent fields. Enable deep fetch when needed; missing fields are not fabricated. No recruiter score proves a buying signal or guarantees revenue.

n8n and developer integrations

Use this Actor in your automation or application with the existing community integrations below. An Apify account and API token are required; Actor and platform charges follow the current pricing.

• n8n community node: n8n-nodes-apivault-linkedin-jobs. Install package name n8n-nodes-apivault-linkedin-jobs in a self-hosted n8n instance that permits community packages.
• n8n source and usage: GitHub.
• Python client and examples: GitHub.
• n8n source and usage: GitHub.

These are community packages. Publication on npm does not establish n8n verification or availability in n8n Cloud. Review the linked package README for supported inputs and setup.