LinkedIn Company Jobs Scraper & Monitor - Hiring Signals Feed

LinkedIn Company Jobs Scraper & Monitor - Hiring Signals Change Feed

Scrape and monitor public LinkedIn company job pages without a login, and turn them into a stateful hiring-signals change feed for recruiting alerts, ATS and RPO intelligence, B2B sales signals, and market research.

The Actor reports new, changed, reopened, and safely confirmed closed jobs. It requires no LinkedIn login or cookies from the user. Optional verification can add an official application URL, current job status, confidence, and ghost-job risk to the same dataset row.

What this LinkedIn jobs scraper and monitor does:

• monitor LinkedIn company job postings for changes on a schedule
• scrape the current job openings of any public LinkedIn company page, no login
• detect new job postings, edits, reopenings, and safely confirmed closures
• track competitor or target-account hiring activity as dated events
• deliver results as a dataset, API response, or signed webhook

This is a company and job-posting monitor, not a people-search or candidate-sourcing tool. Use it for repeat employer watchlists where a dated change feed is more useful than repeatedly checking the same public job pages by hand.

Quick start

{
  "companies": [
    "https://www.linkedin.com/company/github/"
  ],
  "stateNamespace": "auto",
  "closureConfirmationScans": 2,
  "verifyApplyLinks": false
}

Save the input as an Apify Task and schedule it daily. The first run emits the current openings as new. Later runs return only changes by default.

Accepted company inputs:

• canonical LinkedIn company URLs
• LinkedIn company jobs or search URLs containing f_C
• numeric LinkedIn company IDs

Use the current canonical company URL. If an obsolete slug redirects to a different company, the Actor rejects it instead of returning plausible data for the wrong organization.

Hiring signals workflows: ATS, RPO, sales, and research

LinkedIn job posting monitor for ATS and recruiting operations

Monitor target employers for new, changed, reopened, and confirmed closed roles. Send the dataset or webhook events to an ATS-side analytics layer, recruiting-operations dashboard, or internal alert workflow without collecting applicant or recruiter profiles.

The Actor provides a dataset, API output, and optional webhook delivery. It does not write into an ATS by itself; that final mapping remains part of the buyer's downstream automation.

RPO and staffing-company market mapping

Create one saved Task per client, desk, geography, or employer segment and keep stateNamespace set to auto. Each Task then maintains an isolated watchlist history that can support RPO market mapping or staffing business-development research without mixing client state.

Recruitment market intelligence API and dataset

Use changes-only mode for a dated hiring-movement feed. Use full-snapshot mode when the buyer needs the current open-job inventory on every run. The records can support employer, location, and role-family analysis, but polling cadence and public-page availability still determine what can be observed.

Company hiring signals for B2B account research

Watch target accounts for company-level signals such as a new function, location, or sustained expansion. Route relevant events to a CRM or research queue as a reason to investigate. A hiring event is not proof of budget, purchase intent, or an open sales opportunity.

What the Actor returns

• new: first time a job is seen
• changed: title, location, company, URL, or posting date changed
• reopened: a previously closed job reappeared
• closed: absent from the configured number of complete scans
• current: unchanged open job when full-snapshot mode is enabled

Every dataset row carries the full monitoring context:

Field	Description
🏷️ eventType	Lifecycle event: new, changed, reopened, closed, or current
🆔 jobId	Unique LinkedIn job identifier
📝 jobTitle	Job title as posted
🏢 companyId, companyName, companyUrl	Numeric LinkedIn company ID, name, and company page URL
🌍 location	Job location as posted
🔗 jobUrl	Direct URL to the LinkedIn job posting
📅 postedAt	Date the job was posted
⏱️ detectedAt	When this lifecycle event was detected
👀 firstSeenAt, lastSeenAt	First and most recent complete scans where the job was observed
🔀 changedFields	Which fields changed, for changed events
📡 source	Always linkedin_public_jobs
✅ verificationStatus, verifiedAt, verificationConfidence, verificationEvidence	Optional apply-link verification state, timestamp, 0-1 confidence, and evidence trail
🎯 officialApplyUrl, applyMethod, sourceProvider	Official ATS application URL, apply method, and detected ATS provider when verification is enabled
🚦 jobStatus	Live job status evidence from verification
👻 ghostJobRisk	Ghost-job risk signal: low, medium, high, or unknown
🛡️ safeToPublish, reviewRequired	Editorial guard flags for downstream publishing workflows
🌐 companyWebsite	Company website when verification resolves it

