LinkedIn Member Data Portability API (DMA): The EEA-Only Data Route Most Developers Never Hear About
Every LinkedIn data conversation ends the same way — the Partner Programs are closed, the Products you need are not self-serve, and the answer is no. Then someone finds a Microsoft Learn page describing a LinkedIn API that returns a member's posts, comments, reactions and profile history with their consent, and asks the obvious question: why is nobody using this?
The short version
The Member Data Portability API is real, currently documented, and it exists because of law rather than product strategy. LinkedIn's own documentation states it is provided “in response to certain requirements of the Digital Markets Act (DMA)” — the EU competition law regulating large online platforms.
That origin is also its ceiling. This is a compliance obligation, not a growth channel, and the constraints written into it are the reason most product plans built on top of it collapse in week two rather than month six.
The constraint that ends most projects
LinkedIn states plainly that only members located in the European Economic Area — and, for the self-download product, Switzerland — are able to consent and generate a token. A member in the United States, the United Kingdom, India or anywhere outside that region cannot authorise your app through this route at all. Not with a workaround. Not with a VPN. The consent screen is simply unavailable to them.
There are two products, and people apply for the wrong one
This is the single most common false start. The names are nearly identical and the access paths could not be more different.
| Member Data Portability (Member) | Member Data Portability (3rd Party) | |
|---|---|---|
| Who it is for | A member fetching their own LinkedIn data | A third-party app fetching a member's data with consent |
| Company Page used | A specific default LinkedIn Page LinkedIn provides — you must not create a new one | Your own Company Page, association verified by its super admin |
| Review | Agree to the terms and access is provisioned | Access request form reviewed by LinkedIn |
| Business verification | Not part of the flow | Required — legal name, registered address, website, privacy policy, verified business email |
| Scope | Member-scoped permission | r_dma_portability_3rd_party |
| Token | Generated in the developer portal OAuth token tool | Standard 3-legged authorization code flow |
A documentation trap worth knowing about: the member self-download path is described with the scope r_dma_portability_self_serve in the token-generator walkthrough, while the Snapshot API permissions table lists r_dma_portability_member. Picking the wrong string in your OAuth configuration produces an authorisation failure that looks like a broken app rather than a scope typo.
What the API actually returns
Two endpoints sit behind the product, and they answer very different questions.
Member Snapshot API
A point-in-time export of the member's historical LinkedIn data, split into domains such as profile, articles and posts. This is the “give me what you already have” endpoint.
Member Changelog API
An event stream of what the member does after they consent — posts created, comments, reactions. Archiving starts at the moment of consent, not before.
The 28-day wall
Changelog events can only be queried for the past 28 days. Anything older is gone from your reach. Any product that assumes a durable event history has to build its own storage from day one.
One frozen API version
The Snapshot endpoint is versioned and supports exactly one version header. Send anything else and the request fails outright with a version error, no matter how current the rest of your integration is.
Why teams still get this wrong after reading the docs
The documentation is accurate. It is also written as a reference, not as a warning, so the commercially fatal details read like footnotes.
The Company Page rule is not interchangeable between the two products
One product requires LinkedIn's designated default Page and will not offer the access button if you created your own. The other requires your own Page with verified super-admin association. Building the app against the wrong Page means starting the application over.
Business verification is a hard gate, not a form field
A personal email address does not pass. The legal entity details have to be real and consistent with the privacy policy you submit. Teams routinely submit a request that cannot succeed and then wait weeks for a decision that was already determined at submission.
Pagination does not behave the way the response implies
The total count in the paginated response does not reliably reflect how many pages exist, because some data is assembled by offline systems. An integration that trusts that number silently truncates a member's export — the worst possible failure mode for a data-portability feature.
Consent timing changes what you can ever retrieve
Changelog archiving begins when the member consents. Your onboarding sequence therefore determines the shape of your dataset permanently, which is an architecture decision disguised as a UX decision.
This route does not replace the API access you were denied
It is a member-consented export mechanism for a specific region. It does not grant Marketing Developer Platform capability, company-page management, advertising data, or general-purpose LinkedIn API access. Positioning it to a client as a substitute creates a commitment your integration cannot honour.
Where this leaves your product
- If your users are global, this is at best a regional feature, and your product needs a defensible answer for everyone else.
- If you needed advertising, page-management or messaging data, this is the wrong door entirely — those remain behind the standard Products and partner review.
- If you are building genuine data portability or member-consented import for EEA users, this is the correct and intended route, and it is worth applying for properly the first time.
- If a client asked for “LinkedIn data via API” without specifying region or consent model, the scoping conversation has to happen before the application, not after a rejection.
Do not treat DMA products as stable ground
These products track a regulatory obligation and their documentation carries multiple dated versions. Availability, scopes and terms can change with the regulation. Any commercial commitment built on them should be re-verified against LinkedIn's current documentation before it is signed, not after.
How this fits the rest of LinkedIn API access
Most teams arrive here after being told no somewhere else. If you have not yet worked through the standard route, the Products model, Page verification and business vetting are covered in LinkedIn API access explained. If your problem is authentication rather than data volume, Sign In with LinkedIn using OpenID Connect covers the login-only path. And if you already hold access and are hitting session problems, why LinkedIn access tokens expire in 60 days explains the refresh-token restriction that catches most integrations.
Getting help with this
The hard part of a LinkedIn API project is rarely the code — it is deciding which access route can actually carry the use case, and preparing an application that survives review the first time. We provide LinkedIn API setup support, access-request preparation and policy-aligned technical guidance, including honest scoping when the route a client has in mind cannot deliver what they were promised. No specific review outcome can be promised; LinkedIn decides that. What is avoidable is an application that was never eligible to succeed.
Sources: Microsoft Learn — LinkedIn Member Data Portability (Member), Member Data Portability (3rd Party) and Member Snapshot API documentation, all verified against the live pages on 8 August 2026. DMA-related products change with the regulation; verify against LinkedIn's current documentation before implementation.