Salary Data API: Three Sources, Three Different Numbers
Indeed says the median software engineer earns 136k. Levels.fyi says 298k. Both are right, and the field that explains it is the sample count.
Copy this line to your agent to pull compensation data for a company and role.
set up https://monid.ai/SKILL.md and use levels.fyi /get_salary_data with a company slug
On 2026-09-08 we asked three endpoints what a software engineer earns. Indeed returned a national median of 135,988 dollars. Levels.fyi returned a base salary median of 200,000 for Google engineers and a total compensation median of 298,000 for the same people. Certified H-1B filings for 2025 had a page-one median of 220,504. Every one of those numbers is accurate, and a pipeline that keeps any single one of them as "the salary" has discarded the part that made it mean something. This guide runs through Monid, the OpenRouter for agent tools.
What is actually in a salary API response?
Never a number. Always a distribution, a population and a definition, and the number is what falls out once you fix all three.
The percentile block
levels.fyi/get_salary_data for Google software engineers returned percentiles split four ways:
{
"base_salary": { "p10": 150000, "p25": 167000, "p50": 200000, "p75": 220000, "p90": 250000 },
"tc": { "p10": 175000, "p25": 207000, "p50": 298000, "p75": 397800, "p90": 496000 },
"bonus": { "p10": 0, "p25": 0, "p50": 23000, "p75": 37800, "p90": 46000 },
"stock_grant": { "p10": 25000, "p25": 40000, "p50": 75000, "p75": 140000, "p90": 200000 },
"locationName": "United States"
}
Read the two p50 rows against each other. Base is 200,000 and total is 298,000, so salary is about two thirds of what the job pays. Read the p90 rows and the gap widens: 250,000 against 496,000. The higher the level, the less of the compensation is salary, because the stock grant grows faster than the base does.
The per-level breakdown
Alongside the percentiles came an averages array with one entry per level, L3 through L9, each carrying base, stock, bonus, total, yoeAvg, yoeMedian and two separate counts. The counts turn out to be the load-bearing fields, and they get their own section below.
The aggregate shape from a job-title source
indeed/get_salary_info answers a different question and returns a different structure: a title normalisation block, a location block, a national aggregate, a state-by-state salary map, top paying cities, top paying companies, and a salaries object holding five pay periods. It is not company-specific and does not try to be.
The record shape from a filing source
levels.fyi/get_h1b_salaries returns neither of those. It returns rows: company, domain, job title, occupational category, wage, level, city, state, year, certification status and the filing dates. On 2026-09-08 the 2025 set held 549,133 records across 5,492 pages. This is raw material rather than a summary, which makes it the only one of the three where you get to define the population yourself. Working from records rather than a vendor aggregate is the same move made in PDL vs Akta on per-record cost.
📖 See also Job Postings API: Turning Hiring Into a Buying Signal
Why do three sources give three different numbers?
Because they are measuring four different populations, and the word "salary" means something different in each one.
The four numbers, side by side
| What was asked | Source | The number | What it measures |
|---|---|---|---|
| Software Engineer, United States | indeed/get_salary_info | 135,988 median | Self-reported and posting-derived pay, all employers, all levels |
| Google Software Engineer, base | levels.fyi/get_salary_data | 200,000 p50 | One employer, cash salary only |
| Google Software Engineer, total | levels.fyi/get_salary_data | 298,000 p50 | The same people, cash plus stock plus bonus |
| Certified H-1B filings, 2025 | levels.fyi/get_h1b_salaries | 220,504 page-one median | Legally attested wages for sponsored roles |
The spread from 135,988 to 298,000 is not disagreement. It is four honest answers to four different questions that happen to share a job title.
Why the national figure sits lowest
Indeed's population is every employer that posts a role or has pay reported against it, which is overwhelmingly companies that are not Google. A national median mixes a two-person agency in Ohio with a public company in Mountain View, and the median of that mixture answers "what does this job pay in general".
Why the filing figure sits in the middle
H-1B wages are filed for a specific role at a specific employer and are legally attested, so per-record quality is high. But the population is people being sponsored for a visa, which skews toward larger employers and technical roles and excludes everyone who did not need sponsorship.
The rule this produces
Match the population before you compare the number. Benchmarking an offer against a national median makes almost every large-company offer look generous, and benchmarking a small-company offer against levels.fyi makes it look insulting. It is the same class of error as reading a price without its list price beside it, which we measured in the price monitoring guide.
How do you pull compensation data?
Three steps, and discovery is free.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Get the company and level view
What it does. Returns percentiles and a per-level breakdown for one employer.
The endpoints. levels.fyi/get_salary_data, billed per call, requires company_slug.
The call.
monid run -p levels.fyi -e /get_salary_data \
--query '{"company_slug": "google", "job_family_slug": "software-engineer"}'
What comes back. percentiles for base, total, bonus and stock, plus averages with one row per level and two sample counts on each.
What it costs. About a cent per call. Current figures at monid.ai/tools.
Step 2. Get the market view for a title
What it does. Answers what a title pays in general, and where.
The endpoints. indeed/get_salary_info, per call, requires job_title.
The call.
monid run -p indeed -e /get_salary_info \
--query '{"job_title": "Software Engineer", "location": "Austin TX"}'
What comes back. A national and a local aggregate, a state map, top paying cities and companies, and five pay periods. Read the next section before you use four of those five.
What it costs. The same order, per call.
Step 3. Get the rows and compute it yourself
What it does. Hands you filings rather than a summary, so the population is yours to define.
The endpoints. levels.fyi/get_h1b_salaries, per call, with year and page both optional.
The call.
monid run -p levels.fyi -e /get_h1b_salaries --query '{"year": 2025, "page": 1}'
What comes back. 100 rows per page and 5,492 pages for 2025, sorted by date descending. Sorted by date, not by wage, which matters for the reason two sections down.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to pull the first ten pages of 2025 H-1B salary records, drop anything above 600000, and give me the median by job title.📖 See also Extracting Leadership Contact Information Without Paying to Look
Which field tells you the number is real?
The sample count, every time. It is the field most often dropped on the way into a database and the only one that says whether the figure above it means anything.
Four of five periods had nothing behind them
Indeed returns the same pay in five periods. Here is what each carried on 2026-09-08:
| Period | Median | numDataPoints | inferred |
|---|---|---|---|
| Yearly | 135,988.38 | 39,617 | false |
| Monthly | 9,628.20 | 0 | false |
| Weekly | 2,488.13 | 0 | false |
| Daily | 604.36 | 0 | false |
| Hourly | 58.39 | 0 | false |
Only the yearly figure was measured. The other four were produced by dividing it, and the response says so in salaryMultipliers: the yearly multiplier is 2,328.845783089349. That is the implied count of paid hours in a year, and it is not 2,080, so converting the hourly figure back by hand gives a different answer than the yearly figure does.
The flag that should have warned you is wrong. inferred reads false on all five rows, including the four with no observations. The count is the honest field and the boolean is not.
A level with no recent samples still reports a salary
In the levels.fyi response the L9 row carried count: 5 and count_last_12_months: 0. So the figure shown for the most senior level rests on five submissions, none of them from the past year. L3 by comparison had 1,085 in the last twelve months.
The top paying company was ranked on two records
The first entry in Indeed's topPayingCompanies for United States software engineers was Xebia IT Architects India Pvt. Ltd, with salary.main reading {"type": "MONTHLY", "mean": 35000, "count": 2}.
Two records, a monthly period, and an entity whose pay is very unlikely to be denominated in dollars. It sits at the top of a ranked list and it is noise. The same failure runs through follower and engagement data, measured in the engagement tracker post.
One certified filing said 1.94 million dollars
The highest wage on page one of the 2025 H-1B set was 1,939,644 dollars, for a role titled "React Developer" at level II, with cs: "Certified".
That is a real filing with a certified status. It is also, self-evidently, not an annual React developer salary. Whatever produced it, a period error or a data-entry artifact, it survived certification and it is in the dataset. Because the endpoint sorts by date rather than by wage, you will not meet it at the top of a list. You will meet it in your average.
CAP = 600_000
clean = [r for r in rows if 30_000 < r["w"] < CAP]
A crude cap is the right first move, and it belongs in your code rather than in your trust of the source.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
levels.fyi/get_salary_data | One employer, by level | company_slug | Percentiles plus per-level averages | Benchmarking against a named competitor | Per call |
levels.fyi/get_salary_summary_md | The same view as Markdown | company_slug | A prose summary | Handing straight to a model | Per call |
indeed/get_salary_info | A title across the market | job_title | National and local aggregates, state map | Pricing a role you are about to post | Per call |
levels.fyi/get_h1b_salaries | Filed wage records | year, page | 100 rows per page | Recomputing on your own population | Per call |
web3.career/get_web3_salaries | One vertical | none | Averages by role | A niche the general sources under-cover | Per call |
Every row was verified with monid inspect on 2026-09-08. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
All five bill per call rather than per record, which is unusual in this catalog and worth knowing: a hundred pages of filings cost the same per page as one page, so the constraint is time rather than volume. That is the opposite of the per-result endpoints discussed in not depending on one scraping vendor.
When is salary data the wrong input?
Four cases, and the first is the common one.
You are setting one person's pay. These are market distributions, not an entitlement calculation. A percentile describes a population and says nothing about an individual's performance, tenure or leverage.
You need statutory or regulated pay data. Prevailing wage determinations, union scales and public-sector bands come from official registers with legal force. Anything derived from self-reporting is evidence about a market, not compliance with a rule.
Your population is not represented. Every source here is heavily United States and heavily technical. Non-technical roles, small employers and most countries outside the US are thin to absent, and the fragmentation looks much like the one described in business entity search.
You need it current to the week. H-1B filings arrive on a certification cycle, levels.fyi accumulates submissions over time, and Indeed's aggregate carried a lastUpdateTimestamp of 2026-08-31 when we called it on 2026-09-08. All three are recent and none is live.
And the disclosure: this is Monid's blog and we sell per-call access to these endpoints. The argument here is that you should call more than one of them and keep the counts, which is not much of a pitch for volume. If you need a single national median for a single title once, the free public pages on any of these sites will give it to you.
Conclusion
There is no single salary number, and "what does this job pay" stays malformed until you name the employer, the components and the population. Indeed's 135,988 and levels.fyi's 298,000 differ by about 160,000 dollars and neither is an error; they answer different questions asked on the same morning.
What matters more than choosing a source is keeping the metadata that arrived with it. numDataPoints, count_last_12_months and the certification status are what let you tell a measured figure from a derived one, and they are the first fields dropped when a response is flattened into a table. A pipeline that stores the median and discards the count has stored a number nobody can audit later, including you.
Free next step: run monid inspect -p indeed -e /get_salary_info to read the schema without spending anything, then make one call and look at numDataPoints across the five periods. It is the fastest demonstration of the point in this article. Start at monid.ai.
FAQ
Can you trust self-reported salary data?
For direction and shape yes, and for a specific figure at a specific level treat it as one input among several. Self-reported datasets carry a well-known upward bias, because people with unusually good outcomes are the most motivated to submit them, and the effect is strongest at senior levels where the samples are smallest. The practical defence is the one this article keeps returning to: read the sample count attached to the row before you use it, and prefer a level with a thousand recent submissions to one with five.
Should I benchmark against base salary or total compensation?
Against whatever your own offer actually contains, which for most companies is base plus bonus and not much else. Comparing an all-cash offer against a total compensation percentile that is one third equity will tell you that you are far below market when you may not be, and comparing against base alone at a company that pays heavily in stock tells you the opposite. The levels.fyi response returns base_salary, bonus and stock_grant as separate percentile sets precisely so you can rebuild a comparable figure rather than accepting theirs.
Where does H-1B salary data come from?
From the Labor Condition Application that a US employer files before sponsoring an H-1B worker, which states the offered wage, the job title, the worksite and the period. The Department of Labor publishes the disclosure data, so this is public record rather than anything leaked, and the endpoint is a structured view over it. The wage is what the employer attested it would pay, which is not necessarily what was paid, and it excludes bonus and equity entirely, so it reads low against a total compensation figure for the same role.
Does any of this cover countries outside the United States?
Only thinly. Levels.fyi accepts a location filter that includes country codes and Indeed operates in many markets, but depth outside the United States drops sharply and the H-1B set is US-only by definition. If your population is European or Asian, expect small samples and check numDataPoints before drawing any conclusion at all. It is the same coverage cliff described in the PitchBook guide.
Last updated September 2026.