This row is from a real GitHub scan on 2026-08-25 (verification off, so verification fields are null):

{
  "jobId": "4442099874",
  "title": "Senior Software Engineer",
  "companyId": "1418841",
  "companyName": "GitHub",
  "companyUrl": "https://www.linkedin.com/company/github",
  "location": "Spain",
  "jobUrl": "https://www.linkedin.com/jobs/view/4442099874",
  "postedAt": "2026-08-11",
  "jobTitle": "Senior Software Engineer",
  "eventType": "new",
  "detectedAt": "2026-08-25T19:21:22.393Z",
  "firstSeenAt": "2026-08-25T19:21:22.393Z",
  "lastSeenAt": "2026-08-25T19:21:22.393Z",
  "changedFields": [],
  "source": "linkedin_public_jobs",
  "verificationStatus": "not_requested",
  "officialApplyUrl": null,
  "applyMethod": null,
  "jobStatus": null,
  "safeToPublish": null,
  "reviewRequired": null,
  "verificationConfidence": null,
  "sourceProvider": null,
  "companyWebsite": null,
  "verifiedAt": null,
  "verificationEvidence": [],
  "ghostJobRisk": "unknown"
}

The OUTPUT key-value-store record reports company coverage, completeness, warnings, failures, jobs seen, emitted events, verification, webhook delivery, rolling SLOs, and billing counters.

Safe partial results

LinkedIn's public guest pages can occasionally return a rate limit, repeated page, or incomplete inventory. The Actor handles that without inventing closures:

• transient requests are retried with fresh network sessions
• incomplete scans never advance missing-job counters
• incomplete scans never emit closed
• incomplete company scans are not billed
• failed or unusable companies appear in the run summary
• companies beyond the run's charge limit are skipped as charge_limit_reached and never scanned or charged, while the covered companies still complete
• useful results from other companies remain available

By default, a run succeeds with explicit warnings when at least one company returns usable inventory. It fails when no requested company produces usable inventory.

Set strictClosureQualityGate: true when a workflow must reject the entire run below 95% closure-safe coverage. A strict-gate failure preserves diagnostic dataset output but does not commit watchlist state, webhooks, or company-scan billing.

This separates operational run status from closure safety. A partial run can deliver safe additions and changes without ever turning missing rows into false closures.

Monitoring state

State is stored per watchlist so repeated runs can detect changes.

• Saved Tasks should leave stateNamespace as auto; each Task receives an isolated namespace.
• API callers should set one stable, unique namespace per independent watchlist.
• Use a new namespace for QA so production history is not changed.
• Runs sharing one namespace use a renewable lease to prevent concurrent state corruption. A run that starts while the previous run on the same watchlist is still working waits up to ten minutes for it to finish.

Two complete missing scans are required before a job closes by default. Increase closureConfirmationScans for more conservative closure detection.

Each run accepts up to 100 companies. The default inventory cap is 1,000 jobs per company and can be raised to 5,000. Reaching the cap before completeness is proven creates a safe incomplete scan, not a false complete inventory.

Changes-only and snapshot modes

The default is a changes-only feed:

{
  "emitInitialSnapshot": true,
  "emitCurrentSnapshot": false
}

For a full current snapshot on every run:

{
  "emitInitialSnapshot": true,
  "emitCurrentSnapshot": true
}

Snapshot mode produces more dataset rows and therefore costs more than changes-only monitoring.

Official apply-link verification

Verification is optional and off by default. Enable it when official application routes and live-status evidence are worth the additional child-Actor cost:

{
  "verifyApplyLinks": true,
  "maxJobsToVerify": 100,
  "verificationMaxTotalChargeUsd": 2
}

The Actor calls kamerozkan/linkedin-job-apply-link-verifier and merges valid verifier results into the default dataset. Malformed or missing verifier rows do not count as completed verification.

When strict verification is enabled, at least 95% of submitted jobs must receive a valid result. Otherwise, scan output remains available but watchlist state, webhooks, and company-scan billing are not committed, allowing a safe retry.

Use maxJobsToVerify and verificationMaxTotalChargeUsd as hard cost guards. The verifier is billed separately at the price shown on its Store page.

Webhooks

Set webhookUrl to an HTTPS endpoint. Non-empty runs send enriched events in batches. Add webhookSecret to receive an HMAC-SHA256 signature:

