There is an official LinkedIn jobs API, and it does not do the thing you almost certainly want: it publishes listings for approved partners and cannot search or read postings. Every product marketed as a "LinkedIn jobs API" that reads or searches job postings is unofficial, whatever its landing page implies.
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 makes sense 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.
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 straightforward way to turn one into a relevant, timely message.
What each jobs API does, and who can use it
| Compared on | Official jobs API | "Unofficial" jobs API |
|---|---|---|
| What it is | LinkedIn's partner Job Posting API | Third-party services that read public job pages |
| What it does | Publishes and syncs job listings | Returns job-search results as structured data |
| Who can use it | Approved ATS and job-distribution partners | Anyone who pays the vendor |
| Search or read arbitrary postings | Not available | The entire selling point |
| Access status | Closed to new partners | Open, but built on scraping |
| Standing with LinkedIn | Sanctioned by LinkedIn | Not sanctioned by LinkedIn |
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 outside what LinkedIn sanctions.
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:
- 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.
- 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.
- 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.
One API for your agent.
Find people, draft, send what you approve.
The BeReach API finds the right people, reads their profiles and posts, and drafts the first message. Your agent drives it, you approve every send.
Start free trial
What "unofficial" actually means here
Because the official API does not read job postings, a market of unofficial ones fills the gap. The same split for people data and messaging is documented at the unofficial LinkedIn API, explained. 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 neither is built on a supported endpoint. 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 point of naming this plainly is not to scold anyone. It is that "unofficial LinkedIn jobs API" is a euphemism, and buying one means betting on a vendor whose standing with LinkedIn could change overnight, as Proxycurl's customers found out. 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.
| Job-post signal | What it tells you | The action it justifies |
|---|---|---|
| A role opened this week | Budget is live and the need is current, not stale | Reach out now, while it is the top of someone's mind |
| Several roles on one team | That function is scaling and stretched | Lead with the pain of scaling, not a generic pitch |
| A role your product supports | The buyer for what you sell just got busier | Reference the specific initiative, not the company generally |
| A backfill after a departure | A process is exposed and someone owns fixing it | Offer to reduce the gap while they hire |
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 instead of a generic outreach blast." 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.
Turning a hiring signal into a message worth sending
Public job posts are public. You can read a company's open roles the same way a candidate browsing openings would. The part that actually matters is not access, it is judgment: matching the role against who you sell to, and writing to the specific initiative behind it rather than the fact of hiring itself.
Three steps turn a posting into a message worth sending:
- Start from the public signal. LinkedIn's own job search finds open roles by keyword and location, free, and gives you a list to work from.
- 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.
- Write to the specific trigger, not the fact of hiring. Reference the initiative behind the role, the team scaling, the tool being replaced, not "I saw you are hiring," which reads as generic. Have a person approve each message before it goes out.
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 the easy part; the judgment that turns them into one message worth sending is what no jobs API ships.
This is the model BeReach is built on. The agent finds companies and people and drafts the outreach you approve. In practice that means the signal-gathering, exactly the part a jobs API is usually bought for, arrives already done. For teams that want to wire this into their own stack, the same capability is available as an API: 84 operations behind a single key, plus a connector that runs inside Claude and ChatGPT, 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, two problems are worth solving first. The vendor you would be depending on can disappear overnight, the way Proxycurl's customers found out, taking your integration with it. And a feed of raw postings sent straight to outreach with nobody reading it first produces exactly the generic "I saw you are hiring" messages that the reply-rate numbers above show underperforming.
Build the qualification layer instead: match each posting against who you actually sell to, write to the specific initiative behind the role, and have a person approve every message before it sends. The BeReach API is one way to get the drafting done without building it yourself.
Frequently asked questions
Is there an official LinkedIn jobs API?
There is an official Job Posting API, but it only lets approved partners publish and manage job listings, not search or read them. It is partner-gated, aimed at applicant-tracking and job-distribution platforms, and effectively closed to new partners. There is no official, self-serve API to search LinkedIn job postings.
What is the difference between an official and unofficial LinkedIn jobs API?
The official API publishes jobs to LinkedIn and is limited to approved partners. An unofficial jobs API reads and searches public job postings, which is the thing most people actually want, but it does so by scraping, which is not something LinkedIn authorizes. Official means write access for partners, unofficial means read access for anyone paying.
Is using an unofficial LinkedIn jobs API legal?
Reading a publicly visible job posting is not a federal crime under US case law. Collecting postings at scale through automated means is a different question: LinkedIn does not authorize it, and has pursued vendors doing it at scale in court, as the Proxycurl case showed. The answer depends on scale and method, not on whether the underlying data is public.
Can I search LinkedIn job postings without an account?
Yes, for public listings. A public job post is readable by anyone, so a tool can retrieve open roles by keyword and location without you logging into LinkedIn at all. A free jobs search tool does exactly this. Roles restricted to a private audience are not publicly readable and will not appear.
Why is a job posting a good sales signal?
A posted role is a dated, specific statement that budget was approved, a team is growing, and a pain exists right now. That makes it one of the cleanest buying signals in B2B, far more useful than a generic company match, because it tells you both that there is a need and that the timing is current.
