# Lever & Greenhouse Job Change Monitor API (`hiringchangefeed/hiring-change-feed`) Actor

Monitor a Lever and Greenhouse watchlist for your job board or dashboard. Get exact before/after field changes, confirmed removals, reopened IDs, and a receipt even when nothing changed. Save one Task to keep history.

- **URL**: https://apify.com/hiringchangefeed/hiring-change-feed.md
- **Developed by:** [Daniel](https://apify.com/hiringchangefeed) (community)
- **Stats:** 3 total users, 2 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$10.00 / 1,000 successful board checks

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

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

```json
{
  "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](https://docs.apify.com/actors/running/tasks) and [schedules](https://docs.apify.com/actors/running/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](https://github.com/lever/postings-api) and [Greenhouse Job Board API](https://docs.greenhouse.io/job-board.html). It is not affiliated with either provider or monitored employers. Choose boards you are permitted to monitor and follow applicable source reuse conditions.

# Actor input Schema

## `boards` (type: `array`):

1–100 objects: provider (lever or greenhouse), token (career-board slug), optional region (global or Lever eu) and label. Example below is Lever's demo board, not a real employer.

## `stateKey` (type: `string`):

Reuse this key across API runs. Saved Tasks use their own task ID instead. Changing this history key begins separate history for direct API runs. 1–64 letters, numbers, underscores or hyphens. This is a label, not a secret/API credential.

## `emitInitialJobs` (type: `boolean`):

Emit baseline events for first-observed jobs. They are not newly published job claims.

## `removalConfirmations` (type: `integer`):

Use two or more to reduce false removals. Failed checks never count. Removed means no longer observed, not filled.

## `maxJobsPerBoard` (type: `integer`):

Boards exceeding this cap fail without advancing history or charging a success event. Results are never silently truncated.

## `timeoutSeconds` (type: `integer`):

Applies to response headers and body.

## `maxRetries` (type: `integer`):

Bounded retries for transient failures.

## Actor input object example

```json
{
  "boards": [
    {
      "provider": "lever",
      "token": "leverdemo",
      "label": "Lever demo (synthetic)"
    }
  ],
  "stateKey": "default",
  "emitInitialJobs": false,
  "removalConfirmations": 2,
  "maxJobsPerBoard": 1000,
  "timeoutSeconds": 15,
  "maxRetries": 2
}
```

# Actor output Schema

## `receipts` (type: `string`):

One receipt per processed board observation. Baselines and failed checks remain visible. Events contain added, changed, confirmed removed, reopened, or optional baseline records. Deduplicate exports by receiptId and eventId.

## `runSummary` (type: `string`):

The OUTPUT record includes run timing, any stopping reason, receipts, recovered receipts, and the named state-store reference. An interrupted run may retain its initial running record; durable receipts are also saved in the named state store.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "boards": [
        {
            "provider": "lever",
            "token": "leverdemo",
            "label": "Lever demo (synthetic)"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("hiringchangefeed/hiring-change-feed").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "boards": [{
            "provider": "lever",
            "token": "leverdemo",
            "label": "Lever demo (synthetic)",
        }] }

# Run the Actor and wait for it to finish
run = client.actor("hiringchangefeed/hiring-change-feed").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "boards": [
    {
      "provider": "lever",
      "token": "leverdemo",
      "label": "Lever demo (synthetic)"
    }
  ]
}' |
apify call hiringchangefeed/hiring-change-feed --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,hiringchangefeed/hiring-change-feed"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/osgDZ2Vrqpav5t7v0/builds/5h6aAC2umwmhZC69Z/openapi.json