Get JazzHR job postings via API

There are two ways to get JazzHR job postings as structured data: read JazzHR's own public feed for one company, or pull every JazzHR board at once from a single normalized endpoint. The first is the right tool for a single employer's board. This guide covers both — what the vendor feed gives you, where cross-company aggregation requires something more, and how to get clean JazzHR data without building the pipeline yourself.

The direct route

JazzHR exposes its postings through an API keyed per company — the key lives in each account's own Integrations settings — returning that employer's roles with simple page-based paging. It is meant for a company reading and syndicating its own jobs, and for that it works fine: one account, one key, that account's postings.

For one company's own account, that is the right tool, and you should use it. It is first-party, it is current, and it is free. If you are tracking a handful of companies you care about, a short script against their feeds will serve you well — there is no reason to reach for anything heavier.

Where it gets hard

The vendor feed answers one question well: what is open at this one company? The moment your question becomes what is open across JazzHR as a whole, you are no longer reading a feed — you are running an aggregation pipeline, and that is a different job:

• Discovery. There is no master list of every JazzHR board token. You have to find thousands of company identifiers and keep finding them as new employers onboard and others churn off.
• Polling at scale. Each board is a separate request. Refreshing thousands of them on a schedule — without hammering any one endpoint, while respecting rate limits and back-off — is real scheduling and infrastructure work.
• Normalization. Each feed reflects whatever the employer typed. Titles, locations, and seniority are inconsistent across companies, so "Sr. Eng II" and "Senior Software Engineer" need to resolve to the same normalized role and level before the data is comparable.
• Deduplication. Companies post the same role on multiple boards and re-post it over time. Without a stable dedup key you count one job several times.
• Silent disappearance. Postings vanish from a feed when they close, usually with no event. Knowing a role is gone — and when — means diffing every poll against the last.

None of this is exotic, but all of it is ongoing. It is the part that quietly turns a weekend script into a service someone has to own.

The aggregated alternative

We do that aggregation once, for every source, and expose the result as one endpoint. Right now that is 25,864 live JazzHR postings from 3,007 companies, in one normalized shape. Filter to JazzHR with ?source=jazzhr — the source filter is available on every plan, including the free tier:

curl -H "X-API-Key: YOUR_KEY" \
  "https://api.joblistingsapi.com/v1/jobs?source=jazzhr&limit=50"

The same call from Node, paging with the cursor:

// Node 20+ (global fetch, no dependencies)
// Every JazzHR posting we track, in one normalized shape.
const res = await fetch(
  "https://api.joblistingsapi.com/v1/jobs?source=jazzhr&limit=100",
  { headers: { "X-API-Key": process.env.JLA_API_KEY } },
);
const { jobs, next_cursor } = await res.json();
console.log(jobs.length, "JazzHR postings;", next_cursor ? "more" : "end");

And the pattern that replaces a polling scraper outright — backfill once, then sync only what changed with updated_since, also on every plan:

# Migration pattern for an existing JazzHR scraper:
# stop crawling boards, sync deltas instead.

# 1. Backfill once — walk the cursor to the end.
GET https://api.joblistingsapi.com/v1/jobs?source=jazzhr&limit=100
  -> { "jobs": [...], "next_cursor": "eyJpZCI6..." }
GET https://api.joblistingsapi.com/v1/jobs?source=jazzhr&limit=100&cursor=eyJpZCI6...

# 2. Then poll only what changed since your last run.
GET https://api.joblistingsapi.com/v1/jobs?source=jazzhr&updated_since=2026-06-11T06:00:00Z

Migrating an existing scraper

If you already have a JazzHR scraper in production, you do not rewrite it — you swap the source underneath it. Four steps:

1. Map your schema to ours. Line your existing columns up against the response fields in the docs — title, company, structured location, role_category, seniority, salary. Most scrapers already have these in some form; you are renaming, not redesigning.
2. Backfill. Pull the current JazzHR set once with the cursor (or offset paging) until next_cursor is null, so your store starts complete.
3. Switch incremental syncs to updated_since. Replace your per-board polling loop with one delta call that returns only records changed since your last run.
4. Key your dedup on duplicate_cluster_id. Drop your home-grown fuzzy matching and trust the cluster ID — the same role across multiple boards already shares one.

FAQ

See the docs for the full response schema and filters, or the JazzHR data page for live coverage counts.

Job Listings API is not affiliated with, endorsed by, or sponsored by JazzHR. JazzHR and other product names are trademarks of their respective owners.