LinkedIn Profile Finder API: Find a Profile From a Name and Company

A CRM record, a signup form or an inherited spreadsheet rarely comes with a LinkedIn profile URL. It comes with a name and a company. A LinkedIn profile finder API (also reachable as an MCP tool) turns that pair into the matching professional profile, so the lookups that need a profile URL as their input can run. This tutorial walks through the request, the response, the checks and the chain that follows.

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.

The short version

• —What it does: takes a full name plus a company name or domain and returns the matching profile: name, profile URL, headline, company, location and a summary.
• —Who it is for: anyone holding names and employers without profile links: CRM owners, recruiters, sales ops, and agents that discover mid-task they only know who someone works for.
• —What it costs: 10 points per matched profile, which is $10 per 1,000. Per the source page, unresolved names are not billed.
• —Where the reference lives: the LinkedIn profile by name and domain source page lists the exact fields, request shape and current price. This post is the walkthrough around it.

Before you start

You need three things, and only the first is a real decision.

1. —A name and an employer for each person. The full name is required, and so is the company. The lookup is built to resolve one specific person, so sending only a name returns nothing useful.
2. —A domain where you can get one. If a record has a work email, the part after the at sign is your domain. If it has a website field, extract the domain from it. A domain resolves more precisely than a typed company name, which is the single best accuracy lever you control.
3. —An API key, or an MCP client. Over REST you send the key as a bearer token. Over MCP you add one URL to your client and sign in, with no key to paste. Both are covered in the REST and MCP step below.

It also helps to decide now what your pipeline does with a name that does not resolve. Step 3 and the troubleshooting section come back to that.

Step 1: Send a name and a domain

The request has two required parameters. company_or_domain accepts either a company name or a domain, and full_name is the person you are looking for.

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

The same call from Python:

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())

This is deliberately a narrow, single-purpose lookup. It does not return a list of candidates to browse, it does not accept fuzzy or partial names, and it does not work without a company qualifier. That narrowness is the point: it turns a name-and-company pair you already have into the one profile it refers to, without a search step in between.

Prefer the domain when you have a choice: company names are ambiguous across subsidiaries and markets, a domain usually is not. If you only have a typed name, send it and retry once with a domain later (see Step 3).

Step 2: Read the response

A resolved match looks like this. The names and URL are placeholders; the shape is what the endpoint 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": "…"
    }
  }
}

The response has two views of the same result. human is a readable one-line summary for a person or an agent to read. machine is the structured part your code should parse.

The fields that matter

Every call also returns a session_id you can trace later.

Step 3: Check the match before you trust it

A returned profile is a candidate, not a certainty. Two situations deserve explicit handling, and neither is a failure of the lookup.

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 compare the returned headline and location with what you already expect before treating a match as certain, especially before it triggers an action such as a send or a CRM update. A simple rule works well in practice: auto-accept a match only when the headline or location agrees with something the record already says, and queue the rest for a human glance.

Job changes

Someone who has recently moved may not match against the old company at all, or may match showing the new one. Both outcomes are informative. They tell you the record you are holding predates a job change, which is a useful signal for a CRM record nobody has touched in a while. It is also where a live lookup differs most from a B2B contact database, which answers from a stored copy that is only as current as its last refresh.

Decide what a miss means

Before running this at volume, decide what the pipeline does with an unresolved name. Silently dropping a non-match loses a real record that may only need a different qualifier. Retrying every miss indefinitely turns a bounded batch into an open-ended one. A reasonable middle ground: if only a company name was tried the first time, retry once with a domain, then treat a second miss as final for that run and flag the row instead of deleting it.

Step 4: Chain the profile into richer lookups

Resolving a profile URL is rarely the end goal. It is the step that unblocks everything richer that needs a profile URL as its starting input. The next link in the chain is people profile plus email, which returns the profile record (name, headline, location, about text) and adds a publicly available email where one exists. A pipeline enriching a raw list of names and companies runs this resolution step first, then runs the follow-up only on records that actually resolved, rather than running every lookup against every record regardless of whether a profile was ever found.

The source pages state the costs of the two steps: the name-and-domain lookup is 10 points per matched profile, the LinkedIn people profile lookup is 5 points, and the profile-plus-email lookup is 10 points. Check each source page for current figures before you price a batch.

Worked example: enriching a signup with only a name and a work email

Acme Oy (Finland), an illustrative company, gets a new signup with a name and a work email address and nothing else: no profile URL, no title, no context.

1. —The email domain gives the company qualifier directly: acme.com. It pairs naturally with the signup's full name as the two inputs this endpoint needs.
2. —A profile by name and domain call with those two inputs resolves the matching profile. The returned headline and location confirm the match looks right before anything downstream trusts it.
3. —With the profile URL in hand, a follow-up people profile plus email call pulls the person's about text, plus an email where one is available. A rep gets real context and a way to reach out before writing a first message.

