How to scrape LinkedIn job postings without logging in

Can you scrape LinkedIn jobs without logging in or using cookies?

Yes, and that is the whole design of the LinkedIn source in Datapika's job-board-scraper. LinkedIn publishes its job search results on public pages that a signed-out visitor can open, and the scraper requests those pages directly. It never asks for a LinkedIn username, password, li_at session cookie, or browser extension, so nothing you own is exposed to a restriction notice, and there is no cookie to refresh when it expires. The scraper's documentation states that it does not log in to any account, does not touch private candidate or recruiter data, and does not circumvent authentication; it only collects postings employers published to be found. That also means it cannot reach anything a session unlocks, such as submitting an Easy Apply form or reading applicant details. What you get is the public posting: title, company, location, date, seniority, and the description text. For most sourcing, lead generation, and market research pipelines that is exactly the set that matters.

• No LinkedIn account, password, or li_at cookie in the input; the only required field is searchTerm
• Reads public job search pages, the same ones a signed-out visitor loads
• Nothing behind a login is touched: no Easy Apply submission, applicant lists, or member profiles
• No browser extension and no session to refresh when LinkedIn rotates cookies
• The default residential proxy carries the requests, so your office IP is never shown to LinkedIn

What fields does a LinkedIn job scraper return?

Every LinkedIn row lands in the dataset with the same flat schema the other seven boards use, plus one field the README ties to LinkedIn alone: job_level, the seniority label LinkedIn attaches to a posting. Alongside it you get the source job id, title, company, location, date_posted, job_type, is_remote, the site value linkedin, and, when the posting shows them, job_function, listing_type, company_industry, company_url, and company_logo. Salary fields have a salary_source marker: direct_data when LinkedIn shows a range, or description when the number was parsed from the text, and enforceAnnualSalary converts hourly and monthly figures to yearly. Two fields depend on linkedinFetchDescription: description, delivered in Markdown by default or HTML on request, and job_url_direct, the employer's own apply page when one exists. Emails found in the description are pulled into their own array. Each row also records search_term, matched_search_term when you run several queries, and a scraped_at ISO timestamp. The table below marks which fields LinkedIn actually fills.

• job_level is LinkedIn-only: the seniority tag LinkedIn shows on the posting
• Core row: id, title, company, location, job_url, date_posted, job_type, is_remote, site
• Salary: salary_min, salary_max, salary_currency, salary_interval, with salary_source telling you whether it came from board data or parsed text
• linkedinFetchDescription adds description (Markdown or HTML) and job_url_direct
• emails array extracted from the description text
• search_term, matched_search_term, and scraped_at on every row

What are the quirks of scraping LinkedIn compared with other boards?

LinkedIn behaves differently from Indeed in four ways that shape how you configure a run. First, LinkedIn rate-limits search traffic at roughly 100 results per IP address, which is why the proxy configuration defaults to Apify residential proxies; a single fixed IP hits that ceiling quickly on a large sweep, while rotating residential IPs spread the requests. Second, the search listing does not include the posting body, so linkedinFetchDescription triggers extra requests per job to collect the description and direct apply URL, making LinkedIn runs slower than the same query on Indeed. Leave it off when titles and companies are enough. Third, LinkedIn rejects the combination of hoursOld and easyApply in one search; pick one, or run two searches. Fourth, LinkedIn is the only board with company targeting, so linkedinCompanyIds can restrict results to named employers. Because LinkedIn is global, countryIndeed has no effect on it; steer by location and distance, which defaults to 50 miles. Rows still stream into the dataset 5 to 20 seconds after the run starts.

• Rate limit: about 100 results per IP, so residential proxies are the default and the right choice for large runs
• linkedinFetchDescription is off by default; enabling it adds requests and time but returns description and job_url_direct
• hoursOld and easyApply cannot be combined on LinkedIn; Indeed has its own filter conflicts
• linkedinCompanyIds restricts a search to specific employers, a LinkedIn-only feature
• countryIndeed is ignored for LinkedIn; use location and distance (default 50 miles)
• maxResults caps at 100 per board per search term, and searchTerms allows up to 5 queries per run

How do you monitor specific companies' LinkedIn job postings?

Recruiters, sales teams, and analysts often care about a handful of employers rather than a keyword. LinkedIn is the one board where the scraper can pin a search to named companies: pass the numeric IDs LinkedIn assigns to their company pages in linkedinCompanyIds, and the run ignores every other employer. The documented example is ["1441", "2382910"] with searchTerm product manager and location San Francisco. Pair that with hoursOld set to 24 or 168 and a daily Apify schedule, and each run returns only the roles those companies opened since the last one, which is the raw material for a competitor hiring tracker or a buying-signal feed. Use searchTerms with up to five titles to cover a whole function, since every row is tagged with matched_search_term. Because output is deduplicated across boards, adding Indeed to the same run brings in the company size, revenue, and rating columns shown in the README's sample Indeed row without doubling the row count. The full board list is at datapika.com/scrape.

• linkedinCompanyIds accepts a list of numeric company IDs, for example ["1441", "2382910"]
• hoursOld 24 on a daily schedule returns only postings opened since yesterday
• searchTerms takes up to 5 titles and stamps matched_search_term on every row
• Cross-board deduplication means a posting found on both LinkedIn and Indeed appears once in the dataset
• Attach a webhook to push each finished run into Slack, Sheets, or a CRM

How do developers and AI agents pull LinkedIn jobs from Datapika?

Three paths lead to the same dataset. In the Apify Console you fill the form, run, and download JSON, CSV, Excel, XML, or RSS from the Output tab. From code, POST your input to the run endpoint for openclawai~job-board-scraper with your Apify token, or call run-sync-get-dataset-items to receive the job rows in a single response; the Python and Node clients wrap both in one call. For agents, add https://mcp.apify.com/?tools=fetch-actor-details,openclawai/job-board-scraper to Claude Desktop, Cursor, or any MCP client, and the assistant can ask for remote senior React roles posted on LinkedIn in the last 24 hours and reason over typed rows instead of HTML. Set a maximum total charge on the run in Console and keep maxResults low while testing. Runs default to 4 GB of memory, which matters only when you add the browser-driven boards; a LinkedIn-only run finishes quickly. Zapier, Make, and n8n can trigger scheduled runs and route rows onward.

• Console: form in, dataset out as JSON, CSV, Excel, XML, or RSS
• REST: POST to api.apify.com/v2/acts/openclawai~job-board-scraper/runs, or run-sync-get-dataset-items for one call
• Python: pip install apify-client, then client.actor("openclawai/job-board-scraper").call(run_input={...})
• MCP: mcp.apify.com with the job-board-scraper tool enabled for Claude, ChatGPT, or Cursor
• Schedules plus webhooks turn one query into a daily LinkedIn feed

Questions, answered

Keep reading