Yes, but not the way you'd expect from Hacker News, Reddit, or Twitter. LinkedIn has no free, self-serve public API for job search data. Every route into it, LinkedIn's own Talent Solutions and Marketing Developer Platform APIs, requires approval as an official partner, an application process with no published timeline and no guarantee of acceptance. There's no equivalent of Algolia's public search index or a Firebase tree you can curl without a key.
That gap is what makes LinkedIn a genuinely different case than the last time I ran this kind of test. A few days ago I pulled all 276 posts from Hacker News's July "Who is hiring" thread through a structured parser and reported what broke. Someone pointed out, fairly, that HN already publishes a free public API, so anyone motivated enough could rebuild that parser themselves in an afternoon. LinkedIn doesn't offer that option. If you want LinkedIn job data as structured fields instead of raw HTML, you're either applying for partner access and waiting, or you're going through a third-party API. So I ran the same experiment on Social Fetch's LinkedIn jobs endpoint: a real pull, real numbers, and an honest account of where structured extraction still falls apart.
How was this data sampled?
I ran 13 separate searches against Social Fetch's linkedin.jobs.search endpoint on August 4, 2026, all scoped to the United States and to postings from the past month, and combined the results into one deduplicated set. Six searches used the keyword "software engineer" and each of LinkedIn's six experience-level filters (internship, entry-level, associate, mid-senior-level, director, executive). Three more used the same keyword split across LinkedIn's three work-arrangement filters (on-site, hybrid, remote). The last four covered "sales development representative," "account executive," and "data scientist," to pull in some non-engineering roles given that a meaningful share of Social Fetch's own LinkedIn-data users are sales and GTM tooling builders, not just developers.
That's 130 raw postings before dedup. After removing postings that showed up in more than one of the 13 searches, 90 unique job listings remained. This is a stratified sample built around one core keyword, not a random draw from LinkedIn's full job market, so treat percentages below as directional for "how a batch of real US software engineering and GTM postings looks in early August 2026," not as a market-wide census.
How much LinkedIn job data actually extracts cleanly?
| Signal | Count | Share of 90 |
|---|---|---|
Structured salary field populated (baseSalary) |
18 | 20.0% |
| Dollar figure present in free-text description, no structured salary | 42 | 46.7% |
| Any real salary signal (structured or in prose) | 60 | 66.7% |
| Full-time | 81 | 90.0% |
| "Easy Apply" listing | 31 | 34.4% |
| Mentions agent, agentic, LLM, generative AI, or ML | 40 | 44.4% |
applicantCount returned as exactly 0 |
61 | 67.8% |
jobPoster (named recruiter) present |
7 | 7.8% |
| Same company, same title, different city, posted separately | 12 | 13.3% |
The headline number here is the salary one. Only 18 of 90 postings (20.0%) populate the API's structured baseSalary field, the one built for pulling a clean number out without touching free text. But 42 more of the remaining 72 postings (58.3% of that group) state a specific dollar figure somewhere in the plain-text job description anyway, meaning a company disclosed pay but LinkedIn didn't put it in a field a script can read directly. Add those together and 60 of 90 postings (66.7%) actually contain real salary information, more than three times what the structured field alone would tell you. If you're building anything that reports "how many jobs disclose salary," reading the description text isn't optional; the field built for it misses most of the real answer.
Where does structured extraction break?
Ambiguous "OTE" language, not a missing field. An Account Executive posting from Marcus Evans Group has baseSalary: null, but its description reads: "Account Executives earn 8%-10% commission on sales, with average deals ranging from $35k-$90k for entry relationships and $150k-$250k on repeat relationships. After a 3-month training program: $74,000 minimum earnings with $90,000-$120,000 OTE for your first year." (job ID 4386539357) There are three different numbers here, a guaranteed minimum, an on-target-earnings range, and a commission-driven deal-size range, and no field distinguishes which one a script should treat as "the salary." A parser has to choose, and any choice it makes is defensible and also wrong for some fraction of readers.
A location field that doesn't match the work-arrangement filter. I ran the same search filtered to remote: "remote" and one result was a Software Engineer 1 posting from Tebra with location: "Corona del Mar, CA" (job ID 4446376378). Its description never uses the word "remote" at all. LinkedIn's remote/hybrid/on-site tag is set through a separate control at posting time, and this API's response doesn't expose it as its own field, so the only place you'd expect to find that information, the location string or the description text, simply doesn't have it for this listing. A script that infers work arrangement from location alone would file this job as on-site despite LinkedIn's own filter classifying it as remote.
The same opening posted once per city. SpotHopper has two listings titled exactly "Account Executive," one based in Tucson, AZ (job ID 4447872890) and one in Wichita, KS (job ID 4447869380), each with its own job ID and URL. Google has two "Software Engineer" postings, one in Sunnyvale and one in Mountain View, and Starbucks, Meta, and LinkedIn itself each have a matching pair split only by city. Across the 90-listing sample, 12 postings (13.3%) are one of these same-company, same-title, different-city pairs. Deduplicating by job ID, which is what a script naturally does, keeps all of them as distinct jobs; deduplicating by title and company would incorrectly collapse genuinely separate openings in different cities into one.
Hourly rates mixed in with annual ones. Of the 18 postings with a structured baseSalary, 16 report an annual figure and 2 report an hourly rate ($65-$75/hr for a Data Scientist recruiting listing, $50-$60/hr for a Technical Recruiter role). The API does return a paymentPeriod field alongside the number, so this one is actually solvable, but only if the code reading the response checks it. A script that assumes every baseSalary is annual will read a $50-$60/hr contract role as a $50-$60/year one.
Can this kind of extraction ever be perfectly clean?
No, and the reason isn't that AI-assisted parsing is hard in the abstract. It's that a chunk of the information a script needs, which of three dollar figures is the real offer, whether "remote" in a filter result also means "remote" in practice, whether two same-titled postings are duplicates or genuinely separate roles, is not represented in the data at all. No amount of better parsing recovers a value the source never encoded. What structured extraction can do is get everything that is represented (title, company, structured salary field when present, employment type, seniority tier) reliably, flag the cases where a human read of the description is the only way to resolve an ambiguity, and not silently guess. The 66.7% total salary-disclosure figure above only exists because we read the free text in addition to the structured field; a script that trusted the field alone would have undercounted disclosure by more than three to one.
Is there a structured API for LinkedIn job postings specifically?
Yes. Social Fetch's /v1/linkedin/jobs/search endpoint returns LinkedIn job listings as typed JSON, title, company, location, seniority level, employment type, structured salary where LinkedIn provides one, and the full plain-text description, searchable by keyword, location, experience level, job type, remote/hybrid/on-site, and posting date.
curl "https://api.socialfetch.dev/v1/linkedin/jobs/search?keyword=software engineer&location=San Francisco" \
-H "x-api-key: YOUR_API_KEY"
import { SocialFetchClient } from "@socialfetch/sdk";
const client = new SocialFetchClient({
apiKey: process.env.SOCIALFETCH_API_KEY!,
});
const result = await client.linkedin.searchJobs({
keyword: "software engineer",
location: "San Francisco",
});
if (!result.ok) {
console.error(result.error.code, result.error.requestId);
} else {
console.log(result.value.data.jobs);
}
Every field name and example in this piece, the endpoint path, the query parameters, the response schema, the credit cost, the curl and SDK examples, came directly from Social Fetch's own docs, verified against the live documentation page rather than assumed from memory.
Quick answers
Does LinkedIn have a free, official public API for job search data? No. Access to LinkedIn's job and profile data requires approval through LinkedIn's Talent Solutions or Marketing Developer Platform partner programs; there's no self-serve key and no open equivalent of Hacker News's Firebase or Algolia APIs.
Is there a structured, self-serve API that returns LinkedIn job postings as clean fields? Yes. Social Fetch's linkedin.searchJobs endpoint takes a keyword and location and returns typed job records (title, company, location, seniority, employment type, salary where available, full description) without requiring LinkedIn partner approval.
How much LinkedIn job data actually discloses salary? Across 90 real US job postings sampled August 4, 2026, only 20.0% populated the structured salary field, but 66.7% mentioned an actual dollar figure once the plain-text description was included.
What's the most common reason automated LinkedIn job extraction produces a duplicate? The same employer posting the identical role separately per city; 13.3% of the sampled postings were exact same-company, same-title pairs distinguished only by location, each with its own job ID.
Can LinkedIn job data ever be extracted with zero ambiguity? No. Some information, like which of several stated dollar figures is the real offer in a commission-heavy sales role, or whether a location string reflects actual work arrangement, isn't present in the source data at all, so no parser can recover it reliably.
What share of the sampled postings mentioned AI or agent-related work? 44.4% of the 90 postings mentioned an AI, agent, or LLM-related term in the job description, matching a similar trend seen in the equivalent Hacker News "Who is hiring" analysis.
Top comments (0)