LinkedIn Recruiter ATS Integration: Data Sharing Guide

Before you commit to a LinkedIn Recruiter ATS integration, you need one thing settled: exactly what member and candidate data LinkedIn will hand your product, in which direction it moves, 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 to sync LinkedIn with an ATS is Recruiter System Connect (RSC), and RSC is a sync layer, not a candidate database you can query.

The short version: the customer's own candidate, application, and job data flows up from the ATS to LinkedIn, and only a limited profile flows back down. That returning profile takes one of two shapes, a basic stub from a One-Click Export or a fuller stub with email and phone after a member consents on an InMail reply, and nothing more. This post breaks that down field by field, shows which RSC tier exposes what, and ends with a two-way sync checklist.

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.

Read RSC as a data contract and it splits into three buckets: data that goes up from your ATS, data that comes back down from LinkedIn, and data that LinkedIn withholds entirely. The table below maps each flow to the fields it carries and the RSC tier that exposes it. Where a row is withheld, that is the work your product has to do itself.

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. LinkedIn returns a profile in only two situations, and the two are not the same. A One-Click Export hands back a basic stub with no contact details. An InMail stub profile is fuller, and can include the member's email and phone, but only when that member replies to the InMail and consents to share their contact information. If they decline, no InMail stub is stored at all. There is no way to read arbitrary profiles at scale.

RSC is not one product. It ships in two tiers, and the tier a customer has decides how much of the table above you can actually use. RSC+ is a superset of RSC 1.0, and RSC 1.0 must be active before RSC+ can be enabled.

RSC 1.0 is the core sync. It covers the six features most integrations start with: Rediscovered Candidates, the In-ATS Indicator, One-Click Export, the Enhanced Profile Widget, InMail history retrieval, and stub profiles returned after an InMail response. If your roadmap only needs to keep an ATS and a Recruiter seat in step, this tier is the whole story.

RSC+ extends that with four additions: syncing job requisition stages so LinkedIn reflects your pipeline status, retrieving application evaluations produced with LinkedIn Hiring Assistant, uploading and syncing resume attachments, and Connected Projects, which link a LinkedIn Recruiter hiring project directly to an ATS job requisition so every applicant sits in one combined pipeline. These RSC+ features require an amended API agreement, so treat them as a separate approval, not a config flag.

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. When an export fires, the push carries a request ID that you exchange for the exported candidate, and that request ID expires in 24 hours, so your retrieval job cannot lag a day behind. 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.

Contact sharing is consent-gated. A member decides whether to share their contact details when they reply to an InMail, and if they decline, no InMail stub profile is stored for them. Your integration cannot assume every profile is contactable, so handle the no-consent case as a normal outcome rather than 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 across nine record types: candidates, candidate notes, applications, application notes, application interview feedback, application stages, job requisitions, job requisition stages, and attachments. That list is itself a useful map of what RSC holds. Deletion also runs in the other direction. If an exported member deletes their LinkedIn account, they can reactivate within 21 days, after which LinkedIn purges the account and lists it on a closed-candidates endpoint. Partners are expected to poll that endpoint at least once every 30 days and tell the customer they may need to delete those records if they no longer have a legal basis to keep them.

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, most expressed as requests per day in UTC, with the applications endpoint adding a per-minute record cap and the export API using a monthly per-seat cap instead. The important nuance is that limits are per endpoint, so do not design against a single global number.

Daily limits reset at midnight UTC, and exceeding any of them returns an HTTP 429. Look up each endpoint you use, note that the One-Click Export cap is monthly and per seat rather than daily, 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 two-way sync has a clear shape. Use this checklist as the skeleton for the integration:

• Push candidates, applications, stage changes, notes, and interview feedback up through the Middleware endpoints.
• Register a callback URL and handle the export push, retrieving each exported candidate before its request ID expires in 24 hours.
• Pull One-Click Export stubs and InMail stub profiles, and store only what each member consented to share.
• Wire Module 5 deletion for all nine entity types so a customer can erase candidates, notes, applications, stages, requisitions, and attachments.
• Poll the closed-candidates endpoint at least once every 30 days and flag members who deleted their LinkedIn account.
• Add backoff for per-endpoint HTTP 429s and treat each endpoint's limit separately.
• Build the open search, ranking, and structured candidate data RSC never returns from the data you already hold.

Follow that shape and the sync is honest about what LinkedIn shares and what it withholds. What it withholds is exactly the open search and ranking most builders wanted, because RSC was never built to provide them.

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.