I spent 8 hours yesterday debugging a LinkedIn Conversions API integration. The architecture I assumed (one conversion ID, dual source, eventId dedup) does not exist on LinkedIn. The HTTP 403 I kept hitting was the platform telling me my mental model was Meta's, not LinkedIn's.
If you are setting up LinkedIn ads for a B2B revenue motion and you have used Meta CAPI before, this post will save you a day.
The short version
LinkedIn Conversions API requires a separate conversion entry per data source. You cannot use one Conversion Rule ID to receive both browser (Insight Tag) and server (CAPI) events. The conversion's source type is locked at creation and is not mutable. Dedup happens at the LinkedIn account level via shared eventId, not at the conversion-rule level.
This contradicts the Meta CAPI mental model: one pixel ID, two sources, internal dedup. The Meta pattern is so common in the industry that community guides routinely project it onto LinkedIn, and AI-assisted implementation help inherits the same assumption. The result is hours of debugging, 403 errors, and engineers wondering why an obviously-correct payload keeps failing.
The hard wall: HTTP 403
When you POST a CAPI event to a LinkedIn conversion rule that was created as Insight Tag type, the platform replies:
HTTP 403 { "message": "Invalid conversion target, failed to grant access.
Conversion must be a CAPI conversion and not deleted.", "status": 403 }
No retry, no override, no API workaround. The conversion entity itself is typed at the schema layer. LinkedIn enforces this.
In our case we had:
- A working LinkedIn Insight Tag conversion firing browser events
- A patched LinkedIn CAPI tag template in server-side GTM ready to send identical events server-side
- The Meta-CAPI assumption that we just needed to point both at the same conversion ID with eventId dedup
Six hours of debugging later, the right answer was: create a second, separate conversion entry typed as CAPI.
Why this happens: the Meta CAPI mental model
Meta Conversions API was the industry's first widely-deployed server-side ad attribution product at scale. Most engineers built their first server-side attribution on Meta. Meta's pattern is now the de-facto reference for what "CAPI" means.
Meta's model:
- One pixel ID
- Browser Pixel fires the event with an eventID parameter
- Server Conversions API fires the same event with matching event_id
- Meta deduplicates internally based on (pixel_id, event_name, event_id) within a 24-hour window
- One conversion in Meta's reporting
LinkedIn looks similar. The vocabulary overlaps. Both have "Conversions API." Both talk about eventId dedup. Both let you send the same event from browser and server.
But the underlying architecture is different. LinkedIn is conversion-object-centric. Meta is event-centric.
LinkedIn's conversionMethod field is set at conversion creation and is immutable. Two distinct values: EVENT_SPECIFIC_TAG for Insight Tag conversions (browser only), and CONVERSIONS_API for CAPI conversions (server only). A conversion typed as one cannot accept events from the other.
The 403 is not a bug. It is the platform telling you to create a second conversion entry.
The canonical architecture
For every business event you want to track via both browser AND server:
1. Two conversion entries in Campaign Manager.
One Insight Tag conversion, one CAPI conversion. Different Conversion Rule IDs. Same name pattern (LinkedIn recommends a CAPI_ prefix or (CAPI) suffix on the API-typed conversion so you can tell them apart in dashboards).
2. Same eventId from both sources.
Browser tag: map eventId via the LinkedIn Insight Tag 2.0 template's "Event ID" field. Pass your stable conversion identifier (lead ID, booking UID, etc.).
Server tag: pass the same eventId via the CAPI tag template's EventID field.
The dedup match key is (LinkedIn account, eventId). Account-scoped, not rule-scoped.
3. Both conversions attached to the same campaigns.
LinkedIn's bidding optimization reads them as a unified signal pool for the same business event. Attach both to every ad set targeting the conversion.
4. Read the reports correctly.
When LinkedIn receives an Insight Tag event and a CAPI event from the same account with the same eventId, it discards the CAPI event for counting purposes and counts only the Insight Tag event in reporting.
In your conversion view:
- Insight Tag count = total events captured browser-side
- CAPI count = total CAPI events MINUS those whose eventId matched an Insight Tag event (LinkedIn does the subtraction automatically)
- CAPI count is the incremental count. It represents events Insight Tag missed (ad blockers, ITP, JavaScript failures)
Typically Insight Tag count is higher than CAPI count when dedup is working. If your CAPI count exceeds Insight Tag count for the same event, the most likely cause is unreliable browser Insight Tag firing or eventIds not matching across sources.
Why the misinformation spreads
Three reinforcing causes.
Meta CAPI mental-model contamination. Meta is the reference. Engineers who built attribution on Meta first assume LinkedIn works the same way. The language overlap makes the assumptions transfer incorrectly.
LinkedIn's own documentation uses shorthand language. Phrases like "send via multiple methods" and "deduplicate via eventId" sound identical to Meta's pattern. The critical clarifier ("you must create a conversion rule for each data source") is buried mid-paragraph in the Microsoft Learn deduplication doc, not flagged prominently.
Community guides routinely paraphrase incorrectly. Some popular tutorials describe LinkedIn dedup as "when the same Conversion ID and Event ID are sent from both sources." That is misleading shorthand. The correct phrasing is "when the IT conversion AND the CAPI conversion both receive the same eventId in the same account." The conversion IDs are different. Only the eventId is shared.
Diagnostic table
If you are seeing any of these symptoms:
| Symptom | Likely cause |
|---|---|
| HTTP 403 "Conversion must be a CAPI conversion and not deleted" | Sending CAPI events to an Insight Tag conversion ID |
| HTTP 403 "Invalid conversion target, failed to grant access" | Same. Conversion is source-typed wrong for the request |
| Conversion shows Data source = "Event-specific tag" | That is an Insight Tag conversion. Cannot accept CAPI events |
| You created a conversion via "Create conversion → Insight Tag" or "Tag Manager" mode and now want CAPI on it | That conversion is permanently Insight-Tag-scoped. Create a new CAPI conversion |
| CAPI count higher than Insight Tag count for the same event | Browser Insight Tag unreliable, or eventIds not matching across sources |
Decision tree for any LinkedIn CAPI rollout
Do not trust the "single conversion + dual source" pattern even if you have used it successfully on Meta. LinkedIn is conversion-object-centric, not event-centric.
- Tracking the same business event via Insight Tag AND CAPI? Plan for two conversion entries per event.
- Already have an Insight Tag conversion firing? Do not try to add CAPI to it. Create a separate CAPI conversion.
- Want dedup? Send the same eventId from both sources. LinkedIn dedupes at account+eventId scope.
- Optimizing campaigns? Attach both conversions to each ad set. Bidding reads them as a unified signal pool.
- Reporting? Sum both rows for total volume. CAPI row is the ad-blocker recovery delta, not double-counting.
What this means strategically
If you are running paid LinkedIn for a B2B revenue motion at any meaningful scale, getting CAPI right is not optional. iOS Safari ITP and modern ad blockers cause real signal loss on the browser side. LinkedIn's documented internal estimate is around 31% incremental conversion lift from CAPI. Without it, your bidding model is making decisions on incomplete data.
But getting CAPI right on LinkedIn is not what most engineers expect from Meta-pattern experience. The architecture is different. Build the second conversion entry. Wire the eventId. Let the platform dedup. Read the reports as additive rather than alternative.
That is what engineered demand requires at the attribution layer: the truth about the platform, not the assumption inherited from the last platform.
Setting up LinkedIn CAPI for B2B and don't want to lose 30% of your conversions to the source-bound trap? We've shipped LinkedIn CAPI end to end (browser + server, with proper account-scoped deduplication) on production B2B funnels. The flagship engagement is a Demand Engine Diagnostic that maps your full GTM motion in one to two weeks.
See how Gilgamesh engineers GTM →