HyperJobs API

A jobs dataset with the hiring company embedded in every posting — one request, no second call.

HyperJobs is a read-only HTTP API over a continuously refreshed dataset of job postings scraped directly from company ATS boards — Greenhouse, Lever, Ashby, Workday, SmartRecruiters and 60-odd others — enriched with skills, seniority, salary, and location, and joined to firmographics for the company doing the hiring.

The defining property is the join. Every job carries its company inline:

JSON

{
  "id": "ashby:0f2c…",
  "title": "Senior C++ Engineer",
  "company": {
    "slug": "stripe",
    "name": "Stripe",
    "domain": "stripe.com",
    "industry": "Financial Services",
    "employee_count": 8000,
    "hq": { "country": "US", "locality": "South San Francisco" }
  },
  "location": { "remote": false, "countries": ["United States"], "cities": ["New York"] },
  "salary": { "annual_min": 180000, "annual_max": 240000, "currency": "USD" },
  "skills": ["cpp", "cuda"],
  "keywords": ["distributed systems"]
}

Most jobs APIs hand you an employer name and leave you to resolve it. Here the company object is already attached, so a query like "remote Rust jobs at Series-B fintechs with more than 200 employees" is one request instead of a search plus N lookups.

Quickstart

Your first request in about two minutes.

Authentication

API keys, headers, and the browser caveat.

Filtering jobs

The filter vocabulary, and the semantics that surprise people.

API reference

Every endpoint, parameter, and response field.

Base URL#

GEThttps://api.hyperjobs.io/v1/jobs

Every endpoint lives under /v1. There is no other version; when a breaking change becomes necessary it will ship as /v2 and /v1 will keep working — see changelog for the compatibility policy.

What's in the dataset#

Numbers move hourly. These are indicative; call /v1/meta for live counts and per-field coverage percentages — we publish what we actually hold.

Metric	Value
Active job postings	~597,000
Companies with firmographics	~158,000
ATS boards tracked	~108,000
Sources supported (ATS, job boards, LinkedIn)	64
Postings with a parsed salary	~36%
Postings with extracted skills	~84%
Remote postings	~14%
Refresh cadence	Hourly (full pool every few hours)

The dataset is scraped from employers' own boards, not resold from an aggregator. That's why apply_url points at the real application form and why postings disappear when the employer takes them down — see duplicates & collapsing.

The shape of the API#

All read-only, all GET. The highlights:

Endpoint	Purpose
`/v1/jobs`	The search. Filter, page, sort by recency.
`/v1/jobs/count`	Match counts without fetching rows.
`/v1/jobs/feed`	Everything indexed since a cutoff — for incremental sync.
`/v1/jobs/expired`	What expired since a cutoff — so a mirror can purge.
`/v1/jobs/modified`	What changed since a cutoff, and which fields.
`/v1/jobs/{id}`	One posting.
`/v1/companies`	Firmographics.
`/v1/meta`	Counts, freshness, source breakdown, per-field coverage.

There are no POST/PUT/DELETE routes, no webhooks, and no streaming. Sync is pull-based via the feeds — new, expired, and modified cover the full lifecycle; syncing the feed covers the pattern. The full reference lists every endpoint, including the keyless /v1/health and the live /openapi.json spec.

Where to go next#

If you're evaluating: run the quickstart, then read filtering — it's where the dataset's real query surface is, and it has two behaviours that will otherwise cost you an afternoon.

If you're integrating: the Job object is the page to keep open.

Was this page helpful?