LinkedIn Recruiter Integrations: API Data Sharing

Before you commit to an integration architecture, you need one thing settled: exactly what member and candidate data LinkedIn will hand your product, and what it will never expose. The answer is narrower than most roadmaps assume. LinkedIn does not offer an open Recruiter API for third-party builders, a point covered in detail in our LinkedIn Recruiter API guide. What it offers for data sharing is Recruiter System Connect (RSC), and RSC is a sync layer, not a candidate database you can query.

With more than 1.2 billion members reported in Microsoft's fiscal year 2025 annual report, filed with the U.S. Securities and Exchange Commission, LinkedIn is the data set every recruiting product wants to build on. That scale is exactly why access is so tightly controlled. RSC lets an approved ATS and the customer's own Recruiter seat stay in step. It does not turn LinkedIn's graph into something you can search or export in bulk. Microsoft's FY2025 annual report is where that membership figure is stated.

The rest of this post maps the RSC data model, shows how the data moves into an ATS or CRM, and walks through the governance and rate constraints you have to design around from the first sync job.

RSC provides a fixed list of six features: Rediscovered Candidates, an In-ATS Indicator, One-Click Export, an Enhanced Profile Widget, InMail history retrieval, and stub profiles returned after an InMail response. Read those features as a data contract and they split into three buckets: data that goes up from your ATS, data that comes back down from LinkedIn, and data that LinkedIn withholds entirely.

The data you push up is the customer's own data. It powers the In-ATS Indicator and Rediscovered Candidates, so a recruiter sees which people are already in their pipeline. The data that comes back is the point most builders get wrong. The only profile record RSC returns from LinkedIn is a stub profile with those four fields, and it appears only after a candidate responds to an InMail inside an approved integration, or through One-Click Export. There is no way to read arbitrary profiles at scale.

Knowing the data model, here is how it actually moves. RSC requests use two-legged OAuth, the client-credentials flow, executed on behalf of each customer with that customer's own client ID and secret, organization URN, and contract URN. Your application authenticates as itself for each customer rather than acting on an individual recruiter's login.

LinkedIn breaks the integration into five development modules, which map cleanly onto the flow of data:

• Module 1, configure customer applications and ATS integrations. Onboard each customer and persist their credentials and URNs.
• Module 2, sync data from ATS to LinkedIn. Push candidates, applications, and notes up so they surface in Recruiter.
• Module 3, retrieve data from LinkedIn. Receive push notifications to your callback URL, for example when a One-Click Export happens, then retrieve the data.
• Module 4, sync ACLs. Define who can access which data inside the Recruiter account.
• Module 5, data deletion. Use the entity deletion APIs to remove records.

Two architectural points follow. First, retrieval is event-driven. Module 3 is a push to your callback URL, not an endpoint you poll on demand, so design for callbacks rather than expecting to query LinkedIn when you feel like it. Second, RSC assumes a Job Posting integration already exists, so you build that foundation first. The mechanics of receiving that data into an ATS, OAuth flows, webhooks versus polling, and normalizing schemas across systems, are covered in our ATS integration API guide.

The data flowing through RSC is personal data about real people, and LinkedIn wraps it in rules you have to build for, not bolt on later. Three of them shape your architecture directly.

Exports are consent-gated. Each member controls, through their own LinkedIn privacy settings, whether Recruiter customers can export their stub-profile data. Your integration cannot assume every profile is exportable, so handle the case where export is not permitted rather than treating it as an error.

Exported data makes the customer an independent controller. Once a stub profile is exported into the ATS through One-Click Export, the customer controls that copy independently of LinkedIn. In practical terms, the ATS carries its own obligations for that data under the EU General Data Protection Regulation, Regulation (EU) 2016/679, including lawful basis, storage limitation, and the right to erasure. You can read the regulation itself at EUR-Lex.

Deletion is a first-class part of the API. Module 5 exposes entity deletion APIs so the customer's ATS can trigger deletion of candidates, notes, and applications. Once a deletion is processed, all copies of the data are deleted within 30 days. LinkedIn also offers a 1-Click Export Deletion mechanism so partners are notified when a member whose data was exported later deletes their LinkedIn account, which lets the ATS reconcile its own records.

Two more constraints belong in the design, not the post-launch retro. The first is throttling. RSC and its Middleware endpoints publish per-endpoint limits, expressed as requests per day in UTC and records per minute. The applications-sync endpoint, for example, is documented at 1,000,000 requests per day and 10,000 records per minute. Limits reset at midnight UTC, and exceeding one returns an HTTP 429. The important nuance is that limits are per endpoint, so do not design against a single global number. Look up each endpoint you use and build in backoff for the 429 case.

The second constraint is contractual. Access to RSC is restricted to LinkedIn-approved developers, who must sign an API agreement with data restrictions before building, and pass a per-module certification. That agreement, not a technical control, is the real boundary on how LinkedIn data may be reused. Design your data handling to those restrictions from day one rather than assuming exported data is yours to repurpose. The wider question of what LinkedIn's terms allow you to automate is covered in our LinkedIn Recruiter automation guide.

Put the pieces together and a compliant RSC sync has a clear shape. You push the customer's own candidate, application, and job data up so it surfaces inside Recruiter. You receive a limited stub profile and export events back down through push notifications. You honor each member's export consent, you wire deletion in through Module 5, and you treat exported data as records your customer controls and must be able to erase. None of that gives you open search or ranking, because RSC was never built to.

That gap is where a parsing and matching layer earns its place. The structured candidate data and ranking most builders wanted from LinkedIn can be produced from the resumes, applications, and job descriptions already flowing through your product. That is what RecruitAI Suite provides as APIs you call from your own product. The Resume Parser API turns PDF and DOCX files into clean structured JSON, the Candidate Matching API scores and ranks candidates against a job with semantic matching instead of keyword search, and the Data Enrichment API fills the gaps LinkedIn will not export. ATS and CRM teams can see how these fit together on the ATS vendors page.

If you are deciding how to route around LinkedIn's data-sharing limits, the fastest way to know is to run the APIs against your own data. You can book a demo for API access and a walkthrough, or browse the full product list to see what each API returns.