Greenhouse Job Change Tracker

See what changed in a Greenhouse job posting: description text, title, location, department, office or application URL. Track known employers over repeated runs and export structured evidence for a recruiting workflow or job board.

Description changes include salary, requirements and remote-work wording when those details appear in the source. This Actor reports text differences; it does not classify compensation or infer company hiring intent.

Try it

Run the default synthetic demo first:

{ "mode": "demo" }

The demo emits six example job rows, including a salary/policy edit, a new posting and a confirmed absence. Every row is marked isDemo: true. It makes no source requests, changes no watch state and incurs no Actor event charge.

For live tracking:

{
  "mode": "live",
  "boards": ["airbnb", "stripe"],
  "watchName": "hiring-watch",
  "outputMode": "changes"
}

Use the employer's Greenhouse board token, typically the name in boards.greenhouse.io/TOKEN or job-boards.greenhouse.io/TOKEN. Custom careers sites may not expose the token. This Actor does not discover it. Supply 1–10 tokens, not URLs.

Save an Apify task and schedule repeated runs yourself, for example daily. Keep the same watch name and board list. A different list requires a new watch name and starts a new baseline. Schedule at least an hour apart; avoid overlapping runs. The Actor runs once per invocation and does not schedule itself.

Price

$0.05 per successfully checked board ($50 per 1,000), with no start or per-job event fee. One complete empty or unchanged board still counts as a successful check. Ten boards checked daily for 30 days cost $15 in Actor event charges. Failed boards and the synthetic demo have no Actor event charge. Export, storage, integration or account costs may apply under your Apify plan. A successful source result is delivered before its event charge; failed checkpoint persistence can still follow a charge, as explained below.

Set a maximum charge for each live run: $0.05 for one board, $0.50 for ten. Once the remaining event budget cannot cover another board, remaining boards are skipped and reported. Billing is in whole board checks, not job rows. Local execution simulates billing without charging money.

Read the output

The default dataset contains two types of row. Filter recordType: job for job events; always inspect recordType: board for coverage and errors.

Job status	Meaning
baseline	Present on the first successful observation; not claimed newly posted.
added	A new job-post ID since the prior complete observation.
changed	One or more tracked fields changed.
unchanged	Included only with outputMode: all.
missing_pending	Absent on a complete observation; removal not yet confirmed.
removed	Absent on a second complete observation at least one hour after the first absence.
reappeared	A previously absent posting returned while retained in watch history.

Rows include jobId, board, title, location, url, normalized description, observedAt, sourceUpdatedAt, changedFields, changes, eventId and last-seen information. Description evidence contains removed/added text plus hashes; excerpts over 4,000 characters or expensive diffs are explicitly marked truncated. Use JSON for nested evidence; CSV is convenient for flat fields. Markup, whitespace and source-update timestamps alone do not create changes. Link-target-only edits inside descriptions are not tracked.

OUTPUT in the run key-value store records successful, failed and skipped boards and whether checkpoints were saved. ERROR provides fatal error details. METRICS contains local process observations, not a platform invoice. A run with one healthy board and one source failure completes with status: partial; inspect the summary even when Apify marks the run succeeded.

State and reliability

Each actor/watch combination uses an account-local named key-value store and request queue; OUTPUT gives their identifiers. Previous job snapshots persist between runs. Source failures, malformed responses, duplicate IDs or a mismatch with meta.total cannot overwrite the prior snapshot or trigger removals. “Removed” means repeatedly absent from this API, not proof the employer closed or filled the position. Two coherent but incorrect API responses can still produce a false removal.

Concurrent runs for one watch are rejected using a platform request lock. A crashed run can hold that lock for ten minutes. Different watches are independent. Storage, billing and output are not one transaction: after a failed run, inspect delivered output and charges, then start a new run. Do not resurrect old runs. A charge may succeed while its checkpoint fails; the next run can repeat evidence. Use eventId to deduplicate retried change events; it is not a universal exactly-once guarantee across fresh baselines or independent watches.

Limits: 1,000 current jobs and 8 MiB per board response; 250,000 source characters per job; 2,000 retained entries and 8 MiB of state per board; 512 MB memory; 240-second hard live runtime. Large boards fail explicitly. Confirmed absences are retained for 30 days of observations; after expiry, a returning ID is treated as added. Time between observations determines detection latency. Empty output is not evidence that a failed board has no jobs.

Data and support

Reads the unauthenticated public Greenhouse Job Board API. No browser, proxies, application submission, candidate data, external AI API or enrichment service. Employer descriptions may contain public contact details. Data stays in your Apify output and named watch stores; it is not sent to a separate analytics service. Runs do not delete old datasets. Remove unneeded run data and both watch storages through Apify after stopping schedules; deleting a watch starts a fresh baseline next time. Verify your right to reuse employer content, especially when republishing descriptions.

Greenhouse only; no historical backfill, multi-ATS discovery, salary parsing or built-in notifications. Not affiliated with Greenhouse or monitored employers. Report failures through the Actor's Issues tab with a run ID and board token, omitting credentials and confidential information.

Local development

Use Node 22 or later and Bun. Run bun install --frozen-lockfile, bun run test and bun run demo. For an SDK demo, run bun start. Local live input goes in storage/key_value_stores/default/INPUT.json; repeated runs retain named watch state. bun run benchmark performs public API reads for Airbnb and Stripe. bun run verify:container needs the local Docker image built from .actor/Dockerfile; it performs public API reads as well. bun run stress uses synthetic data only.