LinkedIn jobs API: official or unofficial, and what each one lets you do

You go looking for the LinkedIn jobs API expecting a signup form and a key. Instead you find a wall. The endpoints that return job postings sit behind a commercial partnership LinkedIn grants to a short list of partners, not behind a developer console, so the "official or unofficial" question in your search box is really a question about that wall and what is safe to do once you accept it is not coming down for you.

That wall has enforcement behind it. In July 2025 Proxycurl, the most polished LinkedIn data API on the market, shut down with paying customers and real revenue still on the books. Every integration built on it broke the day it went dark, and nobody got a migration window. Keep that in view while you shop, because it is the outcome the words "official" and "unofficial" are quietly about.

The reason it is worth getting right is that job data is the cleanest buying signal on LinkedIn. A company opening three roles in the function your product serves has the problem you solve, today, with budget attached. There is an official LinkedIn jobs API. It does not do the thing you almost certainly want. And every product marketed as a "LinkedIn jobs API" that reads or searches job postings is unofficial, whatever its landing page implies.

This guide gives the plain ruling on both, then reframes the whole question, because "which API do I call" is usually the wrong problem. What you actually want from LinkedIn job data is a buying signal, and there is a compliant way to get one without the part that gets accounts flagged.

The short answer, in one table

Two rows of that table carry the whole argument, so here they are in words.

The official row does publishing, not reading. It is a pipe for putting jobs onto LinkedIn, not a way to pull jobs off it. The unofficial row does the reading everyone wants, but it does it by fetching public job pages at machine scale, which is a different activity from calling a supported endpoint, and it sits against LinkedIn's terms.

The official LinkedIn jobs API is for posting, not reading

LinkedIn's only official jobs API is the Job Posting API. It exists so that applicant-tracking systems and job-distribution platforms can publish, update, and close job listings on LinkedIn programmatically. If you run an ATS and you want the roles your customers create to appear on LinkedIn without anyone copy-pasting, this is the integration you would have wanted.

Three facts about it decide almost every real project:

1. It writes, it does not search. There is no supported, self-serve endpoint that returns "all software engineering roles in Berlin posted this week." The official surface is built around a partner pushing their own listings in, not any developer pulling arbitrary listings out.
2. It is partner-gated. Access is granted to approved ATS and distribution partners, not handed out on signup. It is not a key you generate from a developer console in an afternoon.
3. It is effectively closed. LinkedIn has not been onboarding new partners to this program, so for most teams the answer to "can I get access" is no, regardless of use case.

So when a tutorial tells you to "just use the official LinkedIn API" to collect job listings, it is describing something that does not exist. The official API cannot do it. This is the same pattern that shows up across LinkedIn's developer surface: the sanctioned endpoints are narrow and the interesting reads are not among them. We walk through which reads are actually available in the LinkedIn API endpoints you can use without approval, and the broader "is any of it free" question in is the LinkedIn API free.

What "unofficial" actually means here

Because the official API does not read job postings, a market of unofficial ones fills the gap. Search "LinkedIn jobs API" and nearly every result, on marketplaces and standalone vendor sites alike, is one of these. They come in two shapes.

Live readers. You call the vendor, the vendor fetches the public LinkedIn job page in real time, parses it, and hands you back structured fields: title, company, location, posted date, description. Factually, they scrape the public job listing on request.

Pre-built datasets. The vendor scrapes broadly ahead of time, normalizes the result, and sells you query access to the stored copy. You are reading their database, not LinkedIn, but the data got there by reading LinkedIn.

Both are "unofficial" in the only sense that matters: LinkedIn did not sanction them, and automated collection of listings at scale runs against LinkedIn's terms of service. The public nature of a job post is not a free pass here. Reading one page as a person is one thing. Operating a pipeline that pulls thousands of pages on a schedule is the activity LinkedIn's enforcement has been aimed at. The Proxycurl shutdown from the intro is the clearest case, and it was no quiet business pivot: LinkedIn sued in January 2025 over the fake accounts behind the collection, Proxycurl folded by that July rather than fight, and the settlement required deleting the data it had gathered. A paid, polished API with real revenue, gone, and every customer's integration gone with it. The full picture of what the courts actually established, and where the line between public data and terms violation sits, is in our LinkedIn data compliance guide.

