Find a LinkedIn profile URL from what you already know

What a LinkedIn profile URL actually is

A profile URL looks like linkedin.com/in/some-slug. That slug is the part that matters: it is the stable identifier for a person on the platform. Job titles change, headlines get rewritten, companies get left: the slug usually survives all of it. That is why the URL, and not the name, is what you want stored in your CRM as the key for a person.

The cost side is worth stating up front, because it decides how you sequence the work: resolving a profile costs 1 credit, enriching one costs 1 credit, and the free plan carries 100 credits a month. A thousand-row list is therefore a thousand credits to resolve, before any enrichment.

Two consequences follow. First, resolving a person to their profile URL once is worth more than looking them up repeatedly by name, because every later enrichment can start from a stable key. Second, a list keyed on names is fragile in a way that is invisible: it looks fine until two people share a name, and then it is silently wrong.

If what you are after is the address rather than the person, the email finder guide covers that path; if it is the company behind the person, LinkedIn company data starts from the other end.

The three reliable ways to find a LinkedIn profile

From a full name and a company

This is the method with the highest hit rate, and the one to prefer whenever you have both. Searching a name alone returns every homonym on the platform, and there are more of them than intuition suggests: common first-and-last-name combinations run into the hundreds. Adding the company narrows it to one, because a profile carries its current employer as a structured field.

The failure case is worth knowing: someone who left the company you have on file will not match on it. If your list is old, expect a share of misses that are not really misses: the person exists, your data about them is stale. That is a reason to re-resolve a list before a campaign rather than trusting a resolution made a year ago.

From a work email

A professional email carries two signals at once. The local part, before the @, usually encodes the name in one of a handful of patterns: first.last, flast, first. The domain identifies the employer. Put together, they point at one person inside one company, which is exactly the pair the previous method needs.

It fails on shared mailboxes. contact@, hello@, sales@ belong to nobody, so there is no profile to resolve. A tool that returns something anyway on a generic address is not being helpful; it has picked a person from that company and hoped. Check that your input list is made of personal addresses before blaming the hit rate.

From a company page

When what you need is the people rather than one person, the starting point is the company itself: you list its staff, optionally filtered by function, and you get profiles. This is a different job from the two above. You are not resolving a known identity, you are building a list from scratch: and the questions that matter change accordingly, from "is this the right person" to "is this the right set of people".

What you can read once you have the URL

A public profile carries a predictable set of fields, and each of them is its own lookup: full name, headline, current job title, previous job titles, tenure at the current company, skills, languages, education dates, region, follower count, and whether the account is a Premium one. Below this article you will find one page per starting point for each of these: which value you have, which value you get.

Two of these deserve a note. The headline is free text the person wrote themselves, so it is the best single field for personalisation and the worst for filtering: it is not normalised, and half of it is slogans. The job title is closer to structured, which makes it the one to filter on, but it still carries whatever internal vocabulary the company uses. A "Growth Lead" and a "Head of Growth" may be the same job or two levels apart depending on the org.

What no method can do

No tool reads a profile that is not public, and none invents an address that never existed. This sounds obvious and is routinely ignored, because a lookup that always returns something feels better than one that sometimes says no. It is the opposite: a result on every row means the tool is guessing on the rows where it should have abstained, and you cannot tell which ones those are.

The behaviour to demand is an explicit "no match". It costs you a visibly empty cell, which you can decide what to do with, instead of a plausible wrong profile that will get an email addressed to the wrong person. On a list of a thousand, a 10% silent error rate is a hundred people receiving a message meant for somebody else: and that is a deliverability and reputation problem long before it is a data problem.

Finding LinkedIn profile URLs on a whole list

Finding one profile is a manual search and takes a minute. Finding two hundred is a different problem, and the difference is not volume: it is repeatability. You need the same lookup applied identically per row, a cost you can predict before you start, and a clear answer on the rows that fail.

Derrick runs that lookup where your list already lives. In Google Sheets, the lookup is a column: you point it at the name and company columns, and the profile URLs fill in. From an AI assistant through the MCP server, you ask in plain language and get the same result inline. Through the REST API, you wire it into whatever runs your pipeline. Same engine behind the three, same credits.

What it costs, and how to keep it predictable

Resolving a profile costs 1 credit, and enriching one costs 1 credit. The free plan includes 100 credits a month, which is enough to measure the hit rate on your own list before paying for anything: and measuring it on your own list is the only number that means anything, since hit rate depends far more on the quality of your input than on the tool.

The practical way to keep the bill predictable is to resolve first and enrich second. Run the resolution pass on the whole list, look at how many rows came back empty, then only enrich the rows that resolved. Enriching a list you have not resolved spends credits on rows that were never going to produce anything.

Four mistakes that cost the most

Trusting a name-only match. It is the single biggest source of silent corruption in B2B lists. If the name is all you have, treat the output as a candidate to confirm, not as a fact to store.

Re-resolving a list you already resolved. The profile URL is stable. Once you have it, later enrichments should start from it, not from the name again: it is cheaper and it removes the ambiguity entirely.

Filtering on the headline. It reads like a job title and is not one. Filter on the job title field, personalise with the headline.

Reading an empty cell as a tool failure. Sometimes it is. Often it is a person who left the company on your file, a generic mailbox, or a profile that is not public. The distribution of your empty rows tells you which: and it is usually the input, not the lookup.