Greenhouse Job Feed Watch

Track changes to one Greenhouse job board across runs. Get structured observations for job-data pipelines, recruitment research, and job-board maintenance.

What it does

• Creates a baseline on the first run.
• Detects newly observed postings.
• Detects changes to titles, locations, and posting URLs.
• Tracks missing postings before marking them removed.
• Identifies postings that reappear.
• Preserves tracking history between runs.

This Actor monitors posting metadata. It does not track full job descriptions or send notifications.

Quick start

Use this input:

{ "board": "webflow", "watchName": "pilot" }

board: The Greenhouse board token, such as webflow from https://job-boards.greenhouse.io/webflow

watchName: A name for this tracking history. Keep the same board and watch name on subsequent runs. A different watch name starts a separate history.

Recommended run settings:

• Memory: 256 MB
• Timeout: 60 seconds
• Maximum cost per run: $0.03 or more
• Restart on error: Off

The Actor requires a bounded cloud-run timeout and rejects unlimited or long runs.

Example: keep a niche job board up to date

Suppose you track one company's Greenhouse board.

1. Run with a board token and a watch name. The first check saves a baseline.
2. Run again later using exactly the same input.
3. Use the status field to decide what your downstream workflow should update.

Illustrative example — these are fictional postings, not live results:

Posting	First check	Later check
Backend Engineer	baseline	unchanged
Product Designer	baseline	changed — location updated
Data Analyst	Not present	added
Sales Manager	baseline	missing_pending

A missing posting becomes removed only if it is still absent in a later complete check at least one hour after it was first missing.

For a job-board workflow:

• added: create a listing.
• changed: update its tracked metadata.
• removed: flag it for removal or review.
• reappeared: restore or review the listing.
• unchanged: no metadata update needed.

The Actor supplies these observations. Updating your website or sending an alert requires your own integration.

The first run establishes a baseline; it does not provide historical changes from before you started tracking.

Output statuses

Status	Meaning
baseline	Posting recorded on the first check.
added	Posting first observed after the baseline.
unchanged	Tracked metadata has not changed.
changed	Title, location, or posting URL changed.
missing_pending	Previously observed posting is absent from a complete source response.
removed	Posting remains absent in a later complete check, at least one hour after it was first missing.
reappeared	A previously missing posting is present again.

“Added” means newly observed by this watch, not necessarily newly published.

“Removed” means absent from the monitored feed under the rule above. It does not prove the role was filled.

Output fields

Each observation includes:

• status
• jobId
• title
• location
• url
• board
• observedAt
• eventId
• previous: earlier metadata for a changed posting

The default dataset contains observations. The default key-value store's OUTPUT record contains the run summary.

Checks include unchanged postings. Download dataset results using Apify's export options.

Pricing

• Completed board check: $0.02
• Actor start: $0.00005 per start at up to 1 GB memory
• No per-posting fee
• Standard-run platform usage is included

At the recommended memory setting, one completed check costs $0.02005.

A completed check includes the initial baseline, checks with no changes, and valid checks returning zero current postings.

The board-check event is requested only after results and tracking state are saved. The separate Actor-start fee can apply even if the check fails.

Repeat checks and integrations

Run again with the same board and watch name to compare against the saved history.

You can configure an Apify schedule or call the Actor through the API. Scheduling and external notifications are not configured automatically.

Avoid overlapping runs for the same watch. The Actor uses a shared lock to reject concurrent processing.

Limits and recovery

• One board per run.
• Up to 1,000 current postings.
• Up to 5,000 retained history entries.
• Removed-posting records are retained for approximately 30 days, with cleanup on later runs.
• Full job descriptions and changes between checks are not captured.
• Incomplete or invalid source responses stop processing.
• An interrupted run can leave the watch locked for up to 10 minutes.
• Do not resurrect runs. Start a new run instead.
• If billing is reported as uncertain, inspect that run's charge records before taking further action.

A failed run may contain partial output. Use successful runs for downstream processing. Delivery is not guaranteed to be exactly once.

Deleting the named tracking storage resets the watch history. Do not modify its state or lock queue manually.

Pilot status and support

This is an early release. Source availability and behavior can change.

Report issues through the Actor's Issues tab. Include the run ID, board token, and error message. Never include API tokens, identity documents, or other secrets.

This Actor is independently developed and is not affiliated with Greenhouse. Use source data only where you have the right to do so.