TL;DR
- Before the DMA, getting structured access to your own LinkedIn data for personal automation was effectively impractical.
- The EU forced gatekeepers such as Microsoft and LinkedIn to provide machine-readable, programmatic portability APIs for user data (Microsoft implements DMA compliance measures – EU Policy Blog).
- LinkedIn’s Member Data Portability API gives EU/EEA and Swiss users structured access to profile data through a legitimate API instead of fragile exports or scraping.
- That API lets me generate my README, Europass CV, and PDF automatically from one source of truth.
- GitHub Models makes it easy to send that generic CV data to an LLM and tailor selected sections for specific roles such as SRE, DevOps, or software engineering.
- The result is a maintainable pipeline: update LinkedIn once, generate multiple artifacts, and produce role-specific CVs quickly.
- If you want you can replicate it, clone the repo, adapt the pipeline to your own data with your token, and use it to apply to roles because…
- …we are hiring! Open Job Positions: Apply Now | Würth IT Italy
The Challenge
LinkedIn is my single source of truth for professional experience.
Every new role, certification, or skill update goes there first.
A person’s CV should reflect those changes automatically – not weeks later when he or she remembers to manually copy information across formats and through different portals.
The idea was simple: build a pipeline that pulls my LinkedIn data on a schedule, generates a polished README for my GitHub profile, and from that generates a PDF – all versioned automatically.
One source, many outputs, zero manual effort.
Bonus points to include the latest Europass CV in XML.
But for years, programmatic access to my own LinkedIn data was effectively impossible.
The Walled Garden Problem
LinkedIn’s API story has always been one of progressively locking things down.
The platform’s approach to data access was designed for enterprise integrations, not for individual developers wanting to control their own professional information.
The legacy LinkedIn API v2 required joining a partner program.
The application process asked you to explain a lot of things and “I want to automate my own CV sync with other platforms” was never going to pass that bar.
Even if you managed to create a developer application, most useful endpoints demanded company verification and commercial justifications designed for SaaS platforms, not personal pet projects.
Over the past decade, as far as i know, LinkedIn systematically shut down the very APIs that would have made personal automation possible. The Connections API was discontinued. Profile endpoints became restricted. Each API version removed more capabilities. The direction was unambiguous: your data lives in LinkedIn, and it stays there.
The official “Download your data” feature wasn’t much better – a ZIP file delivered after a 10-minute wait, containing CSV and HTML files with no machine-readable structure. Profile photos sit in separate files with no structured relationship to the rest. Every time anything changes, you re-download and re-parse. For a weekly automated pipeline, this was a non-starter.
I wasn’t building a commercial product. I just wanted structured access to my own data. And for a long time, that simply wasn’t possible.
Then the EU Stepped In
The European Union’s Digital Markets Act (DMA) was adopted in September 2022, entered into force on 1 November 2022, and became fully applicable in May 2023. By September 2023, the European Commission had designated six companies as “gatekeepers” – Alphabet, Amazon, Apple, ByteDance, Meta, and Microsoft. LinkedIn, as a Microsoft platform, fell squarely under the regulation’s scope.
The compliance deadline was 6 March 2024: designated gatekeepers had to fully implement the DMA’s provisions by that date.
What makes the DMA different from previous data protection regulations is its emphasis on portability as a right. GDPR already established the right to access your data, but in practice most platforms complied with bulk download features – ZIP files, CSV exports, the kind of thing LinkedIn already had. The DMA goes further. It mandates:
- Machine-readable formats: structured data (JSON, XML), not human-readable HTML dumps
- Programmatic access: real API endpoints, not manual download buttons with 10-minute waits
- Comprehensive coverage: all data categories, not cherry-picked subsets
- Standard authentication: OAuth 2.0 consent flows, respecting user authorization
For LinkedIn specifically, this meant building an entirely new API product – the Member Data Portability API – available to any EU/EEA or Swiss member without commercial justifications or partner approvals.
Suddenly, I had exactly what I needed – even if I only discovered it this year, in 2026, after trying and then giving up at least 3 times in the past.
Two APIs, One Pipeline
LinkedIn’s DMA compliance actually provides two distinct APIs, and understanding both matters for building useful automation.
The Member Snapshot API is the workhorse. It returns a point-in-time snapshot of your profile data across 17 queryable domains: profile information, work positions, education, skills, certifications, courses, languages, honors, publications, patents, projects, organizations, volunteering experiences, recommendations, endorsements, causes you care about, and an AI-generated profile summary. Each domain returns clean, paginated JSON. One request per domain, pagination for large datasets, and you’ve got your complete professional history in structured form.
The Member Changelog API complements this with real-time interaction data – posts you’ve created, comments, reactions from the past 28 days.
I do not care about this, for now.
The authentication model is refreshingly simple compared to LinkedIn’s commercial API tiers. You create a developer application on the LinkedIn Developers portal, using a specific default company page LinkedIn provides for exactly this purpose – no need to register your own company. You request access to the Member Data Portability API product, agree to the terms, and generate an access token through LinkedIn’s OAuth Token Generator Tool with the r_dma_portability_self_serve scope.
The token lasts approximately a year, and renewal follows the same straightforward process(for now i made it manually but i think i could even automate the token creation by using client_id and Primary Client Secret, in the future).
No partner negotiations. No usage-based pricing. No API key tiers. Just standard Bearer token authentication with a version header.
Building the Pipeline
The implementation turned out to be almost anticlimactically simple. My fetch script in dotnet iterates over the 17 snapshot domains, making one paginated API call per domain, and caches the combined JSON locally. Downstream scripts then parse that cached data to generate a GitHub-flavored markdown README, a Europass-compliant CV in XML, and a PDF rendered through headless Chromium.
The entire fetch phase – all 17 calls – completes in under a minute from a GitHub Actions runner. The cached JSON serves as the single intermediate representation: this is so that we don’t spam the API, even if i don’t even know how much should i call it to be throttled.
The GitHub Actions workflow runs weekly and requires exactly one secret: the LinkedIn access token. Everything else is self-contained. You can see the complete implementation – fetch script, README generator, CV generator, PDF pipeline – in my repository, which is open source specifically so others can replicate this setup: macel94 (Francesco Belacca)
Beyond CVs: Why This Matters
The most interesting thing about the DMA Portability API isn’t what it does for my specific use case – it’s what it represents.
For the first time, I can treat my LinkedIn profile as a data source I own rather than content I’ve contributed to someone else’s platform.
I can generate a static portfolio website from the same data.
I can build career timeline visualizations.
I can automatically synchronize my professional information across multiple platforms with LinkedIn as the authoritative source, rather than manually keeping different profile pages in sync.
The real shift is philosophical. The DMA treats user data as a portable asset rather than locked platform content. And LinkedIn is just one of the designated gatekeepers. Meta, Google, Apple, Amazon, and ByteDance all face similar obligations. The precedent being set here – comprehensive, programmatic, user-controlled data access – could fundamentally change how we relate to the platforms that hold our information.
The Geographic Catch
There’s one significant limitation worth discussing honestly: this is only available to LinkedIn members located in the European Economic Area and Switzerland.
The DMA is EU law, and LinkedIn has no obligation to extend these APIs globally.
If you’re outside the EU, this article might feel like reading about a feature you can’t use. And honestly, that’s fair. But it also demonstrates what’s possible when data portability is treated as a right rather than a feature request. Hopefully other jurisdictions take note.
Conclusion
Getting the data out of LinkedIn in a structured way solved the first half of the problem. The second half was making that same data useful for different contexts without maintaining three or four hand-written versions of the same CV. That is where GitHub Models turned this from a neat export pipeline into something genuinely practical.
Once I have a detailed, generic representation of my experience, I can prompt an LLM to selectively reframe it for a specific role without inventing anything new. In my case, I use GPT-5 through the GitHub Models API with a very small amount of glue code: read the generated README, tell the model which sections it is allowed to rewrite, describe the target role, and ask it to preserve dates, companies, structure, links, and formatting. The result is not a fake CV generator. It is a tailoring layer on top of verified source data.
That distinction matters. LLMs are unreliable when they are asked to create substance from nothing, but they are much more useful when they are constrained to transform rich existing content. If your underlying profile data is already verbose, specific, and current, a model can do a surprisingly good job of emphasizing reliability work for an SRE role, automation and CI/CD for a DevOps role, or backend and distributed-systems experience for a software engineering role. The better your source material, the better the tailoring output.
GitHub Models makes this especially easy because the inference step fits naturally into the same developer workflow as the rest of the pipeline. I am already in GitHub Actions. I already have markdown artifacts. I already have a repository that stores the generated outputs. Adding one API call to GPT-5 to rewrite selected sections of the README for cloud-sre, cloud-devops, or cloud-swdev is operationally simple. No separate AI platform, no complicated integration surface, no bespoke hosting layer.
So the end state is simple and powerful: LinkedIn becomes the structured system of record, the DMA API gives me lawful programmatic access to my own data, my scripts convert that data into reusable CV artifacts, and GitHub Models lets me adapt those artifacts quickly for a specific opportunity. One source of truth, multiple outputs, and a much shorter path from updated profile to tailored application.
If you want to build the same thing for yourself, copy the approach or clone the repository and adapt it to your own profile. If you keep your base data detailed enough, you can generate a generic CV once and then tailor it rapidly for specific roles with LLMs instead of rewriting everything by hand each time.
And if you are looking for a practical reason to try it, use it to prepare an application for one of our open positions at Würth IT Italy: Open Job Positions: Apply Now | Würth IT Italy.
If you want to compare notes, ask questions about the pipeline, or just connect, reach out to me on LinkedIn: https://www.linkedin.com/in/francesco-belacca-dev/
Francesco Belacca
Author
