LinkedIn Conversions API Access: Two Very Different Paths, and Why One Rejection Can End Your App
Most guides still tell you that sending server-side conversions to LinkedIn means building a developer app and applying for review. For a large share of advertisers, that is no longer true — and for the teams who genuinely do need the reviewed path, the stakes are higher than almost anyone writing about it explains.
The change most content missed. Since the March 2025 (202503) Marketing API release, an advertiser sending their own conversion data can generate a non-expiring access token directly inside Campaign Manager, under Data → Signals Manager → Direct API — with no developer application and no Conversions API access request at all. The reviewed Developer Portal route still exists, but it is aimed at platforms and partners integrating on behalf of other advertisers. Choosing the wrong path is the single most common reason a project stalls before it starts.
What the Conversions API actually is
The LinkedIn Conversions API is a server-to-server pipeline. Instead of relying on a browser pixel to fire when someone converts, your own server reports the conversion event to LinkedIn, so the measurement survives ad blockers, cookie restrictions, offline conversions, and conversions that happen well after the click. The results surface in Campaign Manager at account, campaign group, campaign, and ad level, and feed optimisation.
Mechanically it is three moving parts: a conversion rule, an association between that rule and your campaigns, and a stream of events. Simple on paper. The friction is entirely in access, identity data, and reconciliation.
Server-side, not browser-side
Events originate on your infrastructure, which is why the identity matching burden shifts onto you.
Works alongside the Insight Tag
It is not a replacement. Running both is a documented, supported pattern — and it introduces a deduplication problem.
Reporting is not instant
LinkedIn publishes up to 24 hours to ingest and a further 48 hours for reporting — up to 72 hours before data is complete.
Access is revocable
LinkedIn explicitly reserves the right to suspend access for non-compliance even after an application was previously approved.
Path A vs Path B: which gate are you actually standing at?
This is the fork that decides whether your project is a configuration exercise or a vetted business application.
Path A — Direct API (self-serve)
- For advertisers sending their own conversion data
- Token generated inside Campaign Manager, no developer app required
- No Conversions API access request through the Developer Portal
- Generated tokens do not expire — and Campaign Manager does not store them again, so the handling of that credential is entirely on you
- The authorising user must hold a real ad-account role, not a viewer role
Path B — Developer Portal (reviewed)
- For platforms, agencies and products integrating on behalf of other advertisers
- Requires a developer application with the Conversions API product requested under the Products tab
- LinkedIn reviews business identity, organisation, domain, Page association, use case and terms compliance
- Partners face an additional Technical Sign Off process that LinkedIn has described as rolling out, including a live demo before beta customers are onboarded
- A rejection is close to terminal for that app — see below
What the reviewed path actually checks
LinkedIn publishes the review criteria plainly, and states that failing to meet the prerequisites will result in the request being rejected. The list is short, but each item is a place real applications die.
A verified business email address
Personal email addresses are documented as not passing review. This alone disqualifies a surprising number of first attempts from founders and contractors.
A verifiable, legally registered organisation
Legal name, registered address and website must line up and be independently checkable. If identity vetting concludes the entity is not verifiable as legally registered and active, the request is denied on those grounds.
A verified LinkedIn Page for the same organisation
A super admin of the associated Page must verify the developer application. Test or placeholder company Pages are explicitly called out as unacceptable.
An approved use case
LinkedIn enumerates the accepted reasons for wanting server-side conversion data. A vague or generic answer here is the most common self-inflicted rejection, because reviewers are matching your description against a defined list.
Terms, security and privacy posture
Compliance with the Marketing API Terms and LinkedIn’s security, privacy and trust requirements. The integrator remains solely responsible for how LinkedIn data is used, disclosed and stored.
App naming
The application must not incorporate any portion of the LinkedIn or Microsoft names or logos. A small detail that silently sinks otherwise solid submissions.
The part almost nobody warns you about
If a request is denied specifically on identity vetting, an appeal route exists. But if a request is rejected — for example because the access form lacked sufficient detail — and no appeal option appears, LinkedIn’s documentation is clear that you cannot re-apply for access using that same developer application. You create a new one and start over.
That single sentence changes the whole risk profile. A weak first submission is not a free draft. It costs you the app, any configuration attached to it, and the time to rebuild. This is precisely why the preparation work matters more than the code.
Where Conversions API projects stall
- Applying through the Developer Portal when the self-serve Campaign Manager route would have covered the use case entirely
- A use-case description written in marketing language rather than mapped to LinkedIn’s accepted categories
- Developer app created under a personal email or an unverified company Page
- No Page super admin available — or the Page belongs to a different legal entity than the one on the application
- Reporting looks wrong after go-live because browser and server events were never separated into distinct conversion rules
- Assuming a rejection can simply be corrected and resubmitted on the same app
- Building the event payload before confirming which identifiers the business can lawfully collect and hash
- Treating approval as permanent, when access is explicitly revocable for non-compliance
Deduplication: the reporting trap
Running the Insight Tag and the Conversions API together is normal and supported. But if the same event reaches LinkedIn from both sources carrying the same event identifier, it is the Conversions API event that is discarded and the Insight Tag event that is counted — not the other way round.
Teams routinely assume the server-side event wins, then misread their own dashboards for weeks. LinkedIn’s own health signal is that the Insight Tag count will typically be higher when deduplication is working correctly. Getting this wrong does not produce an error message; it produces confident, incorrect reporting.
| Constraint | What LinkedIn publishes |
|---|---|
| Request rate | 600 requests per minute per member access token |
| Daily volume | 500,000 requests per day per member access token |
| Batch size | Up to 5,000 conversion events per batch request |
| Event recency | Events must fall within the past 90 days or they are rejected as an invalid conversion time |
| Batch failure behaviour | One invalid value fails the entire payload — the whole batch must be resubmitted |
| Attribution windows | 1, 7, 30 or 90 days, with a 365-day option available only for a specific subset of conversion types |
Identity data carries its own rules: email identifiers must be lowercased, stripped of whitespace and SHA-256 hashed without a salt before they leave your system, and LinkedIn has been steadily expanding the accepted identifier types — the July 2026 release added a hashed IP address identifier alongside the existing plaintext option. Which identifiers you can send is a legal and data-governance question in your business long before it is an engineering question.
How this compares to the other approval gates
If you have been through Meta’s Conversions API setup and its App Review requirement for SaaS platforms, the shape will feel familiar: a self-serve route for your own data, a reviewed route the moment you touch someone else’s. LinkedIn’s other products follow the same logic — both the Advertising API standard tier upgrade and Community Management API access hinge on a verified company, a verified Page, and a use case a reviewer can categorise.
The difference with Conversions API is the cost of getting it wrong. On most platforms a rejection is a resubmission. Here it can mean rebuilding the application.
What good preparation looks like
Before a single line of integration code is written, the questions that decide the outcome are business questions: which access path genuinely fits, whether the legal entity and the LinkedIn Page belong to the same organisation, who holds Page super admin, which of LinkedIn’s accepted use cases your product honestly maps to, and which identity fields you are permitted to collect and hash. Getting those answers aligned — and written in the language a reviewer is assessing against — is the work.
Self-serve or reviewed, decided before any app is created
Entity, Page, email and use case aligned before the form is opened
Separate rules per source, deduplication understood up front
This article is independent guidance based on publicly available LinkedIn and Microsoft developer documentation as of July 2026. It is not affiliated with, endorsed by, or a partnership with LinkedIn or Microsoft. Platform requirements change frequently — always verify against the current official documentation. Approval decisions rest entirely with the platform, and no specific outcome or timeline can be guaranteed.