At LinkedIn, our engineering teams build what’s needed to connect the world’s professionals to economic opportunity. For the Partner Solutions Engineering (PSE) team, this includes the technology that powers our talent and hiring solutions and support for how jobs get posted on the LinkedIn platform.

Amidst the Great Reshuffle, we created multiple job ingestion methods for various Applicant Tracking Systems (ATS), job distributors, staffing agencies, and job boards for our partners and customers. However, having multiple ingestion methods has made it difficult for some of them to understand and choose the best integration approach based on their business needs.

In this blog, we’ll explain the issues our PSE team identified around API based ingestion of jobs, the design proposal, and the adoption plan for a Unified API solution that will allow LinkedIn partners and customers to host more quality jobs and in turn improve our ability to connect our members to more opportunities.

Challenges with current job postings APIs

Originally, we had several APIs related to job postings that were offered as part of different talent solutions bundles. A partner could post jobs on the LinkedIn platform by integrating with LinkedIn Talent Solution (LTS) products such as Premium Job Postings (PJP), Apply Connect (AC), Recruiter System Connect (RSC), and Limited Listings (XML Feed).  were certain challenges that came with each of these products. First, there wasn’t an easy way for partners to discover Job Postings API as an independent offering. They always got access to posting jobs on LinkedIn through different bundled offerings and each bundled offering had a different API schema supported for posting, searching, or managing jobs.

Second, with multiple APIs around job postings, our partners with more than one bundled offering had to build to different sets of APIs and also had to post the same job multiple times using different OAuth API credentials. This resulted in job deduplication issues and impacted the customer and member experience. Additionally, one of the APIs used for the PJP integration was set up on an old legacy backend setup for deprecation. Thus, having a Unified Job Postings API hosted in the latest infrastructure was critical for ensuring a consistent customer onboarding experience.

Also, our mutual customers had to go through different onboarding flows to opt in for LinkedIn Talent Solutions’ bundled offerings. For RSC, customer onboarding took place at the partner’s ATS platform whereas for PJP, onboarding was on LinkedIn’s Recruiter platform, which made it difficult for our customers to get a unified view of all the LinkedIn services that they are using. Due to the described challenges and limitations of each product, the idea emerged to have a single API for job postings (Unified Job Postings API) with a product brand name as “Job Postings.” 

  • representation-of-previous--apis

Representation to indicate different APIs that existed before

Our vision and action plan

To enhance the partner and customer experience, we envisioned a solution that created ease of discoverability for the Unified Job Postings API,  capable of creating, managing, and searching through all types of jobs on the LinkedIn platform. 

To achieve this, the PSE team advocated and executed the following action plan:

For ease of discoverability, we defined Job Postings API as an independent product offering and showcased it on the developer platform’s product catalog (refer here for details). In support of this, we revised our partner documentation to have all job postings documentation under one dossier. Refer to our partner documentation, release notes, and a summary of documentation enhancements for more details. 

Partner development
Another major objective was to have a single externalized API for job postings with a unified schema. For this, we introduced OAuth product definition that supports tiering— lower tier allows partners to post only free jobs on LinkedIn whereas a higher tier allows partners to post paid jobs to LinkedIn. 

The PSE team worked with product managers for RSC, AC, and PJP integration bundles to understand the capabilities that this unified API should support. The solution was to define a foundation schema (schema core to posting and managing jobs on LinkedIn) along with necessary RSC, AC, and PJP bundle specific extensions. This allowed our partners to manage job postings by building these extension schemas on top of the foundation schema. To know more about the schemas refer here.

To validate our vision for a unified API and unified customer onboarding experience of LinkedIn Talent Solution offerings, LinkedIn’s PSE & Business Development teams also conducted feedback sessions using a combination of offline surveys and live calls with all our existing and potential future partners. The focus was to understand if the new unified job postings schema met their systems requirements and taxonomy definitions as well as to understand what solutions, in the form of an iframe widget, can be provided to our ATS partners to help with a smooth customer enablement process with little development effort required at partner’s end.

  • representation-of-job-posting-api

Representation to indicate single Job Postings API leading to majority of API based ingested field jobs

To ensure partner development happiness, the PSE team worked to provide video tutorials and API development tools, such as Postman collections and SwaggerHub’s Open API Specification. While Postman collections allowed our developers to quickly try our APIs, the open API specification provided the capability to auto generate client libraries with the tech stack of choice, which allow for a faster build as developers can focus on integration logic rather than writing client side LinkedIn API calls.

Timeline and strategy 

An effective plan involves enabling all job posting scenarios such as basic, promoted, and onsite job application collection, with a single API based on a common customer onboarding (opt-in) process. With this, it was crucial to systematically collect feedback and roll out the API with LinkedIn and the external partners.

  • migration-timeline-and-strategy

Timeline and strategy

Currently, we are in the process of migrating our existing partners and deprecating old job postings API schema and its supporting documentation. As we introduce the unified API, LinkedIn’s PSE and BD teams will work together to draft communications, re-evaluate legal agreements, and migrate these partners to the new API across all of our partner programs.To accelerate our adoption plan, it will be required for new partners to integrate with the Unified Job Postings API. 


When we talk about talent and hiring solutions, job postings are at the heart of any recruiting process. As we refine our programs, our aim is to scale up partner adoption and customer enablement by providing an easy to develop, self-serve, Job Postings API that allows LinkedIn to host more quality jobs with real time status updates. In turn, this will drastically improve our member’s job application experience and connect them to more economic opportunities. Additionally, the Unified Job Posting API’s modular and extensible schema and OAuth permission definitions will allow us to easily meet the demands of the ever-evolving talent marketplace.


Foremost, sincere gratitude to the Enterprise Jobs Product Manager, Mathias Arkayin. The completion of this project was not possible without his guidance. Besides this, our sincere thanks to Andrew Wu from Product, PE SAAS POD Manager Ramya Sampath, and Partner Engineer Kanika Vats for their able insights throughout the duration of this project.

There was immense amount of work across teams, our acknowledgement and gratitude for the contributions made by the Business Development team: Michael Belick, Maggie Ly, Anand Vora, and Vatsala Jain, Eng team: Ping Hu and Weiping Si, Product Education Specialist Karine Fenix, PMM Neha Mehta, Legal advisor Christopher Grant, Partner Operations Zendesk Owner Gyan Srivatsava, and Technical Writer Amandeep Kaur.

Cookies on this website

There's no tracking cookies or other nonsense used.