Posting jobs to LinkedIn via API: what access actually requires in 2026

Search for linkedin api post job and you will land on two completely different sets of documentation. One is about publishing a text update to the LinkedIn feed. The other is about publishing an employment opportunity to LinkedIn Jobs. They share almost nothing: different base paths, different auth flows, different approval regimes. Getting this wrong costs people days.

The short version. If you want to publish a feed post, you want the Posts API at POST /rest/posts, and the member-level permission for it is self-serve. If you want to publish a job opening, you want the Job Posting API at POST /rest/simpleJobPostings, and it is gated behind a LinkedIn Talent Solutions partnership. As of this writing, LinkedIn’s own Job Posting API overview carries a notice that it is not accepting new partnerships for that API. Everything below is verified against LinkedIn’s developer documentation on Microsoft Learn, which is where LinkedIn publishes its API reference.

Share post versus job post: the disambiguation

These are the two things people conflate, side by side.

A share does not become a job listing. Posting “we’re hiring a backend engineer” to the feed puts content in front of your followers. It does not create a record in LinkedIn Jobs, it does not appear in job search, and it does not consume a job slot. Those are separate systems.

A quick tell for whichever doc page you have open: if it mentions lifecycleState and commentary, you are in the feed docs. If it mentions jobPostingOperationType and externalJobPostingId, you are in the jobs docs.

What the LinkedIn Job Posting API is

LinkedIn’s Job Posting API lets authorized third parties - ATS vendors, job distributors, and their customers - post jobs directly to LinkedIn on behalf of those customers, instead of a recruiter typing them into the LinkedIn website. It sits inside LinkedIn Talent Solutions alongside Apply Connect, Apply with LinkedIn, and Recruiter System Connect.

It supports two job categories, selected with the listingType field. Basic jobs are free listings that get limited active promotion. Premium jobs are paid listings that land in a customer’s purchased job slots and require a LinkedIn Recruiter contract ID. Not every approved partner gets promoted-job permission; the docs say it is granted selectively.

There is a second, non-API route: XML feeds, where LinkedIn ingests jobs from a feed rather than having them pushed over HTTP. LinkedIn warns not to use both for the same customer, because the same job arriving twice gets deduplicated unpredictably.

The access model, stated plainly

There is no self-serve path. LinkedIn’s Getting Access page lists exactly three open permissions available to all developers without approval: profile and email from Sign In with LinkedIn using OpenID Connect, and w_member_social from Share on LinkedIn. Everything in the Talent catalog - Job Posting, Apply Connect, Apply with LinkedIn, Recruiter System Connect - sits behind the Talent Solutions partner application.

On top of that, the Job Posting API overview page now opens with an explicit notice that LinkedIn is not currently accepting new partnerships for the Job Posting API, and directs developers who want job-posting capability to request access to Apply Connect instead. Apply Connect is an ATS integration whose scope is broader: partners post jobs on behalf of customers and receive applications back into the ATS, with candidates applying without leaving LinkedIn.

The docs are not perfectly consistent about this. The Premium Job Posting page still points readers at the partner request form without carrying the closure notice. Treat the Apply Connect redirect on the Job Posting overview as the current signal, and confirm with LinkedIn before you build.

The attached terms are not boilerplate either. Partners must make customers accept LinkedIn’s Jobs Terms and Conditions before any job is posted, keep an auditable record of who accepted and when, and produce it on request. Partners are also barred from marketing the integration as a free way to post jobs to LinkedIn, and LinkedIn reserves the right to require that certain jobs be promoted.

LinkedIn’s job-related API surfaces

The technical shape, if you do get in

Auth is OAuth 2.0 client credentials, not the three-legged member flow. You POST grant_type=client_credentials with your client ID and secret to https://www.linkedin.com/oauth/v2/accessToken and get back a token with a 30-minute lifespan. LinkedIn recommends reusing one token across concurrent and consecutive calls rather than minting a new one per request.

There is no scope name to request for job posting. Unlike w_member_social, access is granted at the application level when LinkedIn provisions your app. If your app was not enabled for it, the token request itself fails with access_denied.

All versioned Talent endpoints live under https://api.linkedin.com/rest/ and require a LinkedIn-Version header in YYYYMM format; the docs currently name 202603 as the latest Talent version. Each version is supported for at least two years, and calling a sunset version returns 426 Upgrade Required. Legacy unversioned endpoints under /v2/ still exist and are being retired.

Job creation is a batch write. You send an elements array and set the x-restli-method: batch_create header; omitting it returns a 403. The four lifecycle operations - create, update, renew, close - are all selected by the jobPostingOperationType field on each element, not by different endpoints or verbs.

POST https://api.linkedin.com/rest/simpleJobPostings

Authorization: Bearer {access_token}
LinkedIn-Version: 202603
x-restli-method: batch_create
Content-Type: application/json

{
  "elements": [
    {
      "company": "urn:li:company:{company_id}",
      "externalJobPostingId": "1234",
      "jobPostingOperationType": "CREATE",
      "title": "Software Engineer",
      "description": "We are looking for a passionate Software Engineer...",
      "location": "San Francisco, CA",
      "employmentStatus": "FULL_TIME",
      "companyApplyUrl": "https://example.com/jobs/1234",
      "listedAt": 1440716666,
      "workplaceTypes": ["remote"]
    }
  ]
}

The call is asynchronous. A success returns 200 OK with a urn:li:simpleJobPostingTask:... id per element, valid for 24 hours, which you then poll for the real outcome. Per-element errors also come back inside a 200 body, so you cannot just check the HTTP status and move on. A maximum of 100 jobs is allowed per batch call.

