LinkedIn API for Developers: Endpoints, Pricing, Use Cases
A developer's reference to NeuralVerge's LinkedIn endpoints — what each one takes and returns, how pricing works, and where to call it directly vs. as an agent tool.
Published August 12, 2026
If you're integrating LinkedIn data into a product rather than just running a one-off enrichment task, the questions are usually more concrete than "does NeuralVerge support LinkedIn": which endpoint takes which input, what it costs per call, and whether to wire it in directly or expose it as a tool an agent can call itself. This is the developer-facing reference for that — for fully worked scenarios (building an outbound list, scoring an existing one, sourcing candidates), see LinkedIn API for Agents.
NeuralVerge is an independent product and is not affiliated with, endorsed by, or connected to LinkedIn Corporation. LinkedIn is a trademark of its owner. Every endpoint below returns publicly visible profile and company information.
The seven endpoints at a glance
| Endpoint | Input | Returns |
|---|---|---|
| Company profile | A company page URL | Headcount, industry, locations, specialties, jobs, posts |
| Company search | Query plus size/industry/location filters | Matching companies with industry and headquarters |
| Company employee search | One or more company pages, optional filters | People currently listed at that company |
| People profile | A profile URL | Full work history, education, skills, posts |
| People profile + email | A full profile URL | The professional record plus an email where available |
| People search | Query plus title/seniority/company/location filters | Matching people with headline and current company |
| Profile by name and domain | A full name plus a company or domain | The matching profile with headline and company |
Every endpoint returns inside the same outer response envelope used across NeuralVerge's source catalog, so a client that already parses responses from corporate registries or funding databases doesn't need a separate parser for the LinkedIn-sourced ones — only the fields inside differ, because a company profile and a people search genuinely don't contain the same data.
The seven endpoints, in depth
Parameters and response shapes below are as documented on docs.neuralverge.ai; example responses use a fictional company and person (Acme Technologies / Jane Doe) in place of real profile data.
Company profile
Runs through the platform's general-purpose run-extract endpoint rather than a LinkedIn-specific one, parameterized with an instruction describing what to pull.
Input:
- —
url(string, required) — the company's LinkedIn page URL - —
instructions(string, required) — e.g."Extract data from Linkedin company profile" - —
settings(object, optional) —country_code;extract_schema_jsonif you want to pin an exact schema instead of the inferred one
Returns: official name, tagline, full about text, website, primary industry, a headcount band (company_size) and exact employee_count where published, a structured headquarters object, every listed office in locations, declared specialties, follower_count, founded_year, open roles (jobs), and recent posts (posts).
{
"session_id": "c4d7…",
"kind": "extract",
"url": "https://www.linkedin.com/company/acme",
"machine": {
"company_name": "Acme Technologies",
"tagline": "Revenue infrastructure for B2B teams",
"industry": "Software Development",
"company_size": "51-200 employees",
"employee_count": 142,
"headquarters": { "city": "Austin", "state": "TX", "country": "US" },
"specialties": ["CRM", "Sales automation"],
"follower_count": 18450,
"founded_year": 2015,
"jobs": [
{ "title": "Account Executive, EMEA", "location": "London", "employment_type": "Full-time" }
]
},
"total_points": 5
}
The open-roles field is worth building around on its own: a company visibly staffing up a function is a company with budget for it, which is a cleaner signal than most funding data gives you. Billed per company that actually resolves. See linkedin-company-profile.
Company search
Its own dedicated tool — run-linkedin-company-search — not the shared extraction one.
Input:
- —
searchQuery(string, required) - —
companySize,industryIds,locations(arrays of strings, optional filters) - —
maxItems(number, optional) — caps results, and therefore cost - —
scraperMode(string, optional) — response detail level - —
startPage(number, optional) — pagination
Returns: total_items, plus per matching company (in first_item and items): name, url, industry, headquarters, followers, description.
{
"session_id": "2f88…",
"kind": "linkedin_company_search",
"searchQuery": "revenue operations software",
"machine": {
"total_items": 2,
"first_item": {
"name": "Acme Technologies",
"url": "https://www.linkedin.com/company/acme",
"industry": "Software Development",
"headquarters": "Austin, Texas",
"followers": "18450"
}
},
"points_per_company": 5,
"total_points": 10
}
This is the discovery step most other enrichment tools assume you've already done somewhere else — it's how a list of companies gets built in the first place, not how one already-known company gets enriched. Priced per company actually returned, so capping maxItems deliberately matters on a broad query. See linkedin-company-search.
Company employee search
Its own dedicated tool — run-linkedin-company-employee.
Input:
- —
companies(array of strings, required) — one or more company LinkedIn URLs - —
searchQuery,maxResults,startPage,scraperMode(optional) - —
locations,currentJobTitleFilter,pastJobTitle,yearsOfExperienceFilter,yearsAtCurrentCompanyFilter,seniorityLevelFilter,functionFilter,industryIds,companyHeadcountFilter(optional filters)
Returns: total_items, plus per person: firstName, lastName, profileUrl, title, company, location.
{
"session_id": "7a1e…",
"kind": "linkedin_company_employee",
"companies": ["https://www.linkedin.com/company/acme"],
"machine": {
"total_items": 1,
"first_item": {
"firstName": "Jane",
"lastName": "Doe",
"profileUrl": "https://www.linkedin.com/in/jane-doe",
"title": "VP of Sales",
"company": "Acme Technologies",
"location": "Austin, Texas"
}
},
"total_points": 35
}
Treat the result as a well-filtered sample of an organization, not its complete staff list — it's built for account-based work, where the starting point is a known company and the question is who's in it. Priced as a per-run charge plus a per-profile charge, so a run that matches nobody is charged only for the run. See linkedin-company-employee.
People profile
Also runs through run-extract, the same as company profile.
Input:
- —
url(string, required) — the person's profile URL - —
instructions(string, required) — e.g."Extract data from Linkedin people profile" - —
settings(object, optional)
Returns: a basic_info object (name, headline, about, location, current company, an open_to_work flag, follower/connection count, top skills), a complete experience array, education, certifications, languages, and recent posts — each carrying its own engagement object (reactions, comments, shares, impressions).
{
"session_id": "9c2f…",
"kind": "extract",
"url": "https://www.linkedin.com/in/jane-doe",
"machine": {
"basic_info": {
"fullname": "Jane Doe",
"headline": "VP of Sales at Acme Technologies",
"location": { "full": "Austin, Texas" },
"current_company": "Acme Technologies",
"open_to_work": false,
"top_skills": ["Enterprise Sales", "SaaS"]
},
"experience": [
{ "title": "VP of Sales", "company": "Acme Technologies", "duration": "3 yrs" }
],
"education": [{ "school": "State University" }]
},
"total_points": 5
}
The posts and their engagement are what separate this from a plain enrichment record: a title tells you whether to write to someone, what they posted last week tells you what to actually say. See linkedin-people-profile.
People profile + email
Its own dedicated tool — run-linkedin-email.
Input:
- —
username(string, required) — the full LinkedIn profile URL
Returns: basic_info (fullname, headline, profile_url, location, about) plus email where one resolves.
{
"session_id": "11111111-1111-1111-1111-111111111111",
"kind": "linkedin_email",
"username": "https://www.linkedin.com/in/jane-doe",
"machine": {
"total_items": 1,
"first_item": {
"basic_info": {
"fullname": "Jane Doe",
"headline": "VP of Sales at Acme Technologies",
"profile_url": "https://www.linkedin.com/in/jane-doe",
"location": { "full": "Austin, Texas" },
"about": "Enterprise sales leader focused on B2B SaaS."
},
"email": "jane@acme.com"
},
"total_points": 10
}
}
This collapses what's normally two separate steps into one request and one charge: reading the profile, then running an email finder against the resulting domain. The email comes back only when it actually resolves; when it doesn't, the profile record is still returned. See linkedin-people-profile-email.
People search
Its own dedicated tool — run-linkedin-people-search — with the widest filter set in the catalog.
Input (all optional):
- —
searchQuery,maxResults,startPage,scraperMode - —
locations,currentCompany,pastCompany,currentJobTitleFilter,pastJobTitle - —
yearsOfExperienceFilter,yearsAtCurrentCompanyFilter,seniorityLevelFilter,functionFilter - —
industryIds,firstNames,lastNames,companyHeadcountFilter
Returns: total_items, plus per match: firstName, lastName, profileUrl, headline, currentCompany, location.
{
"session_id": "44444444-4444-4444-4444-444444444444",
"kind": "linkedin_people_search",
"searchQuery": "VP of Sales",
"machine": {
"total_items": 3,
"first_item": {
"firstName": "Jane",
"lastName": "Doe",
"profileUrl": "https://www.linkedin.com/in/jane-doe",
"headline": "VP of Sales at Acme Technologies",
"currentCompany": "Acme Technologies",
"location": "Austin, Texas"
},
"points_per_25_results": 100,
"points_per_profile": 5,
"total_points": 115
}
}
Pricing has two parts — a block charge per batch of results plus a per-profile charge — so narrower filters are both cheaper and more useful, an unusually well-aligned incentive compared to most search tools. See linkedin-people-search.
Profile by name and domain
Its own dedicated tool — run-linkedin-domain.
Input:
- —
company_or_domain(string, required) — company name or domain - —
full_name(string, required) — the person's full name
Returns: fullName, profileUrl, headline, companyName, location, summary.
{
"session_id": "22222222-2222-2222-2222-222222222222",
"kind": "linkedin_domain",
"company_or_domain": "acme.com",
"full_name": "Jane Doe",
"machine": {
"total_items": 1,
"first_item": {
"fullName": "Jane Doe",
"profileUrl": "https://www.linkedin.com/in/jane-doe",
"headline": "VP of Sales at Acme Technologies",
"companyName": "Acme Technologies",
"location": "Austin, Texas",
"summary": "Enterprise sales leader focused on B2B SaaS."
},
"total_points": 10
}
}
This is the resolution step that unblocks everything else on this list — once a profile URL exists for someone, both the richer profile lookup and the email lookup become available for them, and it's the shape most real records actually start from, since very few CRM rows or signup forms carry a LinkedIn URL directly. Billed only on a resolved match. See linkedin-profile-by-name-and-domain.
How pricing works
Each endpoint is metered in points rather than charged a single flat rate across all seven — a targeted lookup against a known profile or company costs less than a search endpoint that has to evaluate and return several candidates, since more work happens on NeuralVerge's side for the latter. That scaling is consistent across the catalog, not specific to LinkedIn: a well-defined single lookup costs less than an open-ended search, the same principle that applies to AI research's depth tiers. Billing is also tied to a resolved result — a lookup against a company or profile that can't be found isn't charged the same as one that resolves, so a client doesn't pay for misses the same way it pays for hits. Exact current point costs per endpoint are on each endpoint's data source page and the pricing page rather than restated here, since they're the kind of number that drifts out of sync with what actually gets billed if it's copied into a second place.
Calling it directly vs. as an agent tool
Every endpoint is reachable over plain REST as well as MCP, with the same inputs and the same response shape either way — the choice is about where the decision to call it lives, not about capability. Wiring an endpoint directly into backend code makes sense when you already know a lookup belongs at a specific point in a flow — enriching a record right after it's created, for instance. Exposing the same endpoint as a tool an agent can call makes sense when the agent needs to decide for itself, mid-task, that it needs a specific piece of LinkedIn data — checking whether a person still holds a given title before making a claim about them, for instance — rather than having that decision hard-coded into a fixed pipeline.
Use cases: a quick tour
- —Lead and account enrichment. A signup or CRM record usually has a company name and a contact name, not a LinkedIn URL. Resolving both and pulling current firmographics and title turns a raw form submission into a record a sales team can actually route on, rather than working from whatever the form happened to collect.
- —Recruiting and sourcing. Searching for candidates against real filters — title, seniority, industry, location — surfaces people before they'd otherwise turn up in an applicant pipeline, and enriching each match with current tenure fills in the qualification detail a recruiter needs before reaching out.
- —Org mapping. Before an outreach to a target account, listing who currently works there — filtered by title where it matters — turns "who do we talk to" from a guess based on a generic contact address into an actual short list of people.
- —Data hygiene. Contacts already sitting in a CRM go stale the same way any people data does. Re-running profile lookups against existing contacts on a schedule catches a job change directly, rather than waiting for a bounced email to reveal it.
Each of these is covered as a fully worked, step-by-step scenario — including which specific endpoints to chain together and in what order — in LinkedIn API for Agents.
About NeuralVerge
NeuralVerge gives developers and AI builders a single API for AI deep research, AI extraction, and autonomous agents — powered by 29 data sources under the hood.
Data Sources on the NeuralVerge blog.
Try it on your own data
One request format across research, extraction, and enrichment.