Lead Sync API access is effectively a one-shot application — and most teams spend it on a draft
Nearly every other API programme lets you fix the form and try again. LinkedIn documents something different for Lead Sync, and it is buried on page two of the access guide where almost nobody reads it before clicking submit.
That single asymmetry is why Lead Sync applications deserve more preparation than the form suggests. A new app is not a free retry: it means new credentials, a new Page verification of that app by a super admin, and every downstream integration re-pointed — while the leads you were trying to collect keep arriving in a CSV nobody exports.
Four traps that sit before the form
Advertising API access does not include Lead Sync
LinkedIn states plainly that Lead Sync API is a separate programme and that access to the Advertising API does not automatically grant it. Teams routinely discover this after the ads integration is already live.
You can be approved and still retrieve zero leads
The permissions table marks both rw_ads and r_ads as unable to retrieve leads through the lead form responses endpoint. Only the lead-generation automation permission returns actual lead data. Reading and creating forms is not the same product surface as reading submissions.
The double-role requirement
For sponsored leads, the authenticated member needs a qualifying role on the ad account and a qualifying role on the Company Page associated with that ad account in Campaign Manager. One role without the other produces an empty response with no obvious error.
Prerequisites are pass or fail, not scored
Verified Company Page, a super admin of that Page having verified your developer app, a verified business email — LinkedIn notes personal email addresses will not pass review — plus legal name, registered address and website. The page ends with a flat statement that any failure to meet the prerequisites results in rejection.
What the sequence actually looks like
- Decide which product you are actually requestingCreating and managing Lead Gen Forms and retrieving the leads submitted through them are governed by different permissions in different products. Getting this wrong is the most expensive possible start, because the resulting integration passes every test until it needs a real lead.
- Get the identity layer clean before touching the formCompany Page verification, the super admin verifying your app, a verified business email on your organisation’s domain. LinkedIn lists these as prerequisites, not as things reviewers weigh.
- Write the use case for a reviewer, not for a product pageThis is the part with no second attempt. The published review criteria are about verified identity and an approved use case — the description has to survive someone who has never seen your product.
- Build the delivery mechanism to LinkedIn’s operational rulesWebhook subscriptions for lead syncing must be created through the notification subscriptions API rather than the portal UI, and the endpoint has to satisfy a challenge-response handshake plus signature verification on every delivery.
- Plan for enforcement after approval, not just at itLinkedIn reserves the right to monitor your application and suspend or discontinue Lead Sync access for non-compliance even where access was previously approved.
What blocks access vs what silently blocks leads
Almost every stalled Lead Sync project is one of these two categories misdiagnosed as the other. No amount of code fixes an access problem, and no amount of re-applying fixes a role problem.
| Requirement | What it actually stops |
|---|---|
| Separate Lead Sync API product request | Blocks access — Advertising API approval does not carry over |
| Verified Company Page and app verified by a Page super admin | Blocks access — listed as a prerequisite, checked before the use case |
| Verified business email on the organisation domain | Blocks access — personal addresses are stated not to pass review |
| Lead-generation automation permission in the token | Blocks leads — the ads permissions can read forms but not responses |
| Ad account role plus Company Page role on the associated Page | Blocks leads — the call succeeds and returns nothing useful |
| LinkedIn-Version header on every versioned call | Blocks the call — the latest version is not applied by default |
| Webhook challenge response and signature verification | Blocks delivery — and a repeatedly failing endpoint moves to a blocked state |
Where these projects stall
- The Advertising API was approved months ago, so nobody requested Lead Sync until the client asked why leads were not appearing in the CRM.
- The integration was built and tested entirely against form metadata, which the ads permissions can read, and never against a real submission.
- The authenticated member is an ad account manager but holds no role on the associated Company Page, so responses come back empty.
- The app was verified by a Page admin who was not a super admin, or against a Page that is not the organisation’s verified Page.
- The access request was written as marketing copy rather than as a description of what data is read, by whom, and why.
- A rejection arrived with no appeal link, and the team burned days re-submitting on the same app instead of accepting that a new app was the documented path.
- The webhook endpoint fails re-validation while nobody is watching the notification emails, and lead delivery stops without an alert in the product.
- The endpoint re-serialises the JSON body before verifying the signature, so every legitimate delivery is rejected as invalid.
- A tunnelling URL was used for the callback during development, which LinkedIn does not support for these webhooks.
Two live LinkedIn pages that contradict each other — know this before you copy a scope name
- The permission name itself. The Lead Sync access and reference pages name the lead-generation automation scope one way; the Lead Sync use-cases page, also current, names it differently. Both are official and both are live. Anyone copying a scope string from a search result has a coin-flip chance of a token that will never return a lead.
- The product name in the portal. The Microsoft Learn documentation tells you to search for one product name in the Products tab; LinkedIn’s own product catalogue page uses a different one. Same product, two labels.
- Which permissions are required at all. The use-cases page lists organisation and ads permissions alongside the leadgen scope; the reference permissions table does not include the organisation permission at all.
- Where the real vetting criteria live. LinkedIn’s product catalogue routes applicants to a PDF access guide for the requirements — and that document is not reliably retrievable. The criteria you are being judged against are, in practice, harder to read than the form you are filling in.
What LinkedIn does not publish — treat any figure you see elsewhere as invented
- No review turnaround time or service level for a Lead Sync access decision.
- No approval or rejection rate, and no cap on how many new apps you may build and re-apply with.
- No minimum ad spend, client count or revenue threshold.
- No document upload requirement — the published prerequisites ask for legal name, registered address, website and a verified business email, not incorporation papers.
- No requirement to be a LinkedIn Marketing Partner in order to obtain Lead Sync access.
- No confirmed lead-retention window on the Lead Sync reference pages, despite a widely repeated figure circulating in developer blogs.
- No published daily rate limit or quota for retrieving lead form responses.
The part that is genuinely hard
The mechanics are learnable: the product to request, the permission that actually returns leads, the roles that have to line up. What is not learnable from a blog post is writing an access request that survives a reviewer on the only attempt that developer app will ever get, and reconciling the role model across ad account, Company Page and app so that an approved integration returns real data on day one rather than an empty array. That reconciliation — and the judgement about what to say and what to leave out of the use case — is the work we do for clients.
Related reading: how the LinkedIn Advertising API standard tier upgrade works, Community Management API access from Development to Standard tier, and Sign In with LinkedIn and where OpenID Connect apps get stuck.