# Glossary > The vocabulary this API uses — data-model terms, filter semantics and operational concepts — defined once, with the page each one is load-bearing on. Source: https://hyperjobs.io/glossary ## The data model ### ATS (Applicant Tracking System) The software an employer runs its hiring on — Greenhouse, Lever, Workday and the like. Each customer gets a public job board hosted on the ATS, and those boards are where every posting in this dataset is read from. Reference: https://hyperjobs.io/docs/reference/sources ### The company join The defining property of this API: every job posting carries its hiring company inline — name, domain, industry, headcount, HQ — rather than a bare employer string you have to resolve yourself. One request answers questions like "remote Rust roles at Series-B fintechs over 200 people". Reference: https://hyperjobs.io/docs/objects/company ### Firmographics Company-level attributes — industry, employee count, domain, headquarters — attached to the employer on each posting. What lets you filter jobs by the kind of company doing the hiring, not just the job itself. Reference: https://hyperjobs.io/docs/objects/company ### Skills Exact-match skill tokens extracted from each posting ("python", "airflow", "cuda"). Present on about 84% of postings — a filter on skills is a stronger statement than it looks, because it also drops everything nobody tagged. Reference: https://hyperjobs.io/docs/guides/skills-and-taxonomies ### Taxonomy A normalised job family ("Software", "Sales") assigned to a posting so you can group roles across employers who title them differently. Populated on roughly two-thirds of the dataset. Reference: https://hyperjobs.io/docs/guides/skills-and-taxonomies ### work_arrangement The Remote / Hybrid / On-site classification of a role. Distinct from location.remote — they draw on different evidence and disagree on purpose, so pick the field that matches the question you're asking. Reference: https://hyperjobs.io/docs/reference/enums ### Salary normalisation Pay bands from every source reshaped into one salary object with annual_min / annual_max in a common currency and unit — so Greenhouse's cents and Ashby's typed tiers arrive identically. Present on about 36% of postings, because most employers publish no band. Reference: https://hyperjobs.io/docs/guides/salary ### apply_url The employer's real application form — the same URL a candidate reaches from the company's own careers page, not a redirect or an aggregator's mirror. Falls back to the posting url when a board publishes no separate apply link. Reference: https://hyperjobs.io/docs/objects/job ## Sources & provenance ### Source The board a posting was ingested from (greenhouse, lever, linkedin…), carried on every posting and usable as a filter. It's an exact, case-sensitive, free-form match — not a checked enum — so a typo returns zero rows rather than an error. Reference: https://hyperjobs.io/docs/reference/sources ### source_type How a posting reached us: ats (the employer's own board), jobboard (a third-party board like LinkedIn), or aggregator (a re-listing site). One filter on one schema, rather than the separate products some providers sell for each. Reference: https://hyperjobs.io/docs/reference/sources ### Board One company's public job board on an ATS — a single careers page holding anywhere from zero to several thousand open roles. The ingestion queue tracks over 108,000 of them; a tracked board is where postings could come from, never a promise of how many you'll get. Reference: https://hyperjobs.io/docs/reference/sources ### Board token The identifier for a specific board inside an ATS's URL scheme — the segment in boards.greenhouse.io/. Deriving it reliably is harder than it looks, because platforms accumulate several URL shapes for the same board over the years. Reference: https://hyperjobs.io/ats/greenhouse ### Requisition ID The employer's internal identifier for a job opening. Frequently junk — employers type "tbd", "n/a" or a bare dash into it — so it can't be trusted as a stable key without filtering the placeholders out. Reference: https://hyperjobs.io/ats/greenhouse ## Freshness & lifecycle ### Deduplication (collapsing) The same job posted to several boards is folded into a single row rather than returned multiple times. The surviving row's source tells you which copy won — not the only board the job ever appeared on. Reference: https://hyperjobs.io/docs/guides/deduplication ### Board diffing (reaping) How postings expire: each time a board is re-fetched, roles that were there last time and aren't there now are marked expired. The employer taking a job down is the signal — expiry is never guessed. Reference: https://hyperjobs.io/docs/reference/coverage ### expires_at A posting's declared expiry, when a board publishes one. Most don't, so expires_at is usually null on a perfectly live posting — a null value does not mean the job runs forever. Reference: https://hyperjobs.io/docs/objects/job ### posted_at When a posting went live on its board. A good ordering key and "newer than X" filter — but the lag between a job going live and appearing here varies by source, so don't assume uniform latency. Reference: https://hyperjobs.io/docs/objects/job ### Refresh cadence How often boards are re-read. Ingestion runs hourly, working the stalest boards first; fast, direct APIs are hit every cycle while heavier or rate-limited platforms run less often. The whole pool is covered every few hours. Reference: https://hyperjobs.io/docs/reference/coverage ## Querying & access ### Feed The incremental endpoints built for keeping a local mirror in sync — new, expired and modified since a cutoff — covering a posting's full lifecycle. The right tool for bulk sync, instead of paging /v1/jobs to the end. Reference: https://hyperjobs.io/docs/guides/feed-sync ### Cursor pagination Keyset paging via the next_cursor token, stable at any depth — the way to walk a large result set. Unlike deep offset paging, it doesn't get slower the further in you go. Reference: https://hyperjobs.io/docs/pagination ### coverage_pct Live per-field fill rates published on /v1/meta — what share of postings actually carry a salary, skills, seniority and so on, remeasured continuously. The honest, current version of any completeness number. Reference: https://hyperjobs.io/docs/reference/coverage ### /v1/meta The single live authority on the dataset: total counts, freshness, the source breakdown, and the exact filter vocabularies. When a number matters, read it from here rather than hardcoding it — everything else rots. Reference: https://hyperjobs.io/docs/api-reference/meta ### Quota The number of API requests a plan includes per calendar month, from 500 on the free tier up. Separate from the rate limit: quota is how many requests, the rate limit is how fast. Reference: https://hyperjobs.io/docs/rate-limits ### Rate limit The sustained requests-per-minute cap on a key, set by plan. Hitting it returns a 429; it protects the shared index and is the axis plans scale on alongside the monthly quota. Reference: https://hyperjobs.io/docs/rate-limits