A bare name and an email address become a resolved, enriched lead through a short chain that runs the detailed lookup only once the resolution step confirms there is a real profile to enrich.

Worked example: sourcing candidates from a spreadsheet of applicants

A recruiter has a spreadsheet of applicants: full names and current employers pulled from resumes, with no profile links.

1. —For each row, a profile by name and domain call runs against the applicant's name and listed employer, resolving a profile for every row whose pair matches a public one.
2. —Rows that do not resolve are flagged rather than dropped. A common name at a very small company, or an employer field entered inconsistently, are both real reasons a match can fail without meaning the candidate has no profile.
3. —For resolved candidates, the returned headline gives a fast sanity check against the title on the resume before anyone spends time on a deeper review.

REST and MCP

The same lookup is reachable over both, with identical inputs and outputs. The REST path is run-linkedin-domain and the MCP tool is run_linkedin_domain. The price is the same as the equivalent REST call, with no separate MCP rate.

NeuralVerge hosts the MCP server at https://mcp.neuralverge.ai/mcp. You add that one URL to an MCP client (Claude, ChatGPT, Cursor, VS Code, Gemini CLI or any other), sign in through the browser and click Allow. There is no key to paste and no server to build or host. The setup guides cover each client, and how to connect NeuralVerge to Claude over MCP walks through the Claude case. An agent call uses the same two arguments as the curl example above:

{
  "tool": "run_linkedin_domain",
  "arguments": {
    "company_or_domain": "acme.com",
    "full_name": "Jane Doe"
  }
}

The response has the same shape as over REST. Once connected, the agent also sees the tools that follow it in the chain: run_linkedin_email returns the profile record plus a public email from a profile URL, and run_linkedin_people_search builds a list from filters when no specific person is known yet.

Pick REST when your code already knows the step belongs in a flow, such as a nightly job over a spreadsheet of applicants. Pick MCP when an agent drafting outreach or checking a claim about someone's background decides for itself that it needs a profile. A tool description like "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 the agent when to reach for it. A vague one risks the agent reasoning about a person without ever resolving who they are. Connected clients can be revoked under Settings, then API, in the dashboard.

Troubleshooting, cost and limits

The lookup returned nothing

Work through the likely causes in order of how often they apply:

• —The company was a typed name, not a domain. Retry once with a domain.
• —The name was entered inconsistently. Nicknames, initials, a missing middle name or a typo all reduce the chance of a match. The endpoint does not accept fuzzy or partial names, so normalise the input first.
• —The person changed jobs. A miss against the old employer is a legitimate answer. If you have another candidate employer, try it.
• —There is no public profile. Some people simply do not have one, and no input fixes that.

What a lookup costs

A matched profile costs 10 points, which is $10 per 1,000. The source page states that you are charged only when a profile is matched and that an unresolved name is not billed. Billing rules can change, so read the source page's billing line before you commit to a large batch, and see pricing for how points convert to dollars.

Batch behaviour

Run a real batch, not a hand-picked clean sample, and track two numbers: the match rate, and how often a match's headline or location contradicts the record. Hand-typed names and companies resolve less reliably than ones pulled from a verified source such as an email domain, so there is no single match rate worth quoting. Your own sample is the honest baseline.

What it does not do

It does not search, does not return several candidates, and does not work from a name alone. For a filtered list instead of a known person, use the people search source.

How to decide

Use this lookup if you can answer yes to most of these:

• —Do you hold a name and an employer but no profile URL? This is the case the lookup exists for, and the most common shape of an imported or purchased list.
• —Can you get a domain, not just a company name? Extract one from an email address or a website field if a raw company name is all a record has.
• —Will you check the headline and location on a match before acting on it? That check catches the rare ambiguous case, especially for common names.
• —Do you need to unblock a richer lookup? Profile and email sources need a profile URL as their starting point, and this is the step that provides it.
• —Do you need to deduplicate records? Several spellings or variants of one person's name can resolve onto the one profile they correspond to.
• —Will an agent call it mid-task? An agent with a name and an employer can resolve a profile before reasoning further about that person.

If instead you have no specific person yet, start with a filtered search. If you already have the profile URL, skip straight to the richer profile lookup.

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 and more precise lookup than a filtered search.

What does a lookup cost, and are misses billed?

A matched profile costs 10 points, which is $10 per 1,000 lookups. According to the source page, you are charged only when a profile is matched, and an unresolved name is not billed. Check the source page for the current billing statement before you plan a large batch.

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 and use that as the honest baseline.

Can I use the LinkedIn profile finder over MCP, or only through the API?

Over MCP as well. It is the run_linkedin_domain tool on NeuralVerge's hosted MCP server (https://mcp.neuralverge.ai/mcp): add the URL to Claude, ChatGPT, Cursor or any MCP client, sign in and click Allow. It takes the same two inputs, returns the same response shape and costs the same as the REST call.