Data catalog · Enrichment
Send an email address and get back the LinkedIn profile URL behind it. The reverse of every other lookup in the catalog, and the first leg of the email-to-person chain. Flat cost per call, billed on any 2xx including a response with no match.
Last updated September 22, 2026
Every other lookup in this catalog runs identity → contact detail. This one runs the other way. `POST /find_linkedin_url_by_email` takes an address and returns the LinkedIn profile URL of the person who owns it. **[Get 25 free credits — no card](https://app.richapi.ai)**
One required field, `email`, validated against `^[^\s@]+@[^\s@]+\.[^\s@]+$` before anything runs. A malformed address fails as a 4xx and costs you nothing, which is the cheapest input validation available to you: send junk and it bounces at the door. The response is where you need to read carefully: ```json { "status": "example", "data": { "LinkedIn Profile URL": "example" } } ``` The key inside `data` is **`LinkedIn Profile URL`**, with capitals and spaces, rather than `linkedin_url` or `url`. Almost every other endpoint in this catalog returns camelCase or snake_case, so a parser written from muscle memory will read `undefined` here and you will spend twenty minutes blaming the lookup.
The address arrived and the person did not. A form fill with a work email and no other field. A support ticket. A calendar invite. A CRM built in 2019 by someone who thought email was a sufficient identifier. This endpoint turns that address into a profile URL, and the profile URL is the key that unlocks the rest of the catalog. [Person enrichment](/api/person-enrichment) takes it and returns the full record — title, company, work history. That chain, email in and person out, is two separate calls and two separate charges, and it is worth building as two steps rather than one helper function, so you can tell a failed resolve from a failed enrich.
This endpoint is **not** a multi-provider waterfall. Billing is on HTTP 2xx. A thin 2xx still bills. 4xx and 5xx bill nothing, on any endpoint. The miss-free rule on the email finder, phone finder and email verifier does not apply here.
**1. Get a key.** Sign up at [app.richapi.ai](https://app.richapi.ai). 25 free credits, no card. **2. POST the address.** ```bash curl -X POST https://api.richapi.ai/api/v1/find_linkedin_url_by_email \ -H "x-api-key: $RICHAPI_KEY" \ -H "Content-Type: application/json" \ -d '{"email": "jane@acme.com"}' ``` **3. Read the nested key correctly.** ```bash # jq, with the spaces quoted curl -s ... | jq -r '.data["LinkedIn Profile URL"]' ``` **4. Chain it into enrichment.** ```bash curl -X POST https://api.richapi.ai/api/v1/enrich_profile \ -H "x-api-key: $RICHAPI_KEY" \ -H "Content-Type: application/json" \ -d '{"url": "https://www.linkedin.com/in/example/"}' ``` **5. Or let an agent run the chain.** The [hosted MCP server](/integrations/claude) exposes both tools, so the two calls are one instruction: ``` Here are 5 emails from this morning's signups. Find each person's LinkedIn and tell me their current title. ```
Two keys, and the one you want is nested. | Field | Type | What it is | |---|---|---| | `status` | string | Call status. | | `data` | object | Wrapper around the result. | | `data["LinkedIn Profile URL"]` | string | The profile URL. | **Read that last key again.** It is the literal string `LinkedIn Profile URL` — three words, spaces, capital letters. Not `linkedin_profile_url`, not `linkedinUrl`. Any client that assumes snake_case will hand you `undefined` and no error, and you will spend an afternoon on it. ```js // wrong, fails silently const url = res.data.linkedin_profile_url; // right const url = res.data["LinkedIn Profile URL"]; ``` Note this differs from `/profile_search` and `/linkedin_company_employees_search`, which both return `linkedinUrl` in camelCase. Mixing the two up inside one pipeline is the most common integration bug on this endpoint.
Flat `4 credits` per call, billed on every 2xx. The full email-to-person chain (this call plus [person enrichment](/api/person-enrichment) at `1 credit`) is `5 credits` per person, and each leg bills independently. Rates per credit are tiered by package on [the pricing page](/pricing). This is one of the more expensive single calls in the catalog relative to what it returns, because reverse matching is expensive to do at all. Two habits keep the bill sane. Store the profile URL the first time you resolve an address, because the mapping does not change and re-resolving is money for nothing. And filter the list before you loop — role addresses, personal domains and anything already carrying a profile URL should never reach the call.
**Enriching inbound signups that gave you nothing but an email.** A self-serve signup form that asks for more than an email converts worse. Ask for the email, resolve the person server-side, and route the account on a real title instead of a dropdown the user lied in. **Fixing a CRM keyed on email addresses.** Older CRMs carry an email column and nothing else. A one-time resolve pass fills in profile URLs, and from then on every future refresh runs on the URL, the cheap key, instead of repeating this call. **Deduplicating people across systems.** Two records, two addresses, one person. Resolving both to a profile URL gives you an identity key that survives someone changing jobs and giving you a new work email, which the email column never does.
- [Person enrichment API](/api/person-enrichment) — the second leg of the chain - [Email verification API](/api/email-verifier) — check the address is real before you spend a resolve on it - [Email finder API](/api/email-finder) — the forward direction, name and domain to address - [LinkedIn profile search API](/api/linkedin-profile-search) — find profiles by name and title instead - [All endpoints](/api) — the full catalog - [Pricing](/pricing) — credit packages and tier rates
**What am I charged for?** Any 2xx. This is a single-provider endpoint, not a waterfall, so a response with no profile in it still bills the flat per-call cost. A 4xx from the email pattern check, or any 5xx, bills nothing. **Should I verify the address first?** Often, yes. [The verifier](/api/email-verifier) is cheaper than this call and it bills zero when its waterfall cannot reach a verdict, so screening a stale list through verification before resolving keeps you from spending the bigger charge on addresses that no longer exist. **Does it work on personal addresses?** Match rates are better on work addresses, because the association between a work address and a profile is the thing providers can observe. A personal address is a weaker link and resolves less often, and it still bills. **Why is the response key `LinkedIn Profile URL` with spaces?** Because that is what the live API returns, and we would rather document the odd key than let you find it in production. Quote it in whatever language you are parsing with. **Can I send a batch of addresses in one call?** Not to this endpoint. It takes one `email` per request. Loop it, and rate-limit your loop like you would any paid per-call endpoint. **Can I call this from Claude or Cursor (MCP)?** Yes. The hosted MCP server exposes `find_linkedin_url_by_email` as a tool with a copy-paste config and no install. **Do I need a credit card?** No. 25 free credits on signup, no card.
Resolve your first address in two minutes. **[Get 25 free credits](https://app.richapi.ai)**