LinkedIn Company Jobs Monitor & Change Feed

LinkedIn Company Jobs Monitor

Turn public LinkedIn company job pages into a stateful jobs change feed for hiring intelligence, recruiting alerts, 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.

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.

Buyer workflows

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

Each dataset row includes the company, job ID, title, location, job URL, posting date, detection timestamps, changed fields, and lifecycle event type. This shortened row is from a verified live Slack run on 2026-07-28:

{
  "eventType": "new",
  "companyId": "1612748",
  "companyName": "Slack",
  "companyUrl": "https://www.linkedin.com/company/tiny-spec-inc",
  "jobId": "4420986388",
  "jobTitle": "Staff ML Engineer, Fine Tuning - Slack",
  "location": "San Francisco, CA",
  "jobUrl": "https://www.linkedin.com/jobs/view/4420986388",
  "detectedAt": "2026-07-28T14:34:00.682Z",
  "changedFields": [],
  "source": "linkedin_public_jobs",
  "verificationStatus": "completed",
  "officialApplyUrl": "https://salesforce.wd12.myworkdayjobs.com/Slack/job/Washington---Seattle/Staff-ML-Engineer--LLM-Fine-Tuning---Slack_JR344115",
  "verificationConfidence": 0.97,
  "ghostJobRisk": "low"
}

tiny-spec-inc is Slack's legacy LinkedIn company slug in this captured record.

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
• 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.

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.

Pricing and buyer cost model

This Actor uses pay-per-event pricing. Current company-scan prices are:

• Free: $0.005 per completed company scan
• Bronze: $0.0045 per completed company scan
• Silver: $0.004 per completed company scan
• Gold and above: $0.0035 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.

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 $1.50/month
100 companies once daily	3,000	about $15/month
100 companies every 6 hours	12,000	about $60/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.

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 $0.875 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

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.

Local development

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