Get Ashby job postings via API

There are two ways to get Ashby job postings as structured data: read Ashby's own public feed for one company, or pull every Ashby 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 Ashby data without building the pipeline yourself.

The direct route

Ashby offers a straightforward public Job Posting API. GET api.ashbyhq.com/posting-api/job-board/{job_board_name} returns one company's live postings as JSON with no authentication, and ?includeCompensation=true adds pay data where the employer discloses it; the job board name is the slug on the company's jobs.ashbyhq.com URL. It does not filter or search — it hands you that board's roles — and for one board that is all you need.

For one company's job board, 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 Ashby 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 Ashby 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 12,206 live Ashby postings from 1,912 companies, in one normalized shape. Filter to Ashby with ?source=ashby — 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=ashby&limit=50"

The same call from Node, paging with the cursor:

// Node 20+ (global fetch, no dependencies)
// Every Ashby posting we track, in one normalized shape.
const res = await fetch(
  "https://api.joblistingsapi.com/v1/jobs?source=ashby&limit=100",
  { headers: { "X-API-Key": process.env.JLA_API_KEY } },
);
const { jobs, next_cursor } = await res.json();
console.log(jobs.length, "Ashby 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 Ashby scraper:
# stop crawling boards, sync deltas instead.

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

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

Migrating an existing scraper

If you already have a Ashby 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 Ashby 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 Ashby data page for live coverage counts.

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