Lever & Greenhouse Job Change Monitor API

Monitor a watchlist of public Lever and Greenhouse career boards for your job board or dashboard. Get added jobs, exact before/after field changes, confirmed removals, reopened posting IDs, and a receipt even when nothing changed.

Public beta · $0.01 per successful board check, covering up to 1,000 jobs per board. Baselines, unchanged checks, and valid empty boards count. Failed, incomplete, malformed, and over-cap checks do not trigger the success charge. Platform usage is included in the Store offer; there are no additional start, job, or dataset-item fees. The pricing shown by Apify controls.

Start a watchlist

1. Choose Save as a new task so later runs can reuse this watchlist's history.
2. Paste the starter input below, or enter your own board tokens in the input form.
3. Run the Task once to establish a baseline. Open Board receipts and check that the board's status is baseline.
4. Run the same Task again. An unchanged board has status ok and zero change events. Export the dataset or retrieve it through Apify's API.

{
  "boards": [
    {
      "provider": "lever",
      "token": "leverdemo",
      "label": "Lever demo (fictional jobs)"
    }
  ],
  "removalConfirmations": 2,
  "emitInitialJobs": false,
  "maxJobsPerBoard": 1000,
  "timeoutSeconds": 15,
  "maxRetries": 2
}

The starter uses Lever's fictional demonstration board. Replace it with a supported public board when creating your watchlist. To include the existing jobs in your first result, set emitInitialJobs to true before the first successful run. They will be labeled baseline, not newly added jobs. Enabling this after a baseline exists does not replay those initial jobs.

Zero events on your first run is expected. With the default input, a successful first check creates history without claiming that existing jobs are new. The receipt shows whether that check succeeded. A successful Apify run can include failed board checks, so inspect each receipt and the run summary.

For recurring monitoring, choose a schedule and spending limit for that same Task. A daily schedule is a useful starting point; leave enough time for a run to finish before the next starts. Apify Tasks and schedules provide these controls.

Choose boards and limits

• Supply 1–100 boards. For jobs.lever.co/example, use provider lever and token example. EU Lever boards also need "region": "eu".
• For a Greenhouse board such as job-boards.greenhouse.io/example, use provider greenhouse and token example. Greenhouse supports region global only.
• A token is the public board slug, not a company domain, full URL, password, or API key. This Actor does not discover board tokens from company names or domains.
• label is optional display text. Changing it does not reset history.
• removalConfirmations accepts 1–5 successful observations; the default is 2.
• maxJobsPerBoard accepts 1–1,000. A board above that limit fails without advancing its history. Results are never silently truncated.
• timeoutSeconds is the timeout for each source request, from 1–60 seconds. maxRetries permits 0–5 retries. Set the overall Apify run timeout for your watchlist size and source response times.

Missing source fields remain null or an empty department list. Greenhouse's list endpoint does not provide structured salary or workplace data; the Actor does not infer them from descriptions. Full job descriptions, applicant information, and contact enrichment are excluded.

Understand the changes

Event	Meaning
baseline	Optional first observation of an already present posting
added	A new posting ID appeared after the baseline
changed	Normalized fields changed; changes contains exact before and after values
removed	An ID was absent from the board in the required number of successful observations
reopened	A previously confirmed removed ID appeared again

With the default setting, one missing observation does not produce a removal. A failed or incomplete check never advances history or counts toward removal. A new ID with a similar title is still a new ID. Removal means the posting was no longer observed; it does not mean someone was hired or the position was filled. First-seen and event timestamps describe this monitor's observations, not the employer's publication time. Changes that occur and reverse between checks can be missed.

Read and integrate the output

Each completed board attempt produces one dataset item: a check receipt. Job changes are nested in its events array. The Board receipts view gives an overview; download the JSON dataset for the complete receipt and event fields.

Receipt field	Use
receiptId, runId, boardId	Identify the check, run, and source board
status	baseline, ok, or error for ordinary completed checks
observedAt, sourceUrl	Observation time and public source attribution
summary	Job counts, successful-scan count, and event counts
events	Added, changed, removed, reopened, or optional baseline records
error	Source failure details, when present
billing	Charge status and acknowledged event count

Each event includes eventId, type, boardId, provider, company, jobId, observedAt, sourceUrl, job, and changes. Normalized job fields are title, location, departments, team, commitment, workplace type, structured salary when provided, and job URL.

The run's default key-value store contains OUTPUT, with the run summary, stoppedReason, receipts, any recovered receipts, and the named state-store location. A board skipped because the spending limit was reached has no new receipt. Check stoppedReason before treating the whole watchlist as complete.

For n8n or another integration: run the saved Apify Task, retrieve its completed dataset, split each receipt's events array, and upsert events using eventId. Treat error receipts and unfinished runs separately from successful results with no changes. Delivery is at least once: an interruption can replay a receipt. Deduplicate by receiptId and retain event deduplication by eventId in your application.

History and interruptions

History is keyed to the Apify account, Actor, and saved Task. A different Task begins a new baseline. Direct API runs outside a Task use the optional stateKey input instead; reuse it to continue history or change it to start fresh. Changing stateKey inside a saved Task does not reset that Task's history. Removing a board from input pauses observations while retaining its history.

The named state store retains history and receipts until the account owner deletes it. Deleting it resets comparisons. Removed-job records are retained to recognize reopened IDs, so storage grows with long-running watchlists and job turnover.

Only one run can write a watchlist at a time. An overlapping run fails before checking or charging boards; retry after the active run finishes. Following an interrupted process, the lease can remain busy for up to 120 seconds after its last renewal. A restart of the same run may wait for that lease to expire, within its remaining run timeout.

The Actor saves a durable receipt before requesting a charge. If the charge outcome is uncertain, it records billing.status: "unknown" and stops. Inspect that receipt and Apify's billing record before proceeding; an unknown count is not zero. Recovery does not automatically retry an ambiguous charge. A newly started run is a separate observation and can be charged again. Durable receipts in the named state store can help recover results when a run ends before dataset delivery.

Pricing and beta scope

The single pricing event is successful-board-check at $0.01. A quiet successful check is charged because the board was read and compared. At this price, 100 boards checked daily for 30 days cost $30 if every check succeeds. A per-run spending limit is not a monthly limit. If the run cannot afford another success event, it stops before attempting that board.

This beta has passed hosted baseline, repeated-history, cap-preservation, and missing-board checks. Six publisher-operated runs also reconciled successful-check event counts with saved receipts and verified spending limits. These were technical tests, not customer purchases. Independent customer-account behavior and forced-interruption recovery have not yet been tested live. Start with a small watchlist; large-scale costs and performance have not been established. The storage lease cannot guarantee protection from an already-issued write that stalls past lease expiry, and the Actor does not promise exactly-once delivery or billing across every failure.

Public sources

The Actor uses documented unauthenticated GET endpoints from the Lever Postings API and Greenhouse Job Board API. It is not affiliated with either provider or monitored employers. Choose boards you are permitted to monitor and follow applicable source reuse conditions.