live

Rows a caller can obtain from /v1/jobs: not closed, not opted out, and not held back by the quality gate. This is the only figure you can reproduce by paging the API, and it is the number the website quotes.

withheld

Rows present in the ledger and deliberately not served. Three reasons, each with its own count — see Withheld rows.

closed

Roles that came off their source. Retained with the date and the reason, queryable with status=closed. See Closed roles.

ledger_rows

All three, summed. The size of the record, not the size of the product.

The reason to publish all four rather than only the first is that the difference between them is the editorial policy. A product that serves 3.7 million rows out of a 7.4 million row ledger has made about half of its decisions in the gap, and hiding the gap would make those decisions unauditable. Publishing it invites the obvious question — what is in the other half — and the answer is on this page.

quality_removed

The row breaches the employer-direct guarantee, or it came from a discovery-only source. Typically the apply link resolves to an aggregator, an agency or a government portal rather than to the employer. No query parameter re-admits these. That is the point of the guarantee: it is not a default you can turn off.

quality_gated

Reversible doubt. A posted_at in the future, a missing apply URL, a shape that usually indicates a broken scrape. These can be re-admitted deliberately with quality=all on a paid key, and each returned row then carries its verdict, the rule id that matched, and the host that triggered it — so you can judge for yourself rather than trusting the gate.

optout_hidden

A site owner asked to be removed and we verified the request. These are never re-admitted by any parameter, and the removal propagates to every endpoint including the closure feeds. See Employer opt-out.

Why keep them at all? Because deleting them would make the ledger unable to answer why a row is not there, and would make the same row re-enter and re-leave every time the source is re-read. Retention is what makes “we deliberately do not serve this” a checkable statement rather than an absence.

Two things make closures worth having. The first is correctness: if you are mirroring this data you need to know when to stop serving a row, and a row that simply vanished from a listing endpoint is indistinguishable from one that fell off the end of your pagination. The second is signal: the date a company stopped recruiting for a role is often more informative than the date they started.

There are three ways to consume closures, in increasing cost. /v1/jobs/expired returns ids, closure dates and reasons only — about ninety per cent smaller than the equivalent page of rows, and enough to mark your own records stale. /v1/changes folds closures into a single ordered stream with creations and updates. /v1/jobs/closed returns the full rows, with every filter /v1/jobs takes.

The reconciliation is the guarantee. It says that every row is accounted for in exactly one bucket, that nothing has been quietly dropped, and that the served population is a stated subset rather than whatever survived a pipeline. It is cheap to verify and you should verify it rather than take it on trust — that is the whole idea.

The report is measured on a schedule rather than per request, because counting it per request took twenty-four seconds and returned a 503 instead. So it carries measured_at, age_seconds and a stale flag. stale: true means the snapshot is older than its refresh window; the numbers are then indicative rather than current.

Every listing has a id (a uuid) and a slug. The uuid is the identity: it never changes, it survives a role being closed and re-opened, and it is what /v1/changes and /v1/jobs/expired refer to. The slug is a human-readable alias built from the title and the first eight characters of the uuid, which is what makes it unique. GET /v1/jobs/{id} accepts either.

Companies are the harder case. A company has a slug and, on about a third of rows, a website domain. The slug is derived from the display name, and display names are corrected over time — an employer whose ATS token was jj becomes johnson-johnson once the name is resolved properly. That correction is a genuine improvement and it moves the slug.