DEV Community: Radar Labs

Six APIs, zero keys: what 18,825 real job postings contain

Radar Labs — Thu, 22 Oct 2026 21:27:25 +0000

I wanted a job feed I could filter myself, so I tried to fetch one from the source instead of the aggregators. It turns out that most company career pages are thin wrappers around a handful of applicant tracking systems (ATS), and those systems expose JSON endpoints without keys or login.

Six of them answered. I guessed 527 plausible company slugs, 259 responded, and that produced 18,825 real job postings. Here is what I found in them — including two bugs that silently published numbers that were off by two orders of magnitude.

The six endpoints

ATS	Endpoint	Auth
Greenhouse	`boards-api.greenhouse.io/v1/boards/{slug}/jobs`	none
Lever	`api.lever.co/v0/postings/{slug}?mode=json`	none
Ashby	`api.ashbyhq.com/posting-api/job-board/{slug}`	none (add `?includeCompensation=true` for pay)
Workable	`apply.workable.com/api/v1/widget/accounts/{slug}`	none
Personio	`{slug}.jobs.personio.de/xml`	none
Workday	`POST {tenant}.wd{N}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs`	none

All public, all read-only, none of them need an account. Some have changed shape or disappeared: SmartRecruiters returned 404 on both endpoints I tried, and Teamtailor customers usually sit behind their own domain so the documented JSON path just 404s.

Workday is the awkward one. It needs a tenant, a cluster number and a site name before you can address a board at all, and guessing is close to hopeless: 24 well-known companies × 2 clusters × 4 site names = 192 probes, exactly one hit. Everything else had to be supplied by hand.

What a sweep returns

18,825 postings from 259 companies (49% of guessed slugs)
8,071 with a published salary (43%) — but that number only exists because of the mistake below, which is the most interesting thing I learned

Finding 1: I was wrong about Greenhouse

My first sweep looked like this:

ATS	Companies	Postings	With salary
Greenhouse	135	11,608	50
Ashby	98	5,274	2,734
Lever	23	1,810	160
Workable	4	121	0

93% of every salary-bearing row came from Ashby. Greenhouse had the volume and essentially no pay, so the obvious conclusion was "Greenhouse doesn't publish salaries".

That conclusion was wrong, and the reason is that I was asking for the wrong payload. ?content=false returns postings with the metadata array set to null for all of them. Ask for ?content=true and the pay range is sitting right there in the description text — 44% of Greenhouse postings have one.

ATS	Companies	Postings	With salary
Greenhouse	134	11,619	5,164 (44%)
Ashby	98	5,283	2,739 (52%)
Lever	23	1,802	168 (9%)
Workable	4	121	0

The trap is that Greenhouse's content field is double-escaped HTML: the description literally contains <div class="content-intro">. One html.unescape is not enough. If you unescape once and search for $, you find nothing and conclude there is no salary. You need to unescape until the string stops changing (I cap it at three rounds).

Finding 2: Ashby hides its compensation behind one flag

Ashby returns beautiful structured compensation — compensationTiers, summaryComponents with minValue, maxValue, currencyCode, interval — but only when you pass ?includeCompensation=true. Without the flag you get a gorgeous list of jobs and zero numbers. Same failure mode as Greenhouse, different cause: the API is right, the request is wrong.

Finding 3: the $1,536,000 ghost

Lever returns structured ranges:

{"min": 128000, "max": 176000, "currency": "USD", "interval": "per-month-salary"}

That is a monthly salary — in a Latin American band — labeled USD. Annualise it and you get $1,536,000 for a DevOps engineer. It briefly topped the entire scan and looked completely legitimate, because it was a well-formed number in a well-formed field.

Then this one, from a long Greenhouse description:

The base salary range is 210,000 USD - 310,000 USD. Some hourly employees exist.

The word "hourly" appears somewhere in the text, so my annualiser multiplied an annual range by 2,080 and produced $436,800,000.

Both bugs share a shape: the output was plausible. A range that is off by 12× or 2,080× does not look broken; it looks like a senior role at a rich company.

I stopped trying to repair these and started deleting them. Anything that annualises below $5,000, above $5,000,000, or above $1,500,000 in USD loses its salary fields entirely while the posting stays. And the unit words are only read from the ~40 characters after the last number in the sentence, not from the whole description:

def _unit_tail(window, limit=40):
    # "…210,000 USD - 310,000 USD. Some hourly employees exist."
    # -> only look at " USD." , so "hourly" later in the text cannot fire

Since then the maximum salary in a full sweep is $850,000, which belongs to the posting it is attached to.

Lesson: in a data product, one wrong order of magnitude is worse than one missing field.

Finding 4: the pay range is not always a number

American postings often write the currency after each number:

The base salary range is 196,000 USD - 310,500 USD.

My regex was built for $196,000 - $310,500, so it matched the first number plus "USD", stopped, and produced 196000 - 196000. The output looked perfect — a single plausible number — which is exactly the kind of bug that ships. You need a separate pattern for number currency - number currency, and you need to decide what to do about postings that list several bands (… for Level 4, and … for Level 5); I take the first band and say so in the docs.

Finding 5: dedupe and "only new" are the real features

