# Live Greenhouse Jobs — Change Tracking & Ghost-Job Detection (`greyridge-signals/greenhouse-jobs-live`) Actor

Pull every open role from a company's live Greenhouse board with a per-run change feed: each job tagged new, changed, open or closed (ghost-job detection) by diffing the prior run. Authoritative current-open truth a resold database can't give. Domain or slug, no keys. Pay per result.

- **URL**: https://apify.com/greyridge-signals/greenhouse-jobs-live.md
- **Developed by:** [Rez Archer](https://apify.com/greyridge-signals) (community)
- **Categories:** Jobs
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.80 / 1,000 job results

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

## Greenhouse Jobs — Live Feed with New / Changed / Closed Change Tracking

Pull **every open role straight from a company's live Greenhouse board** and get back a
**per-run change-feed**: each job is tagged `new`, `changed`, `open`, or `closed` by diffing
this run against the last one. You get the authoritative *current* open set **and** what moved
since you last looked — not a stale snapshot of a third-party database.

```
Input:  ["stripe.com", "greenhouse:gitlab"]
Output: one clean row per role, each tagged:
          new      — opened since your last run
          changed  — still open, but a tracked field moved (title, location, …)
          open     — unchanged since last run
          closed   — was open last run, gone now  →  ghost-job signal
```

### Why this instead of a resold jobs database

Most Greenhouse feeds on the market resell a **cached database** that refreshes on a schedule and
retains postings for months. That cannot authoritatively answer the two questions buyers actually
have:

- **"Is *this* company's role still open right now?"** — This actor reads the company's live
  Greenhouse board at run time, so an open role is open *now*, not "seen within the last N hours".
- **"What changed since I last checked?"** — A cached database has no memory of *your* last run.
  This actor keeps a per-board snapshot between runs and diffs it, so you get `new` / `changed` /
  `closed` deltas for free — including **ghost jobs** (listings that quietly disappeared), the #1
  complaint about job data.

### What you get per role

| Field | Notes |
|-------|-------|
| `status` | `new` / `changed` / `open` / `closed` — the change-feed verdict for this run |
| `changed_fields` | on a `changed` row, exactly which tracked fields moved |
| `first_seen` / `last_seen` | when the role first appeared in your feed and was last confirmed open |
| `days_open` | how long the role has been open (tenure) |
| `is_ghost` | `true` for a `closed` row — the role **vanished** from the board |
| `ghost_candidate` | `true` when a **still-open** role has been live long enough to be a likely *ghost job* — an evergreen listing the employer keeps posted without actively filling (the #1 job-seeker and recruiting-intel complaint). Distinct from `is_ghost` (vanished): this flags roles that stay up and go stale. Threshold via `ghostDays` (default 60). |
| `ghost_signals` | why `ghost_candidate` fired: `open_60d` (we have observed it continuously open ≥ threshold — needs our maintained cross-run state), `posted_60d` (board's own `posted_at` is ≥ threshold old), `stale_update_60d` (board has not edited it in ≥ threshold — corroboration). Empty when not a candidate. |
| `age_days` | days since the board's `posted_at` — the first-run age signal that powers `ghost_candidate` before cross-run history exists |
| `title`, `company`, `location`, `remote`, `department`, `url`, `posted_at`, `updated_at` | normalized core fields |
| `location_parsed` | the free-text `location` normalized into structured geography — `{city, state, state_code, region, country, country_code, countries, workplace, is_remote, multi_location}` — so you can filter on `country_code` / `state_code` / `workplace` without parsing strings yourself |
| `workplace` | `remote` / `hybrid` / `onsite` / `null` — the work mode, classified across the many phrasings boards use (`Remote - US`, `WFH`, `Hybrid — Austin, TX`) |
| `salary` | normalized pay-transparency range — `{min, max, currency, period, annualized:{min,max}, source}` — parsed from the employer's own live posting, or `null` when no range is disclosed |
| `salary_disclosed` | `true` when a range was parsed for this role (quick filter / coverage metric) |
| `employment_type` | `full_time` / `part_time` / `contract` / `temporary` / `internship`, or `null` when undisclosed — resolved from the board's `metadata` type field (authoritative), the title, or the description boilerplate; a tracked field, so a role flipping contract→full-time comes back `changed` |
| `seniority` | `intern` / `junior` / `mid` / `senior` / `staff` / `principal` / `lead` / `manager` / `director` / `vp` / `executive`, mapped from the title (most-senior signal wins), or `null` — filter a feed to just senior+ / exec roles without regexing titles yourself |
| `employment_type_source` / `seniority_source` | where each was resolved (`metadata` / `title` / `description`) so you can trust-weight them |
| `requirements` | structured hiring requirements parsed from the description: `{skills:[{name,category}], skill_names, skills_count, categories, years_experience_min, education_level, source}`. Skills come from a maintained, boundary-anchored taxonomy (languages, frameworks, cloud, data, devops, ML, security, tools); `years_experience_min` is the lowest explicit experience floor in the posting; `education_level` is the minimum degree required. `null` when descriptions are off (never guessed from the title). Filter and rank a feed by tech stack / experience without running your own extractor. |
| `requisition_id`, `internal_job_id`, `offices` | Greenhouse-specific identifiers for dedup / joins |
| `description_text` or `description_html` | optional full description (plain text or raw HTML) |

`salary` is on by default and a **first-class tracked field**: when an employer moves a role's
posted range, that row comes back tagged `changed` with `salary` in `changed_fields` — a live pay
signal a resold snapshot database cannot give you. Because Greenhouse publishes no structured salary
field, the range is read and normalized from each posting at run time (period-annualized to a
comparable yearly figure), so you get a uniform range even though every employer phrases it
differently. It is returned without the heavy description payload unless you also ask for that.

`location_parsed` is on by default and needs no network — Greenhouse exposes location only as one
free-text string (`"San Francisco, CA"`, `"Remote, Canada; Remote, United States"`, `"Remote from
the US"`), so to filter by geography you would otherwise have to parse it yourself. This field
splits it into city / state / country, recognizes US state abbreviations and full names,
international cities, and the many ways a board writes remote/hybrid/onsite. For a role open in
several regions it sets `multi_location: true` and lists every `country_code` in `countries`, so a
`country_code = "US"` filter still matches a globally-open posting.

### Input

| Field | Type | Default | Description |
|-------|------|---------|-------------|
| `companies` | string\[] | — | Domain (`stripe.com`), board slug (`stripe`), or `greenhouse:token`. The board slug is auto-detected from a domain — no lookup needed. Optional when `useRoster` is on. |
| `useRoster` | boolean | `false` | Pull from the maintained, live-verified roster of Greenhouse boards — a broad current feed **without supplying a company list**. Combine with `companies` to run both. |
| `rosterLimit` | integer | `0` (all) | Cap how many roster boards to pull, richest-first (most open roles). Applies only to roster boards. |
| `rosterFilter` | string | — | Keep only roster boards whose company name or token contains this text (case-insensitive). |
| `includeClosed` | boolean | `true` | Emit `closed` / ghost rows (roles present last run, gone now). |
| `includeSalary` | boolean | `true` | Parse + return the normalized `salary` range for each role. |
| `includeDescription` | boolean | `false` | Also return the job description. |
| `descriptionType` | `text` | `html` | `text` | Description format when `includeDescription` is on. |
| `maxItemsPerCompany` | integer | `0` (all) | Cap **live** rows per company. The full board is always fetched so the diff is complete; the cap only trims output. |
| `firstRunNewAsOpen` | boolean | `false` | On a board's first run (no prior snapshot) label everything `open` instead of flooding you with `new`. |
| `ghostDays` | integer | `60` | Age (days) at which a still-open role is flagged `ghost_candidate` — a likely evergreen/unfilled listing. Uses the longest of `days_open`, `posted_at` age, and a stale `updated_at`. `0` = default (60). |

> The change-feed needs state between runs. On the Apify platform that state is kept in a named
> key-value store that persists across runs automatically — just run the actor on a schedule
> against the same companies and each run reports the delta since the previous one.

### No company list? Use the maintained roster

Most Greenhouse feeds make you supply the companies. A resold "all of Greenhouse" database skips
that — but at the cost of stale, cached data. This actor gives you the broad feed **and** the live
truth: turn on `useRoster` and it pulls from a built-in roster of Greenhouse boards that is
**continuously re-verified and pruned** — dead boards (companies that left Greenhouse, renamed their
token, or went private) are dropped and live ones kept. That upkeep is the point: when we first
built the roster, **more than half** of a naive hand-made list of well-known companies was already
pointing at a dead or moved board. Maintaining a live roster of hundreds of board tokens is exactly
the work you don't want to do — so we do it, and you get a current cross-company feed from one call.

```bash
node cli.js --roster-limit=25            # 25 richest boards, no company list
node cli.js --roster-filter=fintech      # roster boards matching "fintech"
node cli.js stripe.com --roster          # your own company PLUS the roster
```

On the Apify platform set `useRoster: true` (optionally with `rosterLimit` / `rosterFilter`). The
roster is refreshed by `scripts/refresh_roster.mjs`, which live-probes every board, writes the
verified set, and flags a structural break so the feed never silently decays.

### Reliability SLA — not a promise, a signal

Greenhouse's public board JSON can silently drift (a renamed field, a moved endpoint). A plain
"it ran" check misses that — the run succeeds and the data is quietly junk. Every run stamps a
**freshness/schema verdict** (`OK` / `EMPTY` / `SCHEMA_DRIFT` / `DOWN`) onto its run metadata by
probing a large known-good board and grading reachability, population, and key-field presence
(`id` / `title` / `url`). The same check runs standalone (`npm run freshness`) so breakage is
caught and patched upstream — usually before it reaches your runs.

### Use without an account (CLI)

The exact same verified core runs as a zero-dependency CLI, with the change-feed snapshot kept in
a local file:

```bash
node cli.js stripe.com --max=25
node cli.js greenhouse:gitlab --html --pretty
node cli.js stripe gitlab --state=/tmp/feed.json   # run twice to see new → open deltas
```

### Pricing

Pay per result — **$0.80 per 1,000 rows** (see `.actor/PRICING.md`). Each emitted row — live or
ghost — is one billable result, and the run stops the instant your charge limit is reached.

### Guarantees

- **Keyless & free upstream** — reads only Greenhouse's public board API. No API keys, no proxies.
- **Bounded** — per-request timeout + response-size ceiling; a stalled or oversized board can never
  hang a run or exhaust memory.
- **Safe** — board tokens are validated and redirects are re-checked on every hop (see `SECURITY.md`).

# Actor input Schema

## `companies` (type: `array`):

One entry per company. Each may be:
• a domain — stripe.com (the Greenhouse board slug is auto-detected)
• a bare board slug — stripe
• an explicit greenhouse:token — greenhouse:gitlab

The full live board is pulled for each company so the change-feed can diff the complete current set. Leave this empty and turn on "Use maintained roster" to pull a broad live feed without listing companies yourself.

## `useRoster` (type: `boolean`):

Pull from the built-in, live-verified roster of Greenhouse boards — so you get a broad current feed WITHOUT supplying a company list. The roster is continuously re-verified and pruned (dead boards removed, live ones kept), which is the capability a resold 'all of Greenhouse' database charges for. Combine with your own Companies to run both. Off by default.

## `rosterLimit` (type: `integer`):

When Use maintained roster is on, cap how many boards to pull, richest-first (boards with the most open roles). 0 = all boards in the roster. Only applies to roster boards, not your own Companies.

## `rosterFilter` (type: `string`):

When Use maintained roster is on, keep only roster boards whose company name or token contains this text (case-insensitive). Leave blank for the whole roster.

## `includeClosed` (type: `boolean`):

Also emit roles that were present on the previous run but are gone now (status=closed). This is the ghost-job signal — on by default; it is the feature a resold-database feed cannot provide.

## `includeSalary` (type: `boolean`):

Parse each role's pay-transparency range from the live board and return a normalized salary object {min, max, currency, period, annualized}. On by default. Greenhouse exposes no structured salary field, so this is a maintained call-time parse of the employer's own disclosed range — not a resold estimate.

## `includeDescription` (type: `boolean`):

Also return the job description (larger output; off by default). Format is controlled by Description format.

## `descriptionType` (type: `string`):

Plain text (cleaned) or raw HTML. Only applies when Include full description is on.

## `maxItemsPerCompany` (type: `integer`):

Cap the number of LIVE rows (new/changed/open) returned per company. 0 = no cap. Closed/ghost rows are additional and not capped by this.

## `firstRunNewAsOpen` (type: `boolean`):

On the very first run of a board (no prior snapshot), label every role 'open' instead of 'new' so you do not get a one-time flood of 'new'. Subsequent runs always diff normally.

## `ghostDays` (type: `integer`):

Age in days at which a still-OPEN role is flagged a ghost-job candidate (ghost_candidate=true) — an evergreen listing the employer keeps posted without actively filling. Uses the longest of: how long we have continuously observed the role open (days_open), the board's own posted_at age, corroborated by a stale updated_at. 0 = use the default (60). This is the stale-but-open ghost signal, distinct from is_ghost (a role that vanished).

## Actor input object example

```json
{
  "companies": [
    "stripe.com",
    "greenhouse:gitlab"
  ],
  "useRoster": false,
  "rosterLimit": 0,
  "includeClosed": true,
  "includeSalary": true,
  "includeDescription": false,
  "descriptionType": "text",
  "maxItemsPerCompany": 0,
  "firstRunNewAsOpen": false,
  "ghostDays": 60
}
```

# Actor output Schema

## `results` (type: `string`):

The normalized rows this run produced, in the default dataset.

## `overview` (type: `string`):

Open the run results in the Apify Console.

# 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 = {
    "companies": [
        "stripe.com",
        "greenhouse:gitlab"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("greyridge-signals/greenhouse-jobs-live").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 = { "companies": [
        "stripe.com",
        "greenhouse:gitlab",
    ] }

# Run the Actor and wait for it to finish
run = client.actor("greyridge-signals/greenhouse-jobs-live").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 '{
  "companies": [
    "stripe.com",
    "greenhouse:gitlab"
  ]
}' |
apify call greyridge-signals/greenhouse-jobs-live --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,greyridge-signals/greenhouse-jobs-live"
        }
    }
}
```

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/LczN31v4PK2hFD2fl/builds/qH5kNJklQ4AvryDvd/openapi.json