ATS scoring

Every applicant’s resume is parsed and scored against the job’s ATS criteria: the must-haves, nice-to-haves, and weighting defined on the job. The result is a 0–100 score plus a breakdown you can read over the API.

The pipeline

A candidate applies; their resume is parsed into structured data (skills, experience, education, projects, summary).
The parsed resume is scored against the job’s criteria.
Score and breakdown land on the application, ready to filter and sort by.

Parsing and scoring are asynchronous, so a just-submitted application may briefly return { "resume": null } or { "ats": null } until the pipeline completes.

Reading scores

Filter and sort candidate lists by score: GET /api/v1/jobs/:jobId/applications?sort=ats-desc&atsScoreMin=75. See Candidates.
Read the breakdown for one candidate: GET /api/v1/applications/:id/ats returns the overall score, matched/missing keywords, strengths, concerns, and per-criterion detail.

Rerunning a score

If the job description or criteria change after candidates applied, their scores are stale. Trigger a re-score with POST /api/v1/applications/:id/ats/rerun.

Fit scoring runs on paid jobs only. A free job collects and tracks applications but never scores them, so a rerun on one returns JOB_TIER_REQUIRED.

On a paid job a rerun costs one fit score, charged to that job’s own envelope rather than a shared workspace pool. It requires the resume to be parsed and the job to have a description. If the job has no fit scores left, the rerun is skipped and nothing is charged.

Judgment stays with you

The score ranks; it doesn’t decide. The API deliberately exposes the inputs too (the parsed resume and the per-criterion breakdown) so a reviewer (or Claude) can weigh a strong candidate the keyword match undersold.