Use a structured job feed before parsing a careers page
A careers site may already expose the data needed for a jobs list. Greenhouse publishes Job Board GET endpoints; Lever publishes a postings API with JSON output. These are more stable starting points than selectors tied to a page’s visual layout.
The hosted tool accepts five covered Greenhouse board URLs. It resolves the board to a fixed public endpoint and returns up to ten normalized summaries. It does not crawl arbitrary company websites. Use the downloadable collector to retrieve the complete list returned by one supported board.
Job posting data: identifiers, dates, and meaning
Keep provider, board, posting ID, title, location, public job URL, source URL, and fetch time together. A posting ID is unique within its provider and board; do not treat a title as an identifier. The fetch time tells you when a response was obtained, not when hiring began.
Published jobs are not a complete headcount or hiring-demand measure. A board may combine locations or keep a recurring opening online. One empty response does not establish that an employer stopped hiring or changed its ATS.
Access rules and collection limits
Check the publisher’s API documentation, terms, and applicable permission requirements before collecting or redistributing data. Public visibility alone is not a blanket license to reuse content. RFC 9309 defines robots.txt as a crawler-control protocol, not access authorization.
This implementation only reads published job summaries. It uses cached responses, a timeout, and no automatic retries. If an upstream service fails or limits requests, the tool shows an error rather than reporting zero jobs. Private applicant endpoints, application submissions, login pages, and access-control bypasses are outside its scope.
Run the open-source collector
Download the Python collector and its MIT license below. Run it with a supported board URL; it writes JSON to standard output and a clear error to standard error on failure. It has no external package dependency and makes one request per run.
For production collection, keep snapshots with stable IDs, schedule conservatively, and use a defined retention policy. Compare complete responses before inferring a posting removal. Do not interpret posting churn as an ATS vendor switch.