The point of naming this plainly is not to scold anyone. It is that "unofficial LinkedIn jobs API" is a euphemism, and buying one means buying its compliance posture along with its data. That is a decision worth making with open eyes rather than because a product page said "API" and it sounded sanctioned.

Why the either/or is the wrong question

Almost nobody wants a jobs API for its own sake. They want to know that a specific company is hiring, because hiring is one of the cleanest buying signals in B2B.

A posted role is a dated, specific, public statement of intent. It tells you a budget was approved, a team is growing, and a particular pain exists right now rather than in theory. That is worth far more to a seller than the raw job text, and it is the actual reason people go looking for a jobs API in the first place.

Read that way, the question changes from "which API returns the most job fields" to "how do I turn a hiring signal into a qualified, timely conversation without putting my account or my compliance at risk." That is a better question, and it has a cleaner answer. The longer treatment of reading hiring as intent is in LinkedIn hiring signals as buying intent.

The compliant way to use hiring signals

Public job posts are public. You can read a company's open roles the same way a candidate can, without connecting an account, without operating anyone's session, and without running a bulk pipeline against LinkedIn. That is the whole point: monitoring public job posts to feed qualification does not require the automation that gets accounts flagged.

You can do the read part with nothing connected at all:

1. Start from the public signal. The free LinkedIn jobs search tool finds open roles by keyword and location and returns them as a list you can work from. No account, no session, no key.
2. Qualify before you reach out. A hiring signal is a starting point, not a lead. Match the role and company against who you actually sell to, and drop the ones that only look relevant.
3. Act at human pace, through your own account. The signal arriving all at once does not mean your outreach should. Reference the specific initiative behind the role, not "I saw you are hiring," which reads as surveillance.

Here is the difference the qualify step makes. Say a Series B logistics company posts three senior data engineer roles in a single week. The raw signal is only "they are hiring engineers." The qualified signal, once you check the team's current size, the tools named in the posts, and who owns data there, is "their data team is doubling and every role names the warehouse your product replaces." Only the second version earns a specific opening line. Surfacing the three posts is public and account-free; the judgment that turns them into one message worth sending is the part no jobs API ships.

This is the model BeReach is built on. The agent finds companies and people, qualifies them, and drafts the outreach you approve, and all of that runs on public data with nothing connected. A LinkedIn session is only needed at the real send boundary, which is a design we describe as cookieless until outreach. In practice that means the signal-gathering and qualification, exactly the part a jobs API is usually bought for, never touches your account at all. For teams that want to wire this into their own stack, the same capability is available as an API: 135 operations behind a single key, plus a connector that runs inside Claude, documented on the BeReach API page.

Does the qualification step actually pay off? The reply rates say yes. Belkins, analysing more than 15 million LinkedIn touchpoints (2026 outreach study), found warm campaigns replying at 12.2% against 7.9% for cold. A hiring signal is one of the cleanest ways to make a message warm, but only if you qualify on top of it rather than blasting everyone who posted a role.

What this means if you are a developer

If you were about to integrate an unofficial jobs API and pipe its feed straight into automated outreach, the calmer architecture is worth a look first. Reading public job posts for the signal is low-exposure. It is the second half, operating accounts at machine speed off the back of that feed, that carries the account and compliance risk, and it is separable from the first half.

Split them. Read the public signal for qualification, then send from your own account at human pace with a person approving the drafts. You get the hiring intent you wanted with far less exposure than a scrape-to-send pipeline, and no dependency on an "unofficial API" whose standing could change the day LinkedIn decides to enforce. The BeReach API is one way to run that split without building the qualification layer yourself.

Where the line actually sits

To keep it honest: reading a public page is not the same as automating an account, and the two get conflated constantly. Public job data is public. The enforcement of the last few years has landed on bulk resale of scraped data and on tools that operate accounts at machine speed, not on a person reading a listing or a server reading a public page on request. The full version, including what the Proxycurl shutdown and the hiQ litigation established, is in the LinkedIn data compliance guide. Read it before you commit to any approach that involves LinkedIn data at scale.