To see whether a job actually went live, use the Job Posting Status API at GET https://api.linkedin.com/rest/jobPostingStatus?ids=..., also capped at 100 jobs per batch. It returns jobPostingUrl, listingStatus, linkedInApplyStatus, promotionStatus, and expireAt, and partners are required to surface the first four in their own UI. That matters more than it sounds: LinkedIn can close a job on its own, for example when multiple members report it as no longer accepting applications, and this is how you find out.

Two other limits worth knowing before you scope the work: descriptions cap at 25,000 characters including HTML tags, and a job can carry at most seven locations via alternateLocations.

Rate limits and quotas

LinkedIn publishes these as application-level throttles measured in UTC.

• Job Posting API: 100,000 requests per day. For promoted jobs specifically, 2,000 records per minute and 60,000 records per day.
• Job Posting Status API: 1,000,000 calls per day.
• Share on LinkedIn, for contrast: 150 requests per day per member and 100,000 per day per application.

Those are generous ceilings, which tells you the constraint here was never throughput. It is admission.

What getting approved actually takes

If you are a developer deciding whether to even start, here is the honest shape of it.

• You need a commercial relationship first. The docs repeatedly say to reach out to your LinkedIn Relationship Manager or Business Development contact, and if you do not have one, to submit the Talent Solutions Partner Request Form. This is a business development process, not a signup form.
• You sign an API agreement with data restrictions. LinkedIn states you must meet certain criteria and sign that agreement before using the integration.
• The profile that fits is an ATS or job distributor with existing customers. Every part of the design assumes it: you create a child API key per customer through the Provisioning API with a strict one-to-one mapping, and you build an onboarding widget to collect each customer’s company page ID and, for paid jobs, their Recruiter contract ID.
• You certify before you go live. Apply Connect certification runs across seven modules and 28 numbered test cases covering token refresh, webhook signature verification, application delivery, plugin rendering, and retry logic. You demo them to your business development contact, and LinkedIn provisions your production API key only after full coverage.
• LinkedIn does not publish a fee, an approval timeline, or an SLA for any of this. Anyone quoting you one is guessing.

That is a multi-quarter integration program with a commercial gate in front of it. Reasonable if you sell an ATS. Not something a solo developer finishes on a weekend.

If you are an employer who wants jobs on LinkedIn

You almost certainly do not need to build this yourself. If your ATS is already a LinkedIn Talent Solutions partner, jobs flow through that integration and the work is configuration, not code. That is the normal path, and it is why the API is built around per-customer child applications in the first place. If you are choosing an ATS partly on this basis, see our walkthrough of how ATS API integrations are structured and the breakdown of which ATS APIs are public and which are gated. LinkedIn is not unusual here. The same pattern shows up in Indeed’s partner APIs, and it is the default across job posting APIs as a category.

If you actually wanted to read LinkedIn job data

Say it plainly: LinkedIn does not offer an API for searching or reading job postings. The Talent product catalog contains four products - Apply Connect, Apply with LinkedIn, Job Posting, and Recruiter System Connect - and every one of them is employer-side. The only read surface in the job stack is the Job Posting Status API, and it returns status for jobs you yourself submitted, keyed by your own externalJobPostingId. There is no endpoint that queries LinkedIn’s job index by title, company, or location.

That is why so much “LinkedIn jobs API” search traffic ends in disappointment. There is no gated program to apply to and no enterprise tier to buy. The capability does not exist as a product.

Which leaves two options. The first is scraping, covered in building a LinkedIn job scraper in Python. Be clear-eyed about it: it runs against LinkedIn’s User Agreement, it is aggressively rate limited and challenged, account and IP bans are routine, and the markup changes often enough that maintenance is the real cost rather than the build. Plenty of people do it anyway. Just price the ongoing breakage before you commit a roadmap to it.

The second is to stop treating one job board as the dataset. Most questions phrased as “LinkedIn job data” are really questions about the job market: who is hiring for a role, where, at what seniority, how recently. Those are better answered from broad coverage of public postings than from any single site.

That is what JobsPipe does. We index public job postings from 30+ sources - job boards, aggregators, and ATS platforms - normalize them into one schema, and serve them from one endpoint with a self-serve key. No partnership application, no business development call. We have no LinkedIn partnership and do not resell LinkedIn data; we index what is publicly posted across the wider market.

curl -X POST https://api.jobspipe.dev/v1/jobs/search \
  -H "Authorization: Bearer jp_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "job_title_or": ["backend engineer", "platform engineer"],
    "job_country_code_or": ["US", "GB"],
    "job_seniority_or": ["senior"],
    "remote": true,
    "posted_at_max_age_days": 7,
    "limit": 50,
    "include_total_results": true
  }'

You get back a metadata object with total_results and next_cursor, plus a data array of postings carrying title, company, location, country, compensation, seniority, posted date, a stable id, and an apply_url. The free tier is 100 requests per month with no card. If you are still comparing options, we keep a running survey of the jobs APIs worth considering and an explainer on why unified job data beats per-source integrations.

The summary

LinkedIn has a real, well-documented job posting API at POST /rest/simpleJobPostings. You probably cannot get it: it needs a Talent Solutions partnership, and the docs say new Job Posting API partnerships are closed, pointing developers to Apply Connect. It is not the share API, which is what most people searching for this find first. And if you wanted to read job postings out of LinkedIn, no such API exists in any tier.