Get SmartRecruiters job postings via API

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

The direct route

SmartRecruiters runs a public Posting API for published roles. GET api.smartrecruiters.com/v1/companies/{companyIdentifier}/postings returns one company's live postings as JSON with no authentication, paged with offset and limit and a totalFound count. The company identifier is the employer's SmartRecruiters handle. It is built for customers assembling their own career sites, and for a single company it does that well.

For one company's career site, 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 SmartRecruiters 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 SmartRecruiters 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 57,282 live SmartRecruiters postings from 1,011 companies, in one normalized shape. Filter to SmartRecruiters with ?source=smartrecruiters — 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=smartrecruiters&limit=50"

The same call from Node, paging with the cursor:

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

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

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

Migrating an existing scraper

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

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