x-hiring-signals-signature: sha256=<hex digest of the exact request body>

Failed deliveries remain in a durable outbox and are retried on the next run with the same delivery ID, body, and signature. A webhook failure does not delete dataset output.

Recipes: common monitoring setups

Monitor a company's LinkedIn jobs every day

{
  "companies": ["https://www.linkedin.com/company/github/"],
  "stateNamespace": "auto",
  "closureConfirmationScans": 2
}

Save this input as an Apify Task and schedule it daily. The first run records the current openings as new; every later run returns only what changed. No date filters to maintain and no duplicate handling on your side.

Get new-job and closed-job alerts in Slack, a CRM, or any webhook consumer

Add webhookUrl (HTTPS) and optionally webhookSecret to the input. Non-empty runs deliver signed event batches with retries and a durable outbox, so a temporarily down endpoint does not lose events. Map eventType on your side: new for openings, closed for confirmed removals.

Keep a full current snapshot in your warehouse

Set emitCurrentSnapshot: true to receive every open job on every run, including unchanged ones, while still getting lifecycle event labels. Costs more rows than changes-only mode; use it when a BI table needs the complete inventory.

Why a change feed instead of re-scraping every day

Scheduling a plain scraper daily re-downloads the same inventory every run and leaves the hard part to you: diffing runs, deduplicating jobs, and deciding whether a missing job is really gone or the scan just came back incomplete. This Actor keeps that state per watchlist: it emits only dated lifecycle events, confirms closures across multiple complete scans before reporting them, and never turns an incomplete scan into a false closed. You pay per completed company scan, not per re-downloaded row.

Pricing and buyer cost model

This Actor uses pay-per-event pricing. Company-scan prices (effective 8 September 2026) are:

• Free: $0.012 per completed company scan
• Bronze: $0.0108 per completed company scan
• Silver: $0.0096 per completed company scan
• Gold and above: $0.0084 per completed company scan
• Dataset row: $0.00001
• Actor start: $0.00005

Incomplete company scans are not charged as completed company scans. Platform usage for this Actor is included in its event pricing. Optional verification is billed separately. The Store pricing shown at run time is always authoritative.

Approximate monthly monitoring costs at the Free-tier company-scan price, using a 30-day month:

Schedule	Completed company scans	Company-scan cost
10 companies once daily	300	about $3.60/month
100 companies once daily	3,000	about $36/month
100 companies every 6 hours	12,000	about $144/month

These estimates assume complete scans, changes-only mode, and verification turned off. Actor starts and emitted dataset rows add small variable charges; optional apply-link verification is billed separately. Bronze, Silver, Gold, Platinum, and Diamond company-scan rates are lower than the Free-tier rate used above; a monitored company costs a fraction of a cent per scan, well below plain per-result LinkedIn job scrapers.

Seven-day buyer pilot

A narrow pilot makes the value and limitations measurable before a larger rollout:

{
  "companies": [
    "https://www.linkedin.com/company/github/"
  ],
  "stateNamespace": "auto",
  "closureConfirmationScans": 2,
  "emitInitialSnapshot": true,
  "emitCurrentSnapshot": false,
  "strictClosureQualityGate": true,
  "verifyApplyLinks": false
}

Add 24 other agreed canonical company URLs, save the input as one Task, and run that same Task once daily for seven days. If all 25 company scans complete each day, the company-scan component is 175 scans, or about $2.10 at the Free-tier rate. Actor starts and emitted dataset rows add small variable charges.

Judge the pilot on observed evidence:

• scanSuccessRate, closureSafeRate, warnings, and failures in each OUTPUT record
• whether a manual sample review finds the emitted changes useful and correctly classified
• whether the dataset, API, or webhook fits the intended ATS, RPO, CRM, or analytics workflow
• measured operator time before and during the pilot
• total run charges, including any optional verification

Scale only when the measured workflow value is greater than the measured cost. The Actor does not promise time savings, placements, sales opportunities, or a particular return on investment.

To control cost, keep changes-only mode on, choose the lowest useful schedule frequency, leave verification off until its fields are needed, and use the verification job and charge limits when enabling it. The Store pricing shown at run time is authoritative.

Reliability rules

The crawler:

