Levels.fyi Salary Scraper — Real Tech Comp Data | from $3/1K | No Login

For recruiters benchmarking offers, HR teams building comp bands, job-seekers negotiating, and AI models that need real salary training data — Levels.fyi has the most transparent individual compensation records in tech.

$3.00 per 1,000 salary records. These are real individual submissions from Levels.fyi — not estimates, not averages. Each row is a unique compensation package with base, stock, bonus, level, and location. Real submissions, not estimates. Individual records — not just averages. No login required. FAANG + 100+ companies.

Pricing example: 200 Google SWE records = $0.60. 3 companies × 2 roles × ~100 records = 600 records = $1.80. Full FAANG sweep (5 companies × 3 roles × ~200 records = 3,000 records) = $9.00.

Use case: salary negotiation — Pull 200 Google L5 SWE records in SF to benchmark your competing offer. Job-seekers are the largest audience for this data.

Source	Price	Individual records?	Level codes?	Stock/bonus split?
This actor	$3/1k	Yes	Yes (L3/E4/IC3)	Yes
Glassdoor salary scraper	$2-5/1k	Estimated only	No	No
Payscale data	Enterprise	Aggregate only	No	No
LinkedIn salary insights	Enterprise	Aggregate only	No	No

Scrape real tech compensation data from Levels.fyi by company and role. Returns individual salary submissions with full compensation breakdown per level.

Features

• Zero cost to run — no proxy, no auth, no API key required
• Individual salary records — not just averages; each submission is a separate row
• Full compensation breakdown — base salary, total comp, stock (annualized), bonus
• Multi-company, multi-role — scrape any combination in a single run
• Level-aware — data grouped by company level (L3/E4/IC3/etc.) with level codes normalized to uppercase
• parse_confidence — every record carries a data quality score (1.0 = all fields present)
• Batch queries — list of companies × list of roles, all in one run

Input

{
  "companies": ["google", "meta", "openai", "amazon", "microsoft"],
  "roles": ["software-engineer", "data-scientist"],
  "maxItems": 500
}

Field	Type	Default	Description
companies	string[]	[]	Company slugs from Levels.fyi URLs (lowercase, hyphenated)
roles	string[]	["software-engineer"]	Role/job-family slugs
searchQueries	string[]	[]	Company name search (used if companies is empty)
maxItems	integer	200	Max total records (0 = unlimited)
includeAllLevels	boolean	true	Include all levels or just page defaults
minSamplesPerLevel	integer	1	Skip levels with fewer samples

Common company slugs: google, meta, amazon, microsoft, apple, netflix, openai, stripe, airbnb, uber, lyft, linkedin, salesforce, nvidia, bytedance

Common role slugs: software-engineer, data-scientist, product-manager, software-engineering-manager, product-designer, data-engineer, machine-learning-engineer

Output schema

Each result row is a salary submission with these fields:

Field	Type	Description
company	string	Company display name (e.g. "Google")
title	string	Specific job title (e.g. "Backend Software Engineer")
role	string	Job family (e.g. "Software Engineer")
level	string	Company level code, normalized (e.g. "L3", "E4", "IC3")
location	string	City, State (e.g. "San Francisco, CA")
total_comp	integer	Total annual compensation (USD)
base_salary	integer	Annual base salary (USD)
stock	integer	Annualized stock grant value (USD)
bonus	integer	Annual bonus (USD)
years_experience	number	Total years of professional experience
years_at_company	number	Years at this company
date	string	Submission/offer date (ISO 8601 YYYY-MM-DD)
uuid	string	Levels.fyi submission UUID
source_url	string	Page URL this record was scraped from
scraped_at	string	ISO 8601 UTC scrape timestamp
parse_confidence	float	Data quality score 0.0–1.0 (1.0 = all fields present)
warnings	string[]	List of quality warning codes

Example output

{
  "company": "Google",
  "title": "Software Engineer",
  "role": "Software Engineer",
  "level": "L3",
  "location": "San Francisco, CA",
  "total_comp": 210000,
  "base_salary": 160000,
  "stock": 40000,
  "bonus": 10000,
  "years_experience": 3,
  "years_at_company": 1,
  "date": "2026-05-23",
  "uuid": "2218e4a5-18f0-404a-aa6f-805b4508f944",
  "source_url": "https://www.levels.fyi/companies/google/salaries/software-engineer",
  "scraped_at": "2026-05-31T10:00:00Z",
  "parse_confidence": 1.0,
  "warnings": []
}

Use cases

• Salary negotiation research — benchmark your offer against real submissions
• Compensation benchmarking — compare packages across FAANG and Big Tech
• HR analytics — market salary data by role, level, and location
• Job market research — track comp trends across companies and roles
• Recruiting tools — power competitive compensation analysis dashboards

Pricing

Pay per result (PPE). $3.00 per 1,000 salary records. Each salary record = 1 charge event (salary-item).

Technical notes

• Data source: Levels.fyi's Next.js SSR __NEXT_DATA__ JSON blob (stable, structured)
• No scraping proxy needed — data is server-side rendered and publicly accessible
• Each page provides ~10–30 individual samples per level; count field shows the full DB size
• Rate limiting: no observed limits on standard page requests; actor uses conservative single-page fetches
• Not affiliated with Levels.fyi

parse_confidence trust score

Every record carries a parse_confidence score (0.0–1.0). Score 1.0 means all fields are present. The warnings list tells you which specific fields were missing for programmatic filtering.

Use with AI agents (MCP)

AI salary research via MCP — ask your AI agent "what does a Google L5 engineer make in NYC?" and get real Levels.fyi submissions back, structured.

Config: https://mcp.apify.com/?tools=bovi/levels-fyi-scraper

Integrations

Built for recruiters benchmarking offers, HR teams building comp bands, and job-seekers negotiating tech pay by level and location — 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.

Legal

Levels.fyi salary data is publicly accessible (no login required). This actor fetches only the same data visible to any web browser on the publicly accessible pages. Users are responsible for compliance with Levels.fyi's Terms of Service and applicable laws in their jurisdiction.

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.