Company Hiring Signals — Greenhouse & Lever

For recruiting and sales teams watching hiring activity at selected companies.

Track public Greenhouse and Lever job boards. Filter roles and locations, deduplicate postings, and compare new, changed and missing jobs across complete checks.

What it does

Reads public Greenhouse job boards and paginated Lever postings. Records job ID, title, location and URL. Complete boards support added, updated and missing-job comparisons.

Quick start

Paste the example below into Input, run the Actor, then open REPORT for a readable HTML report or SUMMARY for run coverage and history status. Dataset output has one row per supplied companies entry, with nested records and changes. Export JSON for full nested detail; CSV is best for summary fields.

{
  "companies": [
    {
      "id": "greenhouse",
      "provider": "greenhouse",
      "board": "greenhouse",
      "name": "Greenhouse"
    }
  ]
}

Inputs

Each companies object requires provider (greenhouse or lever) and board token. Optional id, name and region (us or eu; Lever only). roleKeywords and locationKeywords are optional case-insensitive literal OR filters; both groups must match. maxPages defaults to 3 (1–10); maxJobs to 500 (1–1000).

Supply 1–10 source objects. URLs must be public HTTP(S) on standard ports without credentials. timeoutSecs is 2–30 per request (default 15), maxRedirects 0–5 (default 3), and delayMillis 100–5000 between requests (default 250). Redirect destinations and DNS answers are validated; private and reserved network addresses are blocked. Response bodies are capped at 4 MB.

Results and interpretation

status is observed, baseline, unchanged, changed or unknown. sourceComplete distinguishes complete coverage from partial/failed evidence. records contains observations; facts provides summary metrics; issues and the report explain limitations. changeCounts gives full counts; changes includes at most 100 detailed changes per input, with changesTruncated when capped. The HTML report previews 20 changes and 10 records. SUMMARY.complete means all inputs were attempted, while coverageComplete means all sources were reliable.

Repeat runs and history

monitor defaults to true. Run the same watchlist with the same monitorKey to compare against the last reliable observation. The first run establishes a baseline and reports no invented changes. Change the key to start a new baseline. Changing source definitions or filter settings creates a separate scope. Keep stable IDs and source order.

History is stored in an Actor-owned named key-value store in your account, under limited permissions. Complete funded runs persist immutable snapshots; failed sources retain their prior records. Overlapping runs use start-ordered snapshots so a late older run cannot roll history back. Each run pins its baseline across restarts. Prefer schedules that do not overlap to avoid duplicate alerts from concurrent comparisons.

The most recent 20 snapshots are retained, with at most 2000 historical record IDs per source for rolling feeds and a 7 MB snapshot cap. Older retained IDs can appear new after eviction. SUMMARY.history says whether history was saved; split large watchlists if it reports a size limit. Partial budget runs do not advance history. monitor: false performs an observation without history.

Pricing

$30 per 1000 completed source checks ($0.03 per board-checked event), plus Apify platform usage and the listed Actor-start event. A completed check can return unknown or problem evidence; it still incurs the custom check event. Transport/security exceptions with an error have no custom check charge. The Actor-start event is $0.00005 per GB of allocated memory, minimum one event. Use the run spending limit to bound charges; the report identifies partial budget runs. The Apify pricing tab is authoritative.

Coverage limits

Public postings only, no applicant data or applications. Greenhouse total must match the returned array. Lever needs a short final page to prove exhaustion. Reaching a page or job cap suppresses comparison. Missing means absent from the configured board, not proof a hire occurred.

HTTP requests only. No CAPTCHA bypass, credentials, proxy subscription, external AI key, notifications or outbound messages are included. Use Apify schedules and your own integrations to consume changes. Reports show source evidence, not guaranteed business outcomes.

Troubleshooting and support

For unknown results, inspect issues and the source response before changing your workflow. Increase pagination limits only when needed. Retry rate limits later with a longer delay. Use a new monitor key when intentionally redefining a watchlist. Open an issue from this Actor's Issues tab with the run ID, expected behavior and a public reproducible input; omit tokens and personal data.

Local development

Node.js 22+. Run npm ci, npm test, npm run check, then npm start with an Apify INPUT record. Tests cover source fixtures, incomplete coverage, history, HTTP safety, report escaping and charging boundaries. Cloud release evidence is recorded separately in RELEASE.md in the local project.