H-1B Data API: Pull Sponsorship Records by Employer

Get H-1B sponsorship records as data, with the employer, role, city and wage on each row. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to pull the first page of H-1B sponsorship records for 2025 and give me a table of employers with how many filings each has on the page, their most common job title, and the wage range.

One prompt turns a page of filings into an employer table. 1 min setup · 8-20 hrs saved.

You want to know which companies sponsor H-1B visas, for which roles and in which cities, and you want it as rows you can filter, not a search box you click through. That means job seekers building a target list, recruiters sizing a hiring market and sales teams looking for companies that are hiring. This guide shows how to pull the filings as JSON from your agent, what came back when we ran it on 2026-10-16, and the cleanup that decides whether an employer table is right. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to get H-1B data through an API?

Monid. Install it once, add a key, and your agent asks for a year and a page number and gets the sponsorship records back as typed JSON, with no data contract and no bulk files to parse.

• Pay per call. One page of records is $0.01 (Verified 2026-10-16 on the labor data tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every source. The same key and balance reach the H-1B endpoint, a free company-name-to-domain lookup and every other tool on Monid. Records, employer identity and company profile are three calls on one balance, not three vendors.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tool is there whenever your agent needs a sponsorship check, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

Pulling one page cost $0.01, and the last page of the year cost the same (Verified 2026-10-16).

How do you pull H-1B sponsorship records for a whole year?

Call the H-1B endpoint with a year and a page, read the page count from the first response, and loop. The endpoint is /get_h1b_salaries on the provider levels.fyi. Both parameters are integers, and the first page is 1.

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

Pull a page

monid run -p levels.fyi -e /get_h1b_salaries --query '{"year": 2025, "page": 1}'

The response carries totalRecords and totalPages beside the rows. For 2025 they were 549,133 and 5,492, which is 100 rows a page, with 33 rows on the last one. Read totalPages first and size the job from it: every page is a billed call, so all 5,492 pages of one year come to about $54.92 (Verified 2026-10-16), and most employer research needs a fraction of that.

Loop over pages

Write one file per page, here the first twenty:

mkdir -p h1b
for p in $(seq 1 20); do
  monid run -p levels.fyi -e /get_h1b_salaries --query "{\"year\": 2025, \"page\": $p}" -w -o "h1b/2025-$p.json"
done

Each page is one billed call, so the loop above costs twenty times the per-page price.

Or hand the whole job to an agent

📖 See also Salary Data API: Pay by Company, Job Title and H-1B Filing

Can you get H-1B data without an API, from a download or a scraper?

Yes. Sponsorship filings are published as disclosure records, so you can work from bulk files or from a site that indexes them, and for a one-off look at a single employer a search box is faster than any code. The rules on how you may use public records and personal data differ by country and by use, so check yours before you build outreach on them.

What the other routes cost is your time:

The work in bulk files is not the download. It is column names that change between years, job titles typed by hand, and employer names with no shared identifier, which is the same work in every route. Monid removes the parsing and paging, and the cleanup section below is what is left for you.

📖 See also B2B Data Provider: Dataset or API?

What does an H-1B sponsorship record look like, and what can you build with it?

A record is one filing: who files, for what role, where, at what wage and with what outcome. We pulled the first and last pages of 2025 on 2026-10-16, so the keys below are what came back.

The fields

The status was Certified on nearly every row, with Certified - Withdrawn on a few (PlayStation and Elevance Health on page one, a University of Georgia row on the last page). The et letters on page one were E, P, C, A, N and X. The endpoint does not explain the letters, hd or the level numerals, so store them as they arrive.

What you can build with it

• A sponsor shortlist. Group a pull by c and count filings, then keep employers with several in your occupation and city. A filing is a record of a past sponsorship, not a promise about the next hire, so treat the list as a place to start.
• A hiring signal for sales. A company that files in a city for a role category was hiring that role. That is a lead signal with a lag, and it pairs with live job postings, which show the openings that exist now.
• A wage benchmark by role and city. Take w for one j and ct and read the spread. The wage on a row is the figure on the filing, not what the person is paid in the end.
• An enriched employer table. Resolve each name to a domain, then pull the company profile: headcount, industry code and location beside the filing count.

What goes wrong when you group H-1B records by employer?

Six things showed up in two pages, and each decides whether your employer counts are right.

Why is page one not the top of the year?

Because the endpoint orders by begin date first and by wage second. Every row on page one had a begin date of Dec 31, 2025, and the wages ran down from 1,939,644 to 192,500. The last page was the mirror image: every row began on Jan 01, 2025, with wages from 45,290 down to 25,605. Page one is the latest begin date sorted by wage, not the best-paid hundred filings of the year, and a "top wages" chart built from it measures one day. To sample a year, pick pages across the range.

Why does a top wage need a sanity check?

The first row on page one was a React Developer at level II on 1,939,644, and the second was a Java developer at the same employer on 1,602,432, with the same begin and decision dates. Both are far above the next row, 445,000. The filing is published as it was typed, so use a median, drop the extremes, and say you did.

Why do the same records appear twice?

Some filings repeat. The last page held four identical rows for an accountant at Core Tech Construction in Tamuning, GU, wage 39,600, with the same decision date, and page one listed a Microsoft Customer Experience Engineering role in Redmond at 218,805 twice. Count filings with the duplicates in if the question is "how many", and collapse identical rows if it is "how many roles".

Why is one employer spelled several ways?

Because the name is whatever was typed, then title-cased. Page one has Amazon, Amazon Web Services and Amazon Development Center U.s, and also Citadel Securities Americas Services next to Citadel Americas Services, and two TikTok entities. Group by a cleaned name, or by parent, and decide up front whether subsidiaries count as one employer.

Why should you not join on the domain field?

Because it is only sometimes a real domain. Google, Microsoft and NVIDIA rows carry google.com, microsoft.com and nvidia.com. Others are the name with the spaces removed plus .com: cloudsocialtechnologies.com and a 52-letter version of Gunderson Dettmer's name. A DNS lookup on both returned no address on 2026-10-16, and a company profile call on cloudsocialtechnologies.com answered 404 and cost nothing (Verified 2026-10-16).

Resolve the name yourself with the free hunterio/domain-finder:

monid run -p hunterio -e /domain-finder --query '{"company": "Gunderson Dettmer", "limit": 4}' -w

It ranked gunder.com first with 291 indexed emails, ahead of three candidates with 1, 0 and 0. A profile call on gunder.com then returned the firm in Redwood City, California, with 769 employees, for $0.0049 (Verified 2026-10-16). The finder gives candidates, not certainty: for Cloud Social Technologies it returned three domains with 2, 7 and 90 emails and none was clearly the employer. Use the city and state on the filing to confirm, and skip any employer you cannot confirm. Looking a company up by name covers that matching step.

Why is the data messy at the edges?

City and state can disagree: a Robinhood row on page one had New York with state CA, and PlayStation's city came back as "San Fransisco". Level was null on several rows, and a physical therapy aide on the last page carried level IV at 41,662. Treat location and level as hints and the employer, title and wage as the core.

Which endpoint should I use for which job?

The first row is the dataset, the second repairs the employer identity and the third enriches it. Inspect any of them for free with monid inspect -p levels.fyi -e /get_h1b_salaries, and see current prices on monid.ai/tools.

📖 See also Hunter.io API: Domain Search vs Email Finder

When is another route a better fit?

You need every filing. At 100 rows a page, a whole year is 5,492 calls. If you want all of them for a one-time analysis, a bulk file is cheaper in money and worse in parsing time, so weigh the two.

You need to know whether a company will sponsor you. A record shows that an employer filed for a role in the past. It says nothing about a current opening or a hiring decision, so confirm on the company's own job post, and ask an immigration professional about your own case.

You need individuals. There are none here. The rows are employer, role, place and wage.

You need the meaning of every code. The endpoint does not document the employment type letters, hd or the level numerals. If your analysis rests on them, decode them from the underlying filing form first.

And the disclosure: this is Monid's blog and we resell this endpoint. The most useful advice here is to drop the domain field and clean the employer name, and that costs us nothing.

Conclusion

The quickest way to get H-1B sponsorship records as data is one call per page through Monid: $0.01 a page (Verified 2026-10-16), one key for this and every other tool, about a minute to set up and ready inside your agent whenever you need it. Bulk files cost nothing to download and hours to parse; Monid keeps the paging and typing out of your way.

Two things matter more than the endpoint. Page one is a single begin date sorted by wage, so sample across the pages before you describe a year. And an employer table is only as good as the name behind it: collapse duplicates and spelling variants, and replace the domain field with a resolved one.

How we estimated the time saved: finding, downloading and parsing the yearly bulk files into one table is roughly 4 to 8 hours, and matching employer names to real domains and cleaning the variants is another 4 to 12 hours. That is 8 to 20 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p levels.fyi -e /get_h1b_salaries, then pull one page and group it by employer yourself. Start at monid.ai.

FAQ

Published September 2026.