• reads LinkedIn's reported inventory total as a coverage target
• forces Worldwide scope instead of inheriting the proxy location
• preserves cookies and session identity within an attempt
• advances pagination by the number of jobs actually returned
• retries transient 429, timeout, repeated-page, and no-progress responses
• rotates independent retry strategies and network sessions
• accepts retry consensus only when independent inventories exactly satisfy the reported total
• treats unverified empty HTML as incomplete
• requires explicit no-results evidence before accepting zero jobs
• rejects company-identity mismatches before state or billing
• charges completed company scans only after output, durable outbox, and watchlist state are preserved

The design favors missed or delayed closures over false closures.

FAQ for ATS, RPO, and recruitment intelligence buyers

How do I monitor a company's LinkedIn job postings for changes?

Add the company's public LinkedIn URL to companies, save the input as an Apify Task, and schedule it daily. The first run records the current openings; every later run returns only what changed: new, changed, reopened, and safely confirmed closed events, with an optional webhook push.

Can I scrape LinkedIn company jobs without a login?

Yes. The Actor reads only public LinkedIn guest job pages and never asks for a LinkedIn account, session cookie, or password. It also excludes applicant and recruiter personal data from the output by design.

Is this a LinkedIn jobs scraper or a job-change monitor?

It supports both workflows. The first scheduled run can emit the current openings. Later runs return only changes by default. Set emitCurrentSnapshot: true when a complete current snapshot is required on every run.

Does it integrate directly with an ATS, CRM, or BI tool?

The Actor exposes its records through the Apify dataset and API and can send non-empty event batches to an HTTPS webhook. A buyer still needs to map those fields into the destination system. No native ATS or CRM write is claimed.

Can an RPO keep client watchlists separate?

Yes. Use one saved Task per client or market and leave stateNamespace as auto. API callers should assign one stable, unique namespace to each independent watchlist.

Does closed mean that a role was filled?

No. It means the posting was absent from the configured number of complete scans. It does not prove whether the employer filled, cancelled, paused, or replaced the role.

Why can a run succeed with warnings?

A partial run may still contain safe additions or changes for usable companies. Incomplete scans do not advance closure state and are not charged as completed company scans. Enable the strict closure-quality gate when the downstream workflow must reject coverage below 95%.

Is complete LinkedIn coverage guaranteed?

No. Public pages can change, throttle, block, or return partial inventory. The Actor reports coverage and applies conservative closure rules so the buyer can make a workflow decision from explicit run evidence.

Does it need a LinkedIn account or collect candidate profiles?

No LinkedIn login or user cookies are required. The output contract excludes applicant and recruiter profiles, emails, phone numbers, resumes, and raw job descriptions.

What is charged when a scan is incomplete?

An incomplete company scan is not charged as a completed company scan. Actor-start and emitted dataset-row events, if any, remain separate. Optional official apply-link verification is billed by the verifier Actor.

Support: share a failed run with enough evidence

For a failed, incomplete, or unexpected run:

1. Open the run in Apify Console and inspect its log and OUTPUT record.
2. Review the input, log, and output for client-sensitive values before sharing anything.
3. Open the Actor's Issues page and include the full Console run URL, the expected result, and the observed result.
4. State whether a retry succeeded and which company input was affected. Never paste an Apify token or webhook secret into the issue text.

Apify documents that including a run URL in an Actor issue automatically grants the Actor developer access to that run and its default storages, even when general resource access is restricted. The permission is limited to the reported run and related storages. See Apify's run-sharing documentation.

Privacy and responsible use

The output excludes recruiter names, personal profile links, emails, phone numbers, applicant identities, and raw job descriptions. It processes public company job listings and lifecycle facts.

This is privacy-minimized by design, not a blanket legal guarantee. Users remain responsible for applicable law, contractual terms, and how they use the output.

Examples and API inputs

Copy-ready inputs, output samples, and schemas are available in the public sample repository.

Start from one of the current public Examples:

• Create a GitHub job-change monitor
• Create a GitHub and Slack hiring comparison
• Create a Slack apply-link verification Task

The Actor can also be run from the Apify API, CLI, JavaScript client, Python client, Make, Zapier, n8n, and Apify's MCP server.

Related Actors for hiring-signal pipelines

• ATS Job Change Feed API - Greenhouse + 7 more: the same change-feed contract read directly from public ATS job boards, useful when a company's careers site is the better source.
• LinkedIn Job Apply Link Verifier: the verification engine this Actor calls, usable standalone to check apply links, live status, and ghost-job risk for any LinkedIn job URL.

Local development

npm ci
npm run check
npm audit
npx apify-cli validate-schema