LinkedIn Conversions API.
Structurally unlike the others, in a way that shapes how you configure it: there is no event name on the wire. The event type lives on a conversion rule created ahead of time, and the event references it by URN. So one rule per event type, and the mapping has to be stored.
Credentials
%{
access_token: "…",
conversions: %{
"PURCHASE" => "urn:lla:llaPartnerConversion:123",
"LEAD" => "urn:lla:llaPartnerConversion:456"
}
}Keys are LinkedIn rule types; event_name/1 returns the type, and this looks
the URN up. An event whose type has no rule is skipped rather than guessed —
the alternative is attributing a purchase to whichever rule happened to be
first.
Rules are created with POST /rest/conversions (conversionMethod: "CONVERSIONS_API") and must be associated with campaigns, or nothing is
attributed. Advertisers can generate a non-expiring token directly in
Campaign Manager → Data → Signals Manager → Direct API, with no developer app
and no approval.
Three things that differ from every other platform here
Success is 201, not 200.
userIds must be present even when empty. Identifying a user only
through userInfo still requires "userIds": [], or the API answers 422.
No phone number field exists. SHA256_EMAIL, IP, the LinkedIn click id
and Google's advertising id are the whole match-key vocabulary.
Version pinning
Linkedin-Version is a required YYYYMM header, not a path segment.
Defaults to 202608;
override with config :pixelex, linkedin_version: "202610". Versions are
supported for at least a year, and a missing or expired one is an error
rather than a fallback.