Ashby & Greenhouse Job Changes | BoardWatch avatar

Ashby & Greenhouse Job Changes | BoardWatch

Pricing

$2.00 / 1,000 successful board checks

Go to Apify Store
Ashby & Greenhouse Job Changes | BoardWatch

Ashby & Greenhouse Job Changes | BoardWatch

Monitor Ashby and Greenhouse job boards for new jobs, field changes and confirmed listing removals. Persistent baselines, structured change events and success-only board-check pricing.

Pricing

$2.00 / 1,000 successful board checks

Rating

0.0

(0)

Developer

Evan Zeng

Evan Zeng

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Categories

Share

BoardWatch — Job Board Changes

Checks known public Ashby and Greenhouse job boards and compares them with the previous successful observation. Monitor a watchlist of employers without comparing full job feeds by hand. Designed for niche job boards and recruitment-data workflows.

Input

{"boards": [{"provider": "ashby", "board": "linear"}, {"provider": "greenhouse", "board": "figma"}]}

Use 1–25 board entries. The board name comes from the public careers URL. The Actor uses fixed public API endpoints; arbitrary URLs and private applicant data are not supported.

Results

The first successful check establishes a baseline without claiming existing jobs are new. Later checks report added, changed, and no_longer_listed. A job must be missing from two successful complete checks before it is reported as no longer listed. This describes listing visibility, not whether a position has been filled.

The default dataset contains board_check status rows and job_event rows. The default key-value store contains the full OUTPUT result. Job descriptions are compared by fingerprints; full descriptions are not republished. Fields include title, location, department, employment type and workplace where available.

Persistent state

On Apify, the same Actor and same board set in your account reuse a named key-value store and request queue. Reordering the list preserves the baseline; changing its membership starts a different baseline. Stores belong to your account and consume its storage allowance. Deleting a state store resets that baseline. Different tasks with identical board sets intentionally share state.

Overlapping checks of the same watchlist are skipped using a queue lock. An interrupted run can delay the next check for up to ten minutes. Failed boards retain their last successful snapshot. Delivery is at-least-once: consumers should deduplicate job events by event_id. Checks have a bounded execution window, so larger or slower watchlists may produce partial results.

Pricing is $2 per 1,000 successful board checks ($0.002 each), including the first baseline and successful checks with no changes. All job change events from that check are included. Failed checks and concurrent-run skips have no service charge. Platform usage is included in the event price for customers. The run stops checking boards when its spending limit cannot cover another check.

Set a run budget that covers the boards you want to check: two boards cost $0.004 if both succeed; 25 boards cost $0.05 if all succeed. No automatic schedule is created. Scheduling and notifications are configured separately in your own workflow. Public API availability and payload changes can interrupt coverage.

Quick start

  1. Add the public board names you want to monitor and run the Actor to establish a baseline.
  2. Run it again with the same board list to compare with the previous successful observation.
  3. Open Checks and job changes for dataset rows, or Run summary for the full result. Export the dataset as JSON or CSV for your workflow.

A successful check with no changes still produces a board-check status row. An empty events list does not mean the check failed. Look at each board's status and the run summary for errors or skipped checks.

Independent tool; not affiliated with or endorsed by Ashby or Greenhouse.

Billing reliability

Results are saved before a successful check is charged. API errors, invalid responses, insufficient budget, and concurrent skips do not trigger a board-check event. A stable per-run, per-board idempotency key prevents duplicate service charges if the same run is restarted. For a new observation, start a new run.