What is a job postings API?

A job postings API is a web service that returns open job listings as structured data over HTTP, so software can read them directly instead of scraping careers pages. It returns each opening as a record with a consistent set of fields — title, company, location, a normalized role and seniority, and salary when the employer discloses it — typically as JSON behind an authenticated request. Job boards, market-intelligence teams, recruiters, and researchers use one to get clean hiring data at scale without building and maintaining a crawler for every source.

What it returns

The point of an API over raw scraping is normalization: every posting arrives in the same shape, whatever the source site looked like. A well-built job postings API gives you, at minimum:

• Role category — the posting mapped into one role taxonomy (engineering, sales, design, and so on) so you can filter across sources that all use different titles.
• Seniority — a normalized level (intern, junior, senior, lead) rather than whatever phrasing the employer happened to use.
• Structured location — city, region, and an ISO country code resolved from free-text location strings, plus a remote flag and scope.
• Salary when disclosed — min, max, currency, and period, populated only when the posting actually states it. Roughly a third of postings disclose pay; it is never inferred or estimated.
• Deduplication IDs — a cluster identifier shared by the same role seen on multiple boards, so one job counts once.

Most also carry the original posting URL, a timestamp for when it was listed, and the HTML body of the description. The detail varies, but normalized fields like these are what separate an API from a pile of scraped HTML.

How the data is collected

Where the data comes from matters more than any feature list, and providers fall into two camps.

First-party ATS feeds. Applicant tracking systems — the software companies use to post jobs, such as Greenhouse, Lever, and Workable — expose each employer's openings through public, structured endpoints. Reading those feeds gets you the posting straight from the system of record: complete, current, and stable, because you are consuming an interface meant to be consumed rather than parsing a page meant to be looked at.

Scraped aggregators. The alternative is crawling job boards and aggregator sites and extracting postings from their HTML. That casts a wide net, but it inherits every problem of scraping: pages change and break extraction, the same job appears many times across boards, and you are one layer removed from the source — often re-scraping data the aggregator itself scraped. Knowing which approach a provider uses tells you how trustworthy and how fresh the data really is. This dataset is read first-party from ATS platforms; it is not scraped from aggregators, and LinkedIn is not a source.

Build vs. buy

You do not always need an API. Writing your own scraper makes sense when the scope is small and contained — you are tracking one or two sources, the data feeds an internal tool, and an occasional broken run is an annoyance rather than an outage. For a single company's Greenhouse board, a short script is genuinely the right call.

Buying an API earns its keep once the work stops being a script and starts being a system. That happens when you need many sources at once, when something in production depends on the data not breaking, or when the real cost is normalization — deduplicating across boards, resolving locations, and mapping a thousand title variations into one taxonomy. That normalization burden, not the fetching, is what quietly consumes engineering time. If you would be rebuilding it anyway, buying it is usually cheaper than owning it.

How to evaluate one

Not all job postings APIs are equal. A short checklist when you compare them:

• Source transparency — does the provider name its sources and say first-party versus scraped, or stay vague?
• Refresh cadence — how often is the data re-read, and how quickly do filled roles drop out?
• Normalization depth — are role, seniority, and location genuinely structured, or just passed through raw?
• Delta sync — can you fetch only what changed since your last pull, or must you re-download everything each time?
• Honest coverage stats — does the provider publish real field-fill rates, or imply 100% coverage it cannot have?

Common uses

Teams reach for a job postings API for a few recurring jobs:

• Job boards and aggregators — powering a niche or vertical board with live listings without scraping every employer.
• Market intelligence — tracking who is hiring, for what, and where, to read demand and competitor headcount.
• Lead generation — a company posting a role is a buying signal for tools, services, and recruiters that serve that function.
• Research — labor-market and economic analysis on a clean, normalized corpus of real postings.

In every case the value is the same: structured, deduplicated postings you can query, instead of brittle scraped HTML you have to clean.

FAQ

In practice it is one authenticated request. Here it is against this API:

curl https://api.joblistingsapi.com/v1/jobs?limit=10 \
  -H "X-API-Key: $JLA_API_KEY"

See the docs for filters, pagination, and the full response schema, or the data coverage pages for live counts per source.