Skip to main content
Resume Booster

Hiring Data & API

Most job data stops at "posted." Ours follows every posting to the end: when it closed, whether it was genuinely taken down or quietly re-listed under a new ID, and what the company itself said it paid. Everything is read from employers' own hiring systems, not copied from other job boards, and a daily sample is re-checked against them.

The dataset contains zero jobseeker data: no job seeker's résumé or profile is in it, at any tier, and that data is not for sale. And no license, at any price, changes what the data says about any company — including the licensee.

Query it yourself

A read-only JSON API over the live board: free tier, self-serve, no card. Request a key on this page with an email address: we email that address a single-use link, and the key is shown once, on the page the link opens. Only its hash is stored. A free key meters at 60 requests a minute and 1,000 calls a day per key. Send it as Authorization: Bearer rb_live_….

The API lives at https://bwhdazbotpblihdxcmho.supabase.co/functions/v1/public-api: every path below is relative to it, so a search is GET https://bwhdazbotpblihdxcmho.supabase.co/functions/v1/public-api/v1/jobs. The addresses under resumebooster.work/v1 are pages that point here, not the API.

  • GET /v1/jobs — live postings, newest first; every result is still open in the employer's own feed and dated within the last 30 days. Filters for country, category, company, work mode, source system, experience band, department, pay basis and floor, posting date; paginate with cursor=, never a deep offset. explain=1 names every filter that bound; engine=ranked (paid) swaps the title match for the site's full relevance engine.
  • GET /v1/jobs/{id} — one posting with its description; a 404 once the employer withdraws it, never a stale 200.
  • GET /v1/changes — what opened and what closed since a timestamp, and for each close whether the role genuinely came down or was re-listed under a new id. Opened reaches back 30 days on any key; closed reaches back 72 hours on a free key and 180 days on a paid one, and leaves out batches our own collector flagged as a possible failed read unless you ask for them with include_suspect=true. Closures written before the collector began assessing its batches were never assessed: they carry suspectBatch: null and no walk filters them.
  • GET /v1/companies — employers ranked by open postings, from the same cached facet the board renders, with the as-of stamp and its basis.
  • GET /v1/stats — headline counts, the closure log, feed freshness (p50/p95/max minutes since each feed was last re-read) and per-system coverage, each figure with its own as-of and basis.
  • GET /v1/usage — your own consumption for the last 30 days and what is left of today's limits.
  • POST /v1/fit — 25 scorings a day on a confirmed free key, 1,000 on an account with a paid plan, counted together with fit_resume on the MCP server: a résumé in, the board's best matches out, scored with matched and missing terms; stores nothing.

Two hiring systems on the job board are not handed on by this server or the data API: the U.S. federal job feed, whose terms forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. Their postings stay on the job board, where you can open them yourself.

Pointing an AI agent at this data instead of writing code? The same free keys work on the MCP server, which serves the same board to Claude Code and any MCP client that can send a header, at https://bwhdazbotpblihdxcmho.supabase.co/functions/v1/agent-mcp.

Access beyond the free tier

Free for journalists with attribution, at cost for academic and nonprofit research, and custom-priced for commercial feeds — volume, history and bulk export. Every request gets a human reply.

A live slice is already public: see the Ghost Job Index, Weekly Hiring Trends, the Entry-Level Index and the Pay Transparency Index.