Lever Job Scraper — Clean Schema + Seniority + Remote Type

For talent intelligence and job aggregation teams that scrape Personio, Contentful, Gorillas, Lyft, Figma — and need all office locations per posting, not just the primary.

Pay per result — $1.50 / 1,000 jobs. No API key. No proxy. Official Lever API — no bans.

Extract job postings from any Lever-powered career page — Personio, Gorillas, Contentful, Lyft, Figma, Brex, and 5,000+ more companies. Uses Lever's official public API: zero auth, zero proxy cost, zero bans.

What makes this scraper better?

Most Lever scrapers return raw API fields with minimal processing. This one adds:

Edge	What it means
Canonical seniority	Inferred from title: executive / vp / director / manager / principal / staff / lead / senior / intern / entry / mid
Canonical remote_type	remote / hybrid / onsite — from workplaceType first, location text fallback
Full merged descriptions	All Lever sub-sections merged: intro + body + bullet lists + additional info
Salary extraction	Parsed from salaryDescription when the company populates it
allLocations	Multi-location postings include all posting locations, not just the primary
parse_confidence	Machine-readable quality score per record (0.0–1.0) + warnings list
global_id	lever:<company>:<job_id> — stable deduplication key across runs
Clean, flat schema	Predictable column set every run — no surprise null keys

Input

{
  "companies": ["personio", "contentful", "gorillas"],
  "titleKeyword": "engineer",
  "locationKeyword": "New York",
  "remoteOnly": false,
  "includeDescriptions": true,
  "maxJobsPerCompany": 50,
  "maxTotalJobs": 0
}

How to find a company slug: Go to jobs.lever.co/<slug> — the slug is the part after lever.co/. Example: jobs.lever.co/personio → slug is personio.

Output schema

{
  "company":          "personio",
  "title":            "Senior Software Engineer",
  "location":         "New York, NY",
  "all_locations":    "New York, NY, San Francisco, CA",
  "remote_type":      "hybrid",
  "seniority":        "senior",
  "department":       "Engineering",
  "team":             "Platform",
  "employment_type":  "Full-time",
  "salary":           "$150,000 – $200,000 USD",
  "url":              "https://jobs.lever.co/personio/abc123",
  "apply_url":        "https://jobs.lever.co/personio/abc123/apply",
  "posted_at":        "2024-01-15T08:30:00+00:00",
  "job_id":           "abc123",
  "global_id":        "lever:personio:abc123",
  "description_text": "We are looking for…",
  "description_html": "<p>We are looking for…</p>",
  "parse_confidence": 1.0,
  "warnings":         []
}

Use cases

• AI job-matching pipelines — clean, flat schema feeds LLMs and vector DBs
• Talent intelligence — track competitor hiring signals in real time
• Job aggregator sites — populate boards with fresh postings
• Recruitment research — analyze tech hiring trends, seniority distributions
• Sales prospecting — identify companies actively hiring in specific roles

Pricing

Pay-per-result PPE model: $1.50 / 1,000 jobs ($0.0015 per record).

Worked example: 5 companies × 50 jobs = 250 results = $0.38. 20 companies × 100 jobs = 2,000 results = $3.00.

FAQ

Do I need an API key or proxy? No. Lever's public API (api.lever.co/v0/postings/<slug>) is open — no auth, no proxy cost, no bans.

What output formats are available? JSON, JSONL, CSV, and Excel via the Apify dataset export, plus the Apify REST API.

Can I schedule daily runs? Yes — use Apify Scheduler. Each run returns the current open jobs; use global_id (lever:<company>:<job_id>) as a stable key for deduplication.

What if a company returns 0 jobs or the slug is wrong? The actor logs a warning, records the slug in failedDetails, and continues with the remaining companies — no crash, no broken run.

Integrations

Built for talent-intelligence and job-aggregation teams tracking open roles with seniority, remote type, and salary across Lever boards — the JSON/dataset output drops into the tools you already run, no glue code:

• n8n / Make / Zapier — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: n8n, Make, Zapier.
• Webhooks — fire your own endpoint the moment a run finishes, to push results straight into your pipeline (docs).
• MCP server — expose this actor as a tool to Claude, Cursor, or any MCP client so an AI agent can pull this data mid-conversation (guide).
• API & SDKs — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all Apify integrations.

Is it legal?

Yes. We query Lever's official public API (api.lever.co/v0/postings/<slug>?mode=json), which is publicly accessible without authentication. No personal data beyond what companies choose to publish publicly.

Competitor comparison

Feature	This actor	satish5813/lever-jobs-scraper	bytepulselabs/lever-job-scraper-eu
Seniority field	✅ (11 levels)	❌	❌
Canonical remote_type	✅	✅ raw field	partial
Merged descriptions (all sections)	✅	partial	partial
parse_confidence per record	✅	❌	❌
all_locations (multi-location postings)	✅	❌	❌
global_id for deduplication	✅	❌	❌
Title keyword filter	✅	✅	❌
Location keyword filter	✅	✅	❌
Remote-only filter	✅	❌	❌
maxTotalJobs cap (billing safety)	✅	❌	❌
Official API (no DOM scraping)	✅	✅	✅
Price	$1.50/1k	varies	varies

all_locations is unique to this actor in the cluster: multi-location Lever postings include every office, not just the primary posting location. Essential for global talent intelligence.

parse_confidence (0.0–1.0) and warnings in every record — deductions for missing job_id (0.50), title (0.30), url (0.10), location (0.05), posted_at (0.05), description (0.05).

Use with AI agents (MCP)

This actor is MCP-compatible. Use it as a data source in n8n, Make, or any LLM agent pipeline.

https://mcp.apify.com/?tools=bovi/lever-job-scraper-eu

The flat schema with global_id (lever:<company>:<job_id>) and all_locations is designed for LLM pipelines, vector databases, and n8n/Make job-matching workflows. Need to cover Greenhouse, Ashby, Recruitee, SmartRecruiters and Personio too? Use the flagship Multi-ATS Job Scraper — all 6 ATS in one unified schema.

More scrapers from our toolkit

Building a data pipeline? These actors pair well with this one — each runs on your own Apify account with the same pay-per-result pricing, no subscription:

• Naukri Jobs Scraper
• Seek Jobs Scraper
• Stepstone Jobs Scraper
• Workable Job Scraper
• Xing Jobs Scraper
• Ashby Job Scraper

Chain any of them together from the Integrations tab (the Run succeeded trigger) to build a multi-step workflow — one actor's output feeds the next.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.