Large companies post the same role on several boards, so a raw sweep duplicates heavily: 18,825 rows collapsed to 15,528. And if you (or your users) pay per row, the feature everyone actually wants is "only the postings I have not seen yet" — which needs a stable fingerprint per posting plus somewhere to persist the seen set. Mine is company + normalised title + url, hashed, stored in a key-value store, capped at 50k entries, FIFO.

The normalisation detail that matters: strip punctuation and case, but do not strip location qualifiers. Engineer (Remote) and Engineer (Berlin) are different jobs.

If you want to try this yourself

Do not trust labels, tags or category counts — measure the payload.
Ask for compensation explicitly (Ashby), and fall back to reading the description (Greenhouse, Workday).
Guard every annualisation with a plausibility bound, and drop rather than repair.
Deduplicate on company + normalised title + url, never on title alone.
Store a fingerprint per posting if you want incremental results.

Honest limits

Slug guessing worked 49% of the time. Workable boards often answer with an empty shell. Some postings are evergreen and never close, so "new" is fuzzy at the edges. Salary only exists when a company chooses to publish it — 43% of rows here, not 100%. And a wrong number is worse than a missing one, so I drop aggressively and tell users when a company returned nothing.

I packaged this as a small tool that scans the six APIs, normalises salaries to annual USD, dedupes across boards and can return only new postings: ATS Job Feed. It ships the list of 259 companies that were verified live, so you do not have to guess slugs, and it can return only postings that actually state a salary.

If you pull job data for a living: which of these six APIs has bitten you the hardest? I would like to know which shape I should handle next.

I built a job-lead radar because the job boards I tried returned garbage

Radar Labs — Wed, 21 Oct 2026 19:29:02 +0000

Solo developers don't have a finding-work problem. They have a filtering problem. I spent a week measuring exactly how bad the filtering is, then built a small tool around the answer. Every number below comes from my own runs in October 2026.

The noise, measured

GitHub bounties. I pulled open issues labelled bounty: 4,640 of them. In the 200 most recently created, exactly 4 carried a dollar figure, and 191 came from a single repository that opens issues in bulk. Sampling 298 issues from the bigger bounty label pool, 208 had a price and the median was 5 dollars (p25 3, p75 7, max 750). Roughly two thirds of that sample came from one account.

Hacker News. The monthly Freelancer? Seeking freelancer? thread is half people looking for work, not posting it. In the October 2026 thread, 21 of the top-level comments were resumes. Salaried postings are a separate problem: if you rank them together, a 200k-a-year role crowds out every contract gig, because no single project will ever outbid an annual salary.

Freelancer.com. Wide open API and a trap: most listings are priced in rupees. My first version ranked a 1,500 INR project as if it were 1,500 USD. It sat at the top of the list for an hour before I noticed.

Three mistakes I made, and the fix

1. A 248,400 dollar lead that was not a lead. Top of my ranking one morning was a GitHub pull request titled Add researched paid bug bounty target list, whose body said: total advertised value 230,000 EUR across 214 programs. My parser saw a currency symbol and a number. Now a price only counts if a bounty-ish word (bounty, reward, budget, payout, prize) sits within 60 characters of it, and aggregate words (total, across, combined, median, pool) disqualify the match outright. Both rules came from that one failure.

2. Treating a bounty range as a price. Programs publish a range, for example 500 to 30,000. Taking the top put a 248,000 dollar project at number one; taking the bottom pushed good programs under 20 dollar bounties. The geometric mean of the two ends is a much better estimate of what a program actually pays, so that is what I use, and the output marks it as an estimate.

3. Filtering by date on things that never expire. Bounty programs stay open for months. A 21-day recency window deleted almost all of them. Recency now only applies to sources where it means something.

The rules that survived

Effort matters more than payout. A 5,000 dollar project that needs a 40-hour full-stack build is not better than a 400 dollar one that takes four hours, so every lead gets an effort estimate from its text and the ranking is dollars per hour, not dollars.

Deduplication matters. The same job gets reposted across sources, so titles are normalized before ranking and the most valuable copy survives.

And the output says what it threw away. The run summary is always three numbers: how many items were scraped, how many survived filtering, how many were returned. When a source starts returning junk, the middle number tells you before the list does.

What it does not do

It does not bid on anything. Every platform's terms forbid automated bidding, and a bot-written proposal loses to a human one. It does not send messages and it does not guarantee a lead is still open, so check before you quote.

Coverage is five sources: GitHub bounties, two Hacker News monthly threads, Freelancer.com, YesWeHack programs, and Remotive for remote roles. No Chinese platforms yet. The Freelancer.com endpoint rate-limits after a couple of minutes of hammering, so that one source alone takes about 90 seconds.

Where it lives

It runs as a hosted Actor on Apify, so there is nothing to install and nothing to keep alive:

https://apify.com/contributory_garnet_hyz/freelance-lead-radar

Pricing is per lead returned plus a small per-run start charge. Filtered-out noise is not billed. A default run returns 25 leads, which comes to about 38 cents.

What I would like to know

The scoring weights are the part I am least sure about: payout 42 percent, ease 22 percent, skill fit 21 percent, freshness 9 percent, competition 6 percent. If you have built a similar filter for your own work search, what would you weight differently? I would rather change the weights than keep guessing.

Follow-up: I later went to the source of these postings — 527 company career pages, six public ATS APIs, 18,825 real postings — and found that two of my salary numbers were off by 12× and 2,080×. That write-up is here: Six APIs, zero keys: what 18,825 real job postings contain.