Get Lever job postings via API

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

The direct route

Lever publishes a public Postings API. GET api.lever.co/v0/postings/{site} — adding the Accept: application/json header or &mode=json — returns one company's open roles as structured JSON without authentication, where {site} is the company's Lever handle. It is simple and well-documented, and for a single company's postings it is exactly the right tool.

For one company's postings, 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 Lever 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 Lever 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 10,150 live Lever postings from 1,313 companies, in one normalized shape. Filter to Lever with ?source=lever — 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=lever&limit=50"

The same call from Node, paging with the cursor:

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

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

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

Migrating an existing scraper

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

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