LinkedIn Profile Finder API: How It Works and When to Use It

A CRM record, a signup form, or an inherited spreadsheet almost never comes with a LinkedIn profile URL attached — it comes with a name and a company, and nothing to click on. A LinkedIn profile finder API closes exactly that gap: given a full name and a company name or domain, it resolves the matching professional profile, unblocking every richer lookup — full work history, an email address — that needs a profile URL as its starting point.

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 endpoint described here returns publicly visible profile information.

How the LinkedIn profile finder API works

NeuralVerge's LinkedIn profile by name and domain source takes exactly two inputs — a full name, and a company name or domain — and returns the matching profile: name, profile URL, headline, company, location, and a summary. It's the resolution step specifically built for the most common starting point a real record actually has: not a URL, but a name and where someone works.

curl -X POST https://api.neuralverge.ai/functions/v1/run-linkedin-domain \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_or_domain": "acme.com",
    "full_name": "Jane Doe"
  }'

import requests

response = requests.post(
    "https://api.neuralverge.ai/functions/v1/run-linkedin-domain",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"company_or_domain": "acme.com", "full_name": "Jane Doe"},
)
print(response.json())

Both parameters are required. company_or_domain accepts either a company name or a domain — the domain is the more precise of the two, since company names are ambiguous across subsidiaries and similarly-named companies in different markets, while a domain usually isn't.

What a resolved match returns

{
  "session_id": "4f6a1c92-8b3d-4e17-9a05-2c6f8d1b3e70",
  "kind": "linkedin_domain",
  "company_or_domain": "acme.com",
  "full_name": "Jane Doe",
  "human": "Matched Jane Doe at Acme Technologies.",
  "machine": {
    "total_items": 1,
    "first_item": {
      "fullName": "Jane Doe",
      "profileUrl": "https://www.linkedin.com/in/example",
      "headline": "Head of Revenue Operations",
      "companyName": "Acme Technologies",
      "location": "Austin, Texas",
      "summary": "…"
    }
  },
  "total_points": 10
}

total_items tells you how many candidates matched — normally one for a well-qualified name and domain — and first_item carries the resolved profile. The call is priced at 10 points per matched profile, $10 per 1,000, and an unresolved name isn't billed at all.

What this endpoint doesn't do — and why that's the point

This is deliberately a narrow, single-purpose lookup, not a general search. It doesn't return a list of candidates to browse through, doesn't accept fuzzy or partial names, and doesn't work without a company qualifier — sending just a name with no company returns nothing useful, because the endpoint is built to resolve one specific person, not to search broadly. That narrowness is what makes it fast and precise for the job it's built for: turning a name-and-company pair you already have into the one profile it actually refers to.

Handling an ambiguous or stale match

Two situations are worth planning for explicitly, since neither is a failure of the lookup itself.

Common names. "Jane Doe" at a company with thousands of employees can, in principle, match more than one person. The company qualifier does most of the disambiguating work, but it's worth checking the returned headline and location against what you already expect before treating a match as certain — especially before using it to trigger an action like a send or a CRM update.

Job changes. Someone who's recently moved to a new employer may not match against the old company at all, or may match showing their new one. Neither outcome is wrong — both tell you something real: the record you're holding predates a job change, which is itself a useful signal for a CRM record that hasn't been touched in a while.

A worked example: recruiting sourcing from a spreadsheet of applicants

A second, distinct case: a recruiter has a spreadsheet of applicants — full names and the companies they currently work at, pulled from resumes — with no LinkedIn links attached to any of them.

1. —For each row, a profile by name and domain call runs against the applicant's full name and their listed employer, resolving a profile for every candidate whose name-and-company pair matches a public one.
2. —Rows that don't resolve get flagged rather than dropped — a common name at a very small company, or someone whose employer field was entered inconsistently, are both real reasons a match might fail without meaning the candidate doesn't have a profile at all.
3. —For resolved candidates, the returned headline gives the recruiter a fast sanity check against the resume's stated title before spending time on a deeper profile review.
4. —What started as an unlinked spreadsheet becomes a working candidate list with a verifiable profile attached to each resolved row, ready for the recruiter's own judgment on who to review first.

Batch considerations: running this across a real list

A single lookup proves the mechanism works; a list of any real size surfaces how it behaves on messy, inconsistent data. Before wiring this into a recurring pipeline, run it against a real batch — not a hand-picked clean sample — and track two things directly: the overall match rate, and how often a match's headline or location looks inconsistent with what the record already claimed. Match rate varies meaningfully by how the input data was collected — names and companies typed by hand tend to resolve less reliably than ones pulled directly from a verified source like an email domain, simply because typos and inconsistent company naming are more common in hand-entered data.

It's also worth deciding, before running this at volume, what the pipeline does with an unresolved name. Silently dropping a non-match loses a real record that might just need a different qualifier — a domain instead of a typed company name, for instance — while treating every miss as worth a retry can turn a bounded batch job into an open-ended one. A reasonable middle ground: retry once with a domain if only a company name was tried the first time, then treat a second miss as final for that run.

Where this fits in a larger enrichment pipeline

Resolving a profile URL is rarely the end goal — it's the step that unblocks everything richer that needs one. Once a profile URL is in hand, people profile returns full work history, tenure, and skills; people profile plus email adds a publicly available email where one exists. A pipeline enriching a raw list of names and companies typically chains this resolution step first, then only runs the richer, more detailed lookups against records that actually resolved — rather than running every lookup against every record regardless of whether a profile was ever found.

A worked example: enriching a signup with only a name and a work email

Take a concrete, illustrative case: Acme Oy (Finland) produces a new signup with a name and a work email address, and nothing else — no LinkedIn URL, no title, no context.

1. —The email domain gives the company qualifier directly — acme.com — pairing naturally with the signup's full name as the two inputs this endpoint needs.
2. —A profile by name and domain call against those two inputs resolves the matching profile, returning a headline and location that confirm the match looks right before anything downstream trusts it.
3. —With the profile URL now in hand, a follow-up people profile call pulls the person's full work history and tenure, giving a rep real context before a first outreach message.
4. —Because the resolution step only bills on a match, running it against every incoming signup — including the ones that don't resolve to a public profile — costs nothing for the misses.

What started as a bare name and an email address becomes a resolved, enriched lead, through a small chain of calls that only runs the expensive, detailed lookup once the cheap resolution step confirms there's a real profile to enrich.

Exposing this as an agent tool

Both REST and MCP reach the same underlying source, which matters specifically for an agent that doesn't know in advance which of its facts will turn out to need a profile resolved. A sales or recruiting agent working a task mid-conversation — reading a lead record, drafting outreach, checking a claim about someone's background — can call this tool the moment its own reasoning recognizes it has a name and a company but no profile URL, rather than a developer having pre-fetched every profile a task might conceivably need before the conversation even started.

The tool's description matters here the way it does for any agent-facing tool: describing it as "resolve a LinkedIn profile from a full name and a company or domain — use this when you have a name and an employer but no profile URL" tells an agent precisely when to reach for it, rather than leaving the agent to guess whether this is the right tool for a partially-known contact. A vague description risks an agent skipping the call entirely and reasoning about a person without ever resolving who they actually are.

Where teams use a LinkedIn profile finder

• —Enriching a name-and-company list, which is the most common shape an imported or purchased list actually arrives in — resolved to real, checkable profiles rather than left as unlinked rows.
• —Unblocking downstream lookups, since richer profile and email sources need a profile URL as their starting input, not a name.
• —Verifying a contact still works where a record says they do, since a match that surfaces a different company than expected is itself the answer to that question.
• —Deduplicating records, resolving several spellings or variants of the same person's name onto the one profile they actually correspond to.
• —Agent-driven resolution mid-task, where an agent that only has a name and an employer calls this to get a profile URL before reasoning further about that person.
• —Recruiting sourcing from applicant data, turning a spreadsheet of names and current employers pulled from resumes into a working candidate list with verifiable profiles attached.
• —Pre-call research, resolving a meeting attendee's profile from their name and company in a calendar invite before a rep or recruiter gets on a call with them.

What to check before you build on this endpoint

• —Do you have a domain, or only a company name? A domain resolves more precisely — worth extracting one from an email address or a website field if a raw company name is all a record currently has.
• —Are you checking the returned headline and location before trusting a match, especially for common names? A quick sanity check against what you already expect catches the rare ambiguous case before it causes a problem downstream.
• —Does your pipeline handle a stale match — a person who's changed jobs — as a real signal, not an error? Both outcomes described above are informative, not failures.
• —Are you chaining this before richer lookups, rather than guessing a profile URL some other way? This is specifically the resolution step those richer sources are built to follow.
• —Does the response fit into the same pipeline as your other enrichment calls? It returns through the same envelope as the rest of the source catalog, so it shouldn't need a separate parser.

Frequently asked questions

Do I need the exact company name, or does a domain work?

Either works, but a domain resolves more precisely. Company names are ambiguous across subsidiaries, regional entities, and similarly-named companies in different markets; a domain usually isn't, which makes it the more reliable of the two when you have it.

What happens if the name is common, like "John Smith"?

The company qualifier is what disambiguates it — a common name paired with a specific company or domain narrows the match considerably. It's still worth checking the returned headline and location against what you expect before acting on the match, since a genuinely large company can have more than one person with the same name.

What if the person changed jobs since the record was created?

You may get no match against the old company, or a match showing the person's new one. Either outcome is informative — it tells you the record you're holding is out of date, which is itself useful information for a CRM or outreach list.

How is this different from a general people-search API?

A people search returns a list of candidates matching filters like title or industry when you don't have a specific person in mind. This resolves one specific, named person you already know by name and employer — a narrower, more precise lookup than a filtered search.

Can this run as an agent tool instead of a fixed pipeline?

Yes — it's reachable over REST or MCP with the same inputs and outputs either way. An agent that has a name and a company but no profile URL can call this mid-task to resolve one before reaching for a richer profile lookup.

What match rate should I expect across a real batch?

It varies enough by how the input data was collected that there's no single number worth quoting — names and companies pulled from a verified source like an email domain tend to resolve more reliably than hand-typed data with inconsistent company naming. Run a real sample of your own list, since a miss isn't billed, and use that as the honest baseline.