LinkedIn API for Agents: Profiles, Companies & Signals at Scale

Sales and recruiting workflows both run into the same wall eventually: you have a list of company names or people, and the useful context about each of them — current headcount, current title, recent company growth — lives on LinkedIn, one profile at a time. Opening each profile by hand does not scale past a handful of rows, and it turns a ten-minute research task into an afternoon once the list grows past a few dozen names. A LinkedIn API is what turns that manual lookup into a call your pipeline or agent can make automatically, at whatever volume the workflow actually needs.

NeuralVerge is an independent product and is not affiliated with, endorsed by, or connected to LinkedIn Corporation. LinkedIn is a trademark of its owner. Everything below describes publicly visible profile and company information, not data from LinkedIn's own partner APIs.

What is a LinkedIn API for agents and pipelines?

A LinkedIn API takes a known company or person — a name, a URL, a domain — or a set of search filters, and returns the publicly visible profile data as structured JSON: headcount and industry for a company, current title and tenure for a person. It's worth placing next to two things people reach for instead.

LinkedIn API vs. a general people-data API

A broader people-data API aggregates signals from many sources — public records, other social networks, data brokers — into one composite profile, which is useful when you need the widest possible coverage on a person and don't care which source backed which field. A LinkedIn API is narrower on purpose: it returns exactly what's on the professional profile itself — current employer, title, and history as the person has published it — which is the specific signal that matters for sales and recruiting workflows, without folding in data from sources that may be less current or less relevant to a professional-context question.

LinkedIn API vs. scraping LinkedIn yourself

Building a scraper against LinkedIn's own pages directly means maintaining selectors against a site that changes its markup regularly and runs active anti-automation defenses — a combination that makes a homegrown scraper considerably more fragile than one built against almost any other site. It also means taking on the compliance and terms-of-service exposure of automating against the site directly, rather than going through a maintained source built to keep working as the underlying pages change. A LinkedIn API absorbs that maintenance burden rather than passing it on to every team that needs the data.

Every LinkedIn endpoint NeuralVerge exposes

"LinkedIn data" isn't one lookup — it's seven distinct endpoints, each built for a different starting point and a different shape of answer. Picking the wrong one for what you actually have on hand is the most common way this kind of integration ends up returning sparse or missing fields.

Company profile

Takes a LinkedIn company page URL and returns a full firmographic snapshot: official name, tagline, the complete about text, website, industry, headcount band and exact employee count where published, headquarters and every listed office location, specialties, follower count, founding year, plus open roles and recent posts. Use it when you already know which company you're looking at and need the complete picture, not just a headline number. See linkedin-company-profile.

Company search

Takes a search query with optional size, industry, and location filters, and returns matching companies with industry, headquarters, follower count, and a short description for each. Use it when you don't have an exact company page yet — you're resolving an ambiguous name, or building a list of companies that match a set of criteria rather than looking up one you already know. See linkedin-company-search.

Company employee search

Takes one or more company pages, with optional filters on the people themselves, and returns everyone currently listed as working there — name, profile URL, title, and location. Use it when the question is "who works at this account," whether that's mapping a target account before outreach or scoping how a team is structured. See linkedin-company-employee.

People profile

Takes a profile URL and returns the full professional record: current company, location, open-to-work status, follower count, top skills, complete work experience, education, certifications, languages, and recent posts with engagement. Use it when you already have a specific person and need their complete history, not just a current title. See linkedin-people-profile.

People profile + email

Takes a full profile URL and returns the same professional record — name, headline, location, about text — plus an email address where one is publicly available. Use it when the next step after enrichment is actually reaching the person, not just knowing who they are. See linkedin-people-profile-email.

People search

Takes a search query with title, seniority, company, and location filters, and returns matching people with their profile URL, headline, current company, and location. Use it when you don't have specific people yet — you're building a candidate or lead list from criteria rather than starting from known names. See linkedin-people-search.

Profile by name and domain

Takes a full name plus a company name or domain and returns the matching profile — name, headline, company, location, and summary. Use it when all a workflow has is a name and where they work, with no LinkedIn URL at all — which is the normal starting point for a signup form or a CRM record. See linkedin-profile-by-name-and-domain.

Every one of these seven calls returns inside the same response envelope used across NeuralVerge's source catalog, so a pipeline that also pulls from corporate registries or funding databases doesn't need a separate parser just for the LinkedIn-sourced fields — and a field that isn't publicly listed on a profile comes back empty rather than filled in with a plausible guess.

What you get back

Regardless of which of the seven endpoints you call, the response is typed JSON built to be consumed by code — never a block of profile text you'd have to parse yourself. Fields that don't apply to a given lookup type simply aren't present, rather than returned empty across the board, so a pipeline that branches on company versus people data can rely on the shape it gets back matching the endpoint it called.

A worked example: sales lead search

Take a concrete, illustrative case: a sales team wants a fresh list of outbound targets matching an ideal customer profile — say, software companies of 50-200 people in a specific region — rather than working from a purchased list of unknown accuracy.

1. —A company search call with industry, size, and location filters returns a first pass of candidate companies matching the profile, each with a follower count and short description to sanity-check the match before spending another call on it.
2. —A company profile call against each candidate that looks promising fills in the exact employee count, headquarters, and specialties — the detail needed to confirm real fit rather than trusting the search filters alone, since a company can drift outside a size band by the time a profile actually gets read.
3. —A company employee search call against the confirmed accounts, filtered by title, surfaces the people who actually hold budget for what's being sold — not a generic "sales" title, but the specific seniority and function that matches the ideal buyer.
4. —The result is an outbound list built from real, current criteria — company fit confirmed, the right person identified — instead of a spreadsheet of guesses or a list that was accurate when it was purchased and stale by the time it's worked.

A worked example: lead scoring

A second, distinct case: an existing lead list — inbound signups, a purchased list, a CRM export — needs to be prioritized before an SDR spends time on it, rather than worked in the order it arrived.

1. —For each lead's company, a company profile call returns headcount, industry, and open roles — company size and industry confirm whether the account fits the target segment at all, and a company that's visibly hiring is a weak but real signal of growth worth weighing.
2. —For each lead's contact, a profile by name and domain call resolves the exact person from just a name and a company domain, which is usually all a signup form or a CRM record actually has.
3. —A people profile call against that resolved contact returns their current title and tenure — a title that matches a decision-maker persona and tenure long enough to plausibly hold budget authority both push a lead up; a title that doesn't match the buyer persona, or a person who joined last month, both push it down.
4. —Combining company fit and contact fit sorts the list into rough tiers — high, medium, low — rather than pretending to a single precise score the underlying signals don't actually support. An SDR working top-down through a tiered list built on real, current data spends time where it's actually likely to convert, instead of working the list in the order it happened to arrive.

A worked example: recruiting

A third case: sourcing candidates for an open role, where the goal is a continuously fed pipeline rather than a one-time keyword search.

1. —A people search call filtered by title, seniority, industry, and location returns a pool of matching candidates — the starting list, built from criteria rather than from whoever happened to apply.
2. —A people profile call against the strongest matches returns full work history, tenure, and an open-to-work signal where a candidate has set one — tenure patterns distinguish someone likely to consider a move from someone who just started a role, and an explicit open-to-work flag is worth weighing more heavily than either.
3. —A company employee search call against specific target companies — competitors, or companies known to run a similar function well — surfaces additional candidates who wouldn't turn up from title keywords alone, because their public headline doesn't happen to use the exact words being searched for.
4. —Because every call here is a live lookup rather than a one-time export, the same searches can run on a schedule, so the candidate pool refreshes automatically instead of going stale the moment the initial search was run.

What to check before you use a LinkedIn API

• —Does it return current data, or a stale cached copy? A profile read at request time reflects reality; a database snapshot ages the moment it's written and only gets worse from there.
• —Does it handle name ambiguity, or assume the first match is correct? "Acme" resolving to the wrong "Acme," or "Jane Smith" resolving to the wrong Jane Smith, quietly poisons every enrichment downstream of it.
• —What does it return for private or missing profiles? An honest empty result is worth more than a plausible-sounding guess that looks complete but isn't grounded in anything real.
• —Does it separate company and people lookups cleanly? If a single generic call is expected to handle both, check what actually comes back for each — a shape built for one often returns sparse fields for the other.
• —Can you resolve a profile without already having its URL? A workflow that only ever has a name, a company, or a domain needs an endpoint built for that starting point, not just a lookup that assumes you already found the profile yourself.

Enrichment like this is one piece of a larger research problem — for how a fuller pipeline plans, cross-checks, and cites an answer across many sources at once rather than one lookup at a time, see what an AI deep research API does.

Frequently asked questions

Is this data pulled directly from LinkedIn's own API?

No. NeuralVerge is an independent product and is not affiliated with, endorsed by, or connected to LinkedIn Corporation. LinkedIn is a trademark of its owner. The endpoints described here return publicly visible profile and company information.

How fresh is the data?

Profiles are read at request time, so a lookup reflects whatever is publicly visible on the profile when you call it — it isn't served from a database snapshot that ages between calls.

What happens for a person or company with no public profile?

The lookup returns nothing to report for that field rather than a guess. Private profiles, very new accounts, and some smaller companies simply don't have public data to return.

What's the difference between company employee search and people search?

Company employee search starts from a known company and lists people who currently list it as their employer — useful for mapping an org. People search starts from filters like title and industry and finds people across companies — useful for building a list of candidates or leads you don't already have names for.

Can I look someone up by name and company instead of a LinkedIn URL?

Yes — the profile-by-name-and-domain endpoint resolves a profile starting from a name plus a company or domain rather than requiring an exact LinkedIn URL up front, which matters when all a workflow has is a name from a signup form or a CRM record.

Which endpoint should I call if I only have an email address?

Start with whatever the email tells you — usually a company domain — and work forward: a company search or company profile call against that domain, then a people search or profile-by-name-and-domain call once you have a name to pair with it. There isn't a single "look up by email" endpoint, because an email address alone doesn't reliably resolve to one profile.