LinkedIn Profile API: What It Returns and What It Does Not

• The official LinkedIn Profile API returns data about the authenticated member only. LinkedIn's own docs say you may never store profile data for anyone else.
• Without a partner agreement you get four fields: id, first name, last name, profile picture. Headline, company, title, experience and skills all sit behind partner approval.
• Everything else on the market is a workaround: third-party data providers, or APIs driving a LinkedIn account you own. Both carry risk, and one of the biggest providers was shut down in 2025.
• Pricing in this guide was read on each vendor's own page on 9 August 2026.

Almost everyone who searches for the LinkedIn Profile API wants the same thing: give it a profile URL, get back a job title, a company, an email. The official API does not do that, and it has never done that. It returns information about the person who just logged into your app, and nothing about anyone else.

That single distinction explains the entire market that grew around it, the lawsuits that followed, and why one of the best-known providers disappeared in 2025. This guide covers exactly what the official endpoints return, what the alternatives are with prices checked this week, where the legal line falls, and how to read a profile through an account you actually control.

What does the official LinkedIn Profile API return?

Two endpoints matter, and neither behaves the way the phrase LinkedIn Profile API suggests. The classic one is a single call against the documented Profile API, and the restriction sits right there in LinkedIn's own documentation: you may only store data for the authenticated member, and you may never store profile data for members other than that person. Not a rate limit, not a pricing tier. A prohibition.

curl https://api.linkedin.com/v2/me \
  -H "Authorization: Bearer {access_token}"

# Default response fields with r_liteprofile:
#   id, firstName, localizedFirstName,
#   lastName, localizedLastName, profilePicture

That list is complete. No headline, no current company, no job title, no location, no experience, no skills. LinkedIn splits its profile fields into two groups, and the split is the whole story:

Read that table next to whatever you were planning to build. Every field a prospecting, recruiting or enrichment workflow actually needs sits in the bottom four rows, and the LinkedIn Profile API will not hand them to a self-serve application no matter how you structure the request. The gap between row one and the rest is the entire reason a third-party market exists.

What most developers actually hit: /v2/userinfo

Since LinkedIn deprecated the first version of Sign In with LinkedIn on 1 August 2023, the self-serve path runs through OpenID Connect. One endpoint replaces the old profile and email calls:

curl https://api.linkedin.com/v2/userinfo \
  -H "Authorization: Bearer {access_token}"

# Scopes available self-serve: openid, profile, email
# Response: sub, name, given_name, family_name,
#           picture, locale, email, email_verified

This is a sign-in product, not a data product. It is excellent at letting someone log into your app with LinkedIn and at prefilling a name and an avatar. LinkedIn even warns that it does not verify user identities and should not be marketed as if it did. If your feature is authentication, stop reading: this is the right tool and it is free.

If you are maintaining older code

Integrations written before August 2023 usually call two endpoints: the profile call with the r_liteprofile scope, and a separate email call with r_emailaddress and a projection expression. Both were deprecated with the first version of Sign In with LinkedIn. The migration is small and mechanical: request the openid, profile and email scopes instead, call the userinfo endpoint once, and read the standard OpenID claims. If a LinkedIn Profile API integration in your codebase silently stopped returning emails at some point, this is almost always why.

One thing that did not change with the migration is the boundary. OpenID Connect made the sign-in flow cleaner; it did not open any door to third-party data. If anything it made the scope of the official product more explicit, because the three self-serve scopes are now spelled out in a public discovery document that lists nothing else.

Can you get another person's profile officially?

There is an endpoint shape for it, and in practice it is a dead end. Fetching another member requires their Person ID, which LinkedIn says is available only through limited-access APIs, and that ID is scoped to your application: share it with another app and you get a 404. Even then, it returns nothing for members who have limited their off-LinkedIn visibility, and the fields you would want stay behind partner approval.

I went through the entire developer product catalog looking for an exception. Sales Navigator's partner program is the closest thing, and LinkedIn states it is not currently accepting new partners; even for existing ones it renders profiles in an embedded UI rather than returning JSON, as our Sales Navigator API guide covers in detail. The Talent products are recruiting-system integrations. Member Data Portability returns a member's own data, with their consent, in Europe only. Nothing in the catalog hands you an arbitrary profile.

The cautionary tale nobody in this search result mentions

For years, the default answer to this question was Proxycurl. Then LinkedIn sued its operator in January 2025, and on 4 July 2025 the founder published a post whose second sentence is six words long: today, we are shutting Proxycurl down. His reasoning is worth reading in full, but the line that stays with you is that there is no winning in fighting this, because even a successful defence against a Microsoft-backed plaintiff costs more than the business is worth.

Check the domain today and the story continues: proxycurl.com now redirects to enrichlayer.com, a service selling the same shape of product, whose documentation includes a Transition Guide, linked as "Migrating from Proxycurl", that maps the old base URL to the new one. That domain was registered in April 2025, between the lawsuit and the shutdown, and its terms of use name Vertical Int, Inc., a Wyoming corporation, as the operator. I am reporting what is observable, not asserting any connection between the two businesses. Draw your own conclusion about what that means for a dependency at the centre of your product.

The practical lesson is not that data providers are evil. It is that a profile-data pipeline can vanish on a court date, and if your feature depends on one, your feature vanishes with it. That risk belongs in the build-versus-buy conversation from the start, not in the postmortem.

There is a practical test worth running before you sign with any LinkedIn Profile API vendor. Ask where the data comes from, and listen for whether the answer involves accounts. A provider querying its own historical dataset has a different risk profile from one performing live lookups, which is different again from one operating accounts it created itself. The third shape is what LinkedIn's complaint against Proxycurl described, and it is the one that ends businesses. Ask also what happens to your workflow if they stop tomorrow: a vendor with a real answer has thought about it, and a vendor without one has told you something.

The routes that actually exist in 2026

Strip away the marketing and there are three shapes, each with a different failure mode. Prices below come from each vendor's own pricing page, read this week:

Two of those rows deserve a note. The data providers hold a copy of the data and query it for you, which is fast and works without any LinkedIn account; our review of LinkedIn scraper APIs goes vendor by vendor. And the opaque ones are worth flagging as opaque: when Coresignal, Bright Data and Unipile all publish real numbers, a competitor that publishes none is telling you something about how the negotiation will go.

Reading a profile through an account you control

The account-based route deserves a concrete example, because it behaves differently from everything above. On the Swarmhit API, a profile lookup runs from a sender account you connected, addressed by the public identifier in the URL:

curl "https://app.swarmhit.com/api/v1/accounts/ACCOUNT_ID/profiles/john-doe" \
  -H "Authorization: Bearer swh_live_..."

# The identifier is the username in linkedin.com/in/<identifier>

One detail here matters more than it looks: this is a silent read. No profile view is registered, the target sees nothing, and it consumes no daily cap. That is the opposite of the visit endpoint on the same account, which deliberately registers a real view because that view is itself the outreach signal. Most articles about profile data never make this distinction, and it is the one that decides whether a lookup is a research action or a marketing action.

If you need data at volume rather than one profile at a time, the same API exposes a database, sourced through third-party data providers, that runs entirely server-side, with no connected account and no LinkedIn action limits:

curl -X POST https://app.swarmhit.com/api/v1/database/people/enrich \
  -H "Authorization: Bearer swh_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "linkedinUrl": "https://www.linkedin.com/in/jane-doe",
    "includeEmail": true
  }'

That returns the profile fields plus summary, connections, followers, skills and websites, and with the email flag a list of verified business emails at a higher credit cost. Results are transient until you add the person to a list or a campaign. The reason this pairing exists is that most teams asking for profile data do not want a database: they want to start a conversation, which is what the messaging endpoints on the same account are for.

Where the legal line actually falls

Two cases define the ground, and most summaries get them half right. In hiQ Labs v. LinkedIn, the Ninth Circuit concluded in 2022 that scraping publicly available data does not violate the Computer Fraud and Abuse Act, in a decision affirming a preliminary injunction rather than ruling on the merits. That reading stands. What people forget is the ending: later that year a district court found hiQ had breached LinkedIn's User Agreement, and in December 2022 the parties entered a consent judgment with a permanent injunction and $500,000 in damages. hiQ won the criminal-statute question and lost the contract question, which was enough to end the company.

Proxycurl in 2025 is the same pattern with an aggravating factor: LinkedIn's complaint alleged the creation of fake accounts to do the scraping, which is a separate violation from scraping itself. That case ended in a settlement rather than a ruling on the merits: in July 2025 the court entered a permanent injunction requiring Proxycurl to delete the LinkedIn data it had obtained by unauthorised means.

One clause in the User Agreement deserves your attention if you plan to buy your way around the problem. It prohibits using or distributing information obtained from the service "whether directly or through third parties (such as search tools or data aggregators or brokers), without the consent of the content owner". Buying a dataset does not automatically place you outside the agreement you accepted when you created your account. None of this is legal advice, and your jurisdiction and use case matter, but it is the reason our own position is that automation runs through accounts our customers own, with no cookie-less scraping, which we consider illegal, and no data resale.

Which route should you pick?

Start from what your product does with the data. If you need a name and a photo to complete a signup, the official LinkedIn Profile API through OpenID Connect is the right answer and you can stop there: it is official, free, and permanent. If you are enriching a CRM at scale and never touch LinkedIn as an actor, a data provider with published pricing is the honest fit, sized so that losing that vendor is survivable.

If the profile lookup is a step inside outreach, which it usually is, the account-based route is the one that matches what you are actually doing: your customers' accounts, your customers' network, actions attributable to a real person. Compare the shapes in our Unipile comparison, and if you would rather buy a tool than build on an API, start from the prospecting tools guide.

Whatever you choose, price the dependency risk explicitly. The teams that got hurt in 2025 were not the ones who picked the wrong vendor; they were the ones who built a core feature on a single provider with no fallback. For the wider landscape, our LinkedIn API guide maps every access route, and our outreach API comparison scores the platforms you can build on.

FAQ

Can the LinkedIn Profile API return someone else's profile?

No, not in any practical sense. The documentation states you may never store profile data for members other than the authenticated one. The third-party endpoint requires a Person ID that is scoped to your own application and only reachable through limited-access programs.

What fields does the free LinkedIn Profile API give me?

Four: id, first name, last name, and profile picture, plus localized name variants. Headline, position, company, education, location and skills are Partner Program fields, not self-serve ones.

Is Proxycurl still available?

No. Its operator announced the shutdown on 4 July 2025 following a lawsuit filed by LinkedIn in January 2025. The proxycurl.com domain now redirects to a different service that publishes a Proxycurl migration guide.

Is it legal to get LinkedIn profile data through an API?

Courts have held that scraping public data does not violate the Computer Fraud and Abuse Act, but LinkedIn's User Agreement is a separate matter and it is what ended hiQ with a consent judgment. The agreement also covers data obtained through aggregators and brokers. This is not legal advice; ask a lawyer about your specific use case.

How do I look up a profile without the person knowing?

Through a connected account, a profile lookup is a silent read: no view is registered and no daily cap is consumed. That is different from a profile visit, which deliberately shows up in the target's notifications because the view is itself an outreach signal.