LinkedIn’s profile API can return only the member data that LinkedIn makes available to the specific app and that the signed-in member has authorized. For most apps, that means basic profile details such as a member’s name, profile photo, and—when permission is granted—email address; it does not provide unrestricted access to someone’s full profile, connections, or activity.
What the LinkedIn profile API can return
The available fields depend on the API product, permissions granted to the application, and the member who authorizes it. A typical sign-in integration requests a limited set of identity fields, rather than downloading everything visible on LinkedIn.
- Basic identity: A member’s name and LinkedIn identifier may be available through the applicable sign-in product and permissions.
- Profile photo: A profile picture may be returned when the API and authorization scope support it.
- Email address: This is a separate permission in relevant products. It should not be assumed to be available just because a member signed in with LinkedIn.
- Additional profile fields: Some approved products or partner integrations can access further fields, but availability is governed by the product’s documentation, app approval, and granted permissions.
Field names and response formats can change between API versions. Developers should use the current documentation for the product they have access to, rather than rely on old examples that mention fields such as headline, location, or employment history as if every app can request them.
Why access is limited
LinkedIn does not offer a general-purpose endpoint that lets any developer retrieve arbitrary members’ complete profiles. Its APIs are permissioned: an app must use an available product, obtain the required approval where applicable, and receive authorization from the member for the requested data. A profile being visible on the public website does not automatically make its contents available through an API.
This distinction matters because older tutorials and code samples may describe API access that is no longer generally available. LinkedIn has changed its API products and access policies over time. A sample that once worked, or a field shown in another company’s integration, is not proof that a new application can request the same data today.
How authorization works
For a member-authorized integration, the usual flow uses OAuth 2.0. The app sends the member to LinkedIn to sign in and approve requested permissions. LinkedIn returns an authorization code to the app, which exchanges it for an access token. The app then calls the permitted API endpoints using that token.
- Create or configure an app in LinkedIn’s developer environment and select an API product available to that app.
- Request only the permissions required for the feature, using the authorization flow specified in current documentation.
- Have the member sign in and grant the requested access. A member can decline, and permission may later be withdrawn.
- Use the resulting token only for allowed endpoints and data, and handle expiration or revocation as documented.
- Request and display only the fields the app actually needs; explain their use in the app’s privacy information.
OAuth permission is not a universal data pass. A valid token only authorizes the scopes and resources associated with that token, and the app must still have access to the relevant API product.
What you generally cannot retrieve
Developers should not expect the profile API to provide a member’s entire profile or LinkedIn account data. In particular, access to connections, private contact details, full work and education history, posts, messages, or other members’ profile data is not generally included in basic sign-in access. Some data may be available through a separate, restricted product or approved partner arrangement, but that is not equivalent to open access.
Scraping profile pages or trying to reproduce unavailable API access is not a reliable substitute. It can conflict with LinkedIn’s terms and technical controls, and may create privacy and compliance risks. If a required field is not available in the product documentation for your app, design the feature around data the member can supply directly or another authorized source.
Choosing the right integration
Start with the user outcome, not a list of profile fields you hope to collect. For example, an app that needs to identify a member can often use basic sign-in information; a recruiting or sales workflow that needs detailed employment data may require a different approved product or a user-provided input process.
- Check product eligibility: Confirm the API product is available to your app and whether review or partner approval is required.
- Verify each field: Look up the current endpoint, permission scope, and response schema for every value you plan to use.
- Plan for missing values: Members may not grant optional permissions, and a field may be absent or unavailable.
- Minimize retention: Keep only data needed for the stated feature and follow the applicable platform requirements and privacy obligations.
- Test the real authorization flow: A developer’s own account or a previous token may not represent what a new member or production app can access.
Common problems and misconceptions
“The profile is public, so the API should return it.” Website visibility and API permission are separate. An API response is governed by product access and authorization, not simply by what a person can see in a browser.
“Sign-in gives the app every profile field.” Sign-in confirms an identity within the permitted scope; it does not grant access to all profile content. Ask for additional permissions only when supported and needed.
“A missing field means the request is broken.” The field may not be included in the product, scope, member’s data, or current API version. Check the response, granted scopes, and documentation before changing code.
Other frequent issues include using an outdated endpoint, requesting a scope the app has not been approved for, sending an expired token, or expecting a permission to apply to a different API product. Error messages and available developer-console details can help distinguish authorization failures from unsupported fields.
Frequently Asked Questions
Can I get someone’s full LinkedIn profile through the API?
No, not through general profile access. Available fields are limited by the API product, app approval, and member authorization.
Can the LinkedIn API return email addresses?
An email address may be available when the relevant product and permission support it and the member authorizes access. It is not guaranteed for every integration.
Can I retrieve connections or followers?
Do not assume basic profile access includes connections or followers. These are restricted data areas, and access depends on specific products and permissions.
Does LinkedIn provide headline and job history to every app?
No. Those fields are not universal entitlements for ordinary sign-in apps. Check the current documentation and your app’s approved access.
What should I do if a profile field is unavailable?
Confirm the endpoint, product, scope, and app approval. If the data is not offered to your app, ask the member to provide it directly or redesign the feature without it.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.
More cards in this drawer
- Wireless Controller Charging: Can You Play While Plugged In?
- Secure a Node.js API: Layered Checklist
- Zoom Desktop Client: Features, Setup, and Fixes
- Python Integer Identity: Why It Varies by Run
- Can Technology Solve Poverty? Facts & Limits
- Cannot Detect Device? Fixes for USB & Bluetooth