Greenhouse Jobs Scraper & Change Monitor

Keep your job tracker or recruiting dashboard up to date with observed changes to public Greenhouse job boards. RelayGrove saves the first observation as a baseline, then automatically reports newly observed listings, edits, confirmed removals and reappearances on later runs. No manual snapshot transfer or comparison script is needed.

For technical recruiting teams and job-data builders, export JSON or CSV to review hiring activity at companies on your watchlist or feed your own data pipeline. Job events include listing IDs, titles, locations, public links and observation times. This tool is independently developed by RelayGrove and is not affiliated with Greenhouse or the companies being monitored.

Public beta — no RelayGrove fee. You pay only for the Apify platform resources used in your own account. This is a short beta while we evaluate recurring use and future pricing. No end date has been set. Any introduction of a RelayGrove fee will be announced in advance under Apify's pricing-change rules.

Start in three steps

1. Enter one to ten Greenhouse board tokens. For https://boards.greenhouse.io/stripe, the token is stripe.
2. Run the Actor once to save your first baseline. Confirm that the run succeeds and SUMMARY.stateCommitted is true.
3. Run it again with the same input, or schedule it in Apify. A daily schedule is a reasonable starting point when you do not need intraday changes.

{
  "boards": ["stripe"],
  "monitorName": "daily-hiring",
  "confirmMissing": 2,
  "minimumConfirmationHours": 1
}

The first run produces baseline job events for existing listings, not proof of newly posted jobs. Each successfully fetched, validated and compared board also produces one board_check row. An unchanged repeat has zero job events but still has a check row for each successful board. A genuinely empty, valid board also produces a check row with currentCount: 0.

Illustrative example for one board — these are example counts, not a live result:

Observation	Dataset output
First check finds 100 posts	100 baseline events + 1 board_check
Next check finds no changes	1 board_check, zero job events
Later check finds 2 additional posts and 1 edited listing	2 new + 1 changed + 1 board_check

To process only changes after the baseline, keep rows whose type is new, changed, removed_from_board or reappeared. Skip baseline and board_check. A new event means first observed by this monitor after its baseline, not a guaranteed original posting date.

Automatic history lives in a named key-value store in your own Apify account. The Actor uses Limited permissions. Each account, Actor and monitor name has separate history. You do not need to copy snapshots between runs or provide a Greenhouse login.

Reuse the monitor name for the same board collection and removal rules. To change that configuration or start a fresh baseline, use a new monitor name. Two simultaneous runs of the same monitor are prevented from comparing or overwriting the same history; the second run fails clearly so it can be retried later.

What the events mean

Event	Meaning
baseline	Present at the first successful observation.
new	First observed after the baseline. This is not a guaranteed original posting date.
changed	Title, location, URL, department, office or description fingerprint changed.
removed_from_board	Absent in at least two complete observations, separated by the configured minimum time. This does not establish that a job was filled.
reappeared	Visible again after a previously confirmed removal.

Timestamp-only source updates are ignored. Description changes are detected using a normalized text fingerprint; the full description and a text diff are not included. Changed structured fields include their before and after values.

Every job event includes eventId, type, board, jobId, observedAt and a job object containing the title, location, public URL, departments, offices, source update timestamp and description fingerprint. Export the dataset as JSON or CSV, or connect it to your own workflow through Apify.

The same dataset includes comparison summaries with type: "board_check". These contain monitorName, board, observedAt, ok: true, baseline, currentCount, trackedCount, missingPendingCount, removedCount, eventCount and per-event counts. They do not have eventId, jobId or job. To process all job events, including the initial baseline, filter rows with type !== "board_check".

A check row means that a complete board response was validated and compared. Rows are written before history is saved, so the row does not prove that the whole run succeeded or its history was committed. Use the final run status and SUMMARY.stateCommitted for those conclusions.

Saved outputs

• Dataset: Job events with stable event IDs, plus one board_check row per successful board comparison. The existing output link remains named events for compatibility and returns both record types.
• SUMMARY: Per-board health, errors and stateCommitted, plus eventCount (job events only), checkCount (successful board comparisons) and datasetRowCount (both kinds of rows). An unchanged fully successful run has eventCount: 0, one check per selected board and the same number of dataset rows as checks.
• NEXT_SNAPSHOTS: A portable backup of the comparison history. Ordinary runs load history automatically.

An unavailable board, incomplete response or invalid data never becomes an empty successful observation and gets no successful board_check row. Failed boards retain their earlier history. Successful comparisons can still have rows and saved history in a partially failed run; the run remains failed. Inspect SUMMARY before retrying.

Job events and check rows are written before history advances. If a run is interrupted between those operations, a later run can repeat events. Deduplicate job events by eventId when combining outputs. Check rows summarize individual comparisons and have no event ID; do not count them as job changes. Exactly-once delivery is not promised. A timed-out run can hold its monitor lock for up to five minutes; start a new run after the lock expires. Runtime is capped at two minutes as a safety bound.

Make a job-change spreadsheet

1. After a successful run, export the dataset as CSV and open it in your spreadsheet app.
2. Filter type to new, changed, removed_from_board and reappeared. The first baseline and board_check rows are not subsequent job changes.
3. Keep observedAt, type, board, jobId, job.title, job.location, job.url and eventId. Sort by observedAt. For edited fields, inspect changedFields in the JSON export.
4. When combining exports, remove duplicate rows by eventId. Keep the IDs so a retried run does not count the same event twice.

Fictional example, showing selected columns only:

Observed at (UTC)	Event	Board	Job	Location
2026-10-24 09:00	new	example-company	Data Analyst	Remote, US
2026-10-24 09:00	changed	example-company	Backend Engineer	New York

These are illustrative records, not real vacancies. Observation time is when the monitor saw the change, not the employer's publication time.

Pricing and schedules

During this beta, RelayGrove charges no product fee. Apify calls this pay per usage: the compute, storage and other platform resources used by your runs are billed to your own Apify account or deducted from its available credits. Platform usage is not unlimited or guaranteed free. Consult the Actor's Pricing tab and your account limits before running or scheduling it.

Future pricing and the beta end date are undecided. The current no-developer-fee offer is temporary. Any paid transition will be announced in advance and follow Apify's applicable pricing-change rules; no automatic conversion date is set.

A schedule runs only when you create it in Apify. This Actor does not create schedules, send messages or enable external integrations itself. Storage persists between runs, but checking a board still requires a run. Named storage continues to occupy space until you remove it; ordinary platform limits apply.

Frequently asked questions

Can I get only newly observed jobs? After the first baseline, keep rows with type: "new". Existing posts in the baseline are not new-job events, and observation time is not a guaranteed publication time.

Does it check automatically or send alerts? Create an Apify schedule to repeat checks with the same input. The Actor saves its history automatically, but it does not create schedules or send alerts. Connect the output to your own workflow if you need notifications.

Does it return full job descriptions? No. It returns public job metadata and a normalized description fingerprint. Description changes can be detected, but full description text and text diffs are not returned. Changed structured fields include before-and-after values.

Scope and limits

• Supports public boards on the main boards-api.greenhouse.io endpoint. EU-region boards, other hiring platforms, arbitrary URLs and automatic company discovery are not supported.
• Between 1 and 10 board tokens per monitor; maximum 5,000 current posts per board and 10,000 tracked posts per board. Limits fail visibly rather than silently truncating data.
• Each source response is limited to 10 MiB with bounded retries. A large or slow batch may need to be split across separate monitors to fit the two-minute run limit.
• History is bounded but not automatically pruned. If tracked history reaches its limit, preserve the exported backup and start a new monitor; the new monitor establishes a fresh baseline.
• Description normalization handles ordinary HTML and entities but is not a full HTML parser. Some formatting changes can still produce a fingerprint change.
• These are source observations, not verified hiring outcomes or business intentions. Briefly removed listings, board migrations and publisher edits can affect results.
• Public job metadata only. No applicant information, private Greenhouse access, contact enrichment, proxy service or AI API is used.

Migrating an earlier manual pilot

On a monitor's first run only, an optional previousSnapshots array can import a saved NEXT_SNAPSHOTS backup. Once automatic history exists, that saved history wins over a valid supplied seed. A malformed seed still fails input validation. Leave the field empty for normal use.

Support

Use the Actor's Apify Issues tab when available. Include the run ID, board token, approximate time and a description of the problem. Do not include passwords, API tokens or applicant information. For a source error, inspect SUMMARY; for a busy monitor, wait for the other run or its lock to finish and start a new run.

For beta feedback, tell us what you use the results for, whether you have run the same monitor on more than one day, and one thing that would make it more useful. Scheduled checks are welcome. We do not add a separate usage tracker or send your monitored jobs to a RelayGrove server; Apify provides its own developer analytics.