LinkedIn API for Developers: Endpoints, Inputs, Use Cases

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 returns, 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 five endpoints at a glance

Every endpoint returns inside the same outer response envelope used across NeuralVerge's source catalog, so a client that already parses responses from other data sources doesn't need a separate parser for the LinkedIn-sourced ones — only the fields inside differ, because a company search and a people search genuinely don't contain the same data.

If you're weighing these endpoints against a B2B contact and company database's API, the main difference is where the data comes from: every call here reads the public profile at the moment you make it rather than returning a stored copy.

The five 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 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
• —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"
    }
  }
}

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. 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"
    }
  }
}

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. See linkedin-company-employee.

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"
    }
  }
}

This collapses what's normally two separate steps into one request: 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"
    }
  }
}

Narrower filters return a shorter, more relevant list, which is usually what a pipeline wants anyway. 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."
    }
  }
}

This is the resolution step that unblocks everything else on this list — once a profile URL exists for someone, the people profile + email lookup becomes 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. See linkedin-profile-by-name-and-domain.

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.

Either way, the LinkedIn endpoints share a key and an envelope with the rest of the catalog: email finding, validation and reverse lookup, phone enrichment, corporate registry records read with AI extraction, and cited AI research, with a session id on every call.

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.

Frequently asked questions

How do I authenticate against these endpoints?

With a bearer token in the Authorization header, the same as every other NeuralVerge endpoint — there's no separate auth scheme for the LinkedIn-sourced endpoints specifically. Generate a key from the app dashboard.

Do all five endpoints return the same response shape?

They share the same outer response envelope used across the source catalog, but the fields inside differ by endpoint, since a company search and a people search return genuinely different data. Check the specific endpoint's field list rather than assuming one shape covers all five.

What happens if I call an endpoint against a private or missing profile?

The relevant fields come back empty rather than filled in with a guess. Build error handling around "nothing found" as a normal, expected response, not an exception case.

Is there a rate limit I need to design around?

Check the Errors and Rate Limits page on docs.neuralverge.ai for current limits. Each data source call is synchronous, and a run that hits its time budget returns partial: true with the records collected so far rather than failing.

Can I call these as MCP tools instead of REST endpoints?

Yes — every endpoint on this page is reachable over MCP as well as REST (as the run_linkedin_* tools), using the same input parameters and returning the same response shape either way.

How do I disambiguate a common name in search results?

Pass whatever secondary signal is actually available — a domain, a location, a company name alongside a person's name — to any endpoint that accepts one. Search and resolution endpoints use it to narrow ambiguous matches; without it, a common name can resolve to the wrong person or company.