LinkedIn Company Jobs Monitor

Track hiring changes for up to 20 companies through LinkedIn's public guest job search. Every scan reports new and updated postings from the newest-first window, for companies of any size. A removal is emitted only after the same job is absent from two complete consecutive scans, which protects saved history when source access is incomplete.

The current Store configuration charges $0.005 at run start, $0.003 per posting checked, and $0.015 per non-baseline change. Apify platform usage is billed separately to the user. No LinkedIn account or cookies are required.

Built for recurring company research

Use the monitor for account research that needs fresh hiring signals or for competitor intelligence that must keep its history through an interrupted source scan. The first run creates a baseline. Later runs emit NEW_POSTING, UPDATED_POSTING, and — from complete scans — REMOVED_POSTING rows.

A numeric LinkedIn company ID gives the cleanest scope. Company-name search remains available as a filtered fallback when the ID is unavailable.

Coverage: how large employers are enumerated

LinkedIn's public guest search returns only about 30 to 50 results for a single company query, regardless of how large the company is. To see past that ceiling, the monitor runs the company query once per location in facetLocations and unions the de-duplicated postings. On a large employer this recovers many times more postings than a single query. Each scan reads newest-first (sortBy=DD), paces its requests, and retries a repeated page once before treating it as the end, because a repeat on the guest surface is usually a transient throttle rather than the true end of results.

Set facetLocations to the markets a company hires in for the best coverage-to-cost ratio, keep the broad default list, or set it to an empty list to run a single query for a small employer that fits under the ceiling.

The two guarantees

The monitor makes two promises with different evidence requirements, and it keeps them separate so each is honest:

• New and updated postings need only a recent view of the newest jobs. They are reported from the observed window on every scan, complete or not. Adding an observed posting to saved state can never fabricate a removal, so this is safe even when a scan cannot be finished.
• Confirmed removals need full enumeration, so that an absent job is known to be gone rather than merely beyond the scanned window. A removal is therefore restricted to complete scans (the base query and every location facet each reached an empty final page) and still requires two consecutive complete absences. Very large employers may not reach a complete scan on the public guest surface; for those, the monitor reports new and updated postings and holds removals rather than guessing.

Sample change

{
  "changeType": "NEW_POSTING",
  "companyLabel": "Acme",
  "companyId": "1035",
  "companyName": null,
  "jobId": "4440655897",
  "title": "Applied AI Engineer",
  "location": "Paris, France",
  "salary": null,
  "postedAt": "2026-07-21",
  "postedText": "1 day ago",
  "url": "https://www.linkedin.com/jobs/view/4440655897/",
  "scanComplete": false,
  "scanTruncated": true,
  "scanDiagnostic": "FACETED_INCOMPLETE",
  "checkedAt": "2026-07-22T09:15:00.000Z"
}

scanComplete tells you whether the scan that produced a row was exhaustive. Removed rows keep the fields from the last complete snapshot. Relative posting text is excluded from change identity, so a label such as "2 days ago" becoming "3 days ago" does not create an update.

Input

companies accepts one to 20 entries. Add companyId when possible, or use companyName as the fallback. The optional label is copied to each output row.

{
  "companies": [
    { "companyId": "1035", "label": "Microsoft" },
    { "companyName": "Acme Corp", "label": "Acme" }
  ],
  "monitorId": "target-accounts-eu",
  "maxItemsPerCompany": 100,
  "facetLocations": ["United States", "United Kingdom", "Germany", "India"],
  "sortBy": "DD",
  "pacingMs": 1500,
  "fullReport": true,
  "webhookUrl": "https://example.com/linkedin-job-changes"
}

Reuse the same monitorId on scheduled runs to compare with the same saved history. maxItemsPerCompany defaults to 50, is capped at 500, and bounds the union across all facets — reaching it marks the scan incomplete, so choose a value above a company's expected public posting count when you need complete scans and confirmed removals. facetLocations controls coverage and cost: more locations means more requests and more postings checked. pacingMs spaces requests to reduce throttling. fullReport adds diagnostic rows for quiet or incomplete company scans. webhookUrl receives one HTTPS POST when a scan finds changes.

State and removal safety

Only a genuinely empty final page completes a facet, and a scan is complete only when the base query and every facet complete without truncation. A block, fetch failure, malformed response, duplicate page, per-company cap, per-facet page guard, or billing limit leaves the scan incomplete. Incomplete scans still report new and updated postings, but they never drop a stored job and never increment a removal count, so no sequence of incomplete scans can confirm a removal or erase history.

The two-scan removal rule applies to complete scans. If a job is absent from one complete scan, the monitor records that absence internally. A second complete absence emits REMOVED_POSTING. A job that reappears clears its pending absence.

Review OUTPUT_SUMMARY before acting on a quiet run. It records, per company, how many postings were observed, whether the scan was complete, and the billing outcome.

Where the history is kept

On its first run each monitorId creates a named key-value store, linkedin-company-jobs-<monitorId>, in your account and reuses it on every later run. Keep the monitorId stable to keep the history; change it to start a fresh baseline.

This Actor runs with limited permissions, so it can only use a store it created itself. If a store of that name already exists in your account from something else, the run stops immediately and tells you to pick a different monitorId or remove that store. It never falls back to a new store, because a silent fallback would erase the history and re-report every posting as a baseline.

Billing

The Actor event charge is $0.005 + ($0.003 × postings checked) + ($0.015 × non-baseline changes).

Postings checked and non-baseline changes are billed on every scan that observes postings, complete or incomplete, because each such scan delivers new-and-updated detection. A scan that observes nothing — blocked, failed, or empty and incomplete — charges only the start event. Baseline postings on a first run are checked but not counted as changes.

A scan that checks 50 postings and finds two changes creates $0.185 in Actor event charges, including the start event. Larger coverage across more location facets checks more postings and costs proportionally more; maxItemsPerCompany and facetLocations are the controls. Apify platform usage, including compute and data transfer, is charged separately under the user's Apify plan.

If the platform cannot accept all required events for a company, the Actor emits BUDGET_EXHAUSTED and preserves that company's prior state — it never bills for a partial result it cannot deliver.

Output and delivery

The dataset view puts the change type and company label first, followed by the job fields and check time. Results can be exported as JSON, CSV, Excel, or XML. The optional webhook carries a scan's changes to an HTTPS endpoint.

Coverage is limited to postings returned by LinkedIn's public guest search. Local tests verify state transitions, faceted enumeration, and failure handling against structural fixtures. A bounded cloud run is required before this version becomes the public default.

Support

For a reproducible issue report, include the Apify run ID, monitorId, affected company input, and OUTPUT_SUMMARY. Remove webhook secrets and downstream customer data before sharing it.