TL;DR
- ContactOut is the direct test when the input is a regular LinkedIn profile URL and the output must distinguish work from personal email. Its API docs exclude Sales Navigator and Talent URLs for the profile endpoint and describe endpoint-specific email, phone and search credits.
- Prospeo is the focused person-enrichment option. Its Enrich Person API accepts
linkedin_urlalone as a matching input, charges one credit for a found email, and says a no-result request is not charged. A found mobile costs ten credits, with email included. - FullEnrich is the waterfall option for a team that would otherwise integrate several providers. Its bulk API accepts up to 100 contacts per job; check callback, result status and what the contract calls a chargeable find.
- People Data Labs (PDL) fits a broader person-identity pipeline. Its Person Enrichment API returns a likelihood score from 1 to 10 and lets the buyer set
min_likelihood. A matched profile is not the same as a verified work email. - Benchmark correct, usable work emails per 500 inputs, not non-empty API responses. A professional-profile URL is an identifier, not proof of email ownership, permission to send or LinkedIn's authorization of the workflow.
What LinkedIn-to-email actually means
The phrase sounds like a conversion: put a LinkedIn URL in, get an email out. In production it is a chain of separate decisions. The URL may identify a person. A vendor may match that person to its own profile. It may return an address associated with that profile, infer an address from employer patterns or verify that an address appears deliverable. Each step can fail while the previous step succeeds. A returned company address can also belong to someone with the same name.
Imagine two Alex Morgans at a large company. One is a finance director in London; the other works in customer operations in New York. A name-and-company lookup can return a syntactically valid work email for the wrong person. A professional-profile URL may reduce ambiguity, but it does not remove it if the data provider's profile mapping is stale. A “valid” mailbox test only tests the address, not the identity. Your integration needs independent states for person matched, work email found, address verified, current employer confirmed and eligible for outreach.
The URL is also not a permission slip. LinkedIn's User Agreement prohibits unauthorized bots accessing its services. A third-party API that accepts a LinkedIn URL is not a LinkedIn partnership or a license to scrape its pages. Review the provider's terms and the origin of your inputs. The lawful basis and channel rules for sending a message are separate from the technical ability to find an address. The wider data enrichment guide covers other identifiers and data sources; this guide stays with profile-led API enrichment.
Four API paths compared
| API | Supported input to test | Response and billing point | Best use | Non-fit |
|---|---|---|---|---|
| ContactOut | Regular LinkedIn profile URL; its documented endpoint excludes Sales Navigator/Talent URL forms | Work-email field and status; email credit when found; some endpoint cases use search credit | Direct profile-to-contact lookup | Your source list contains only nonstandard URL forms or needs unquoted bulk rights |
| Prospeo | linkedin_url, or name plus company identifiers |
One credit for found email; ten for found mobile with email included; no result free per docs | Focused email finding with explicit cost unit | Broader identity graph or custom multi-provider orchestration required |
| FullEnrich | Contact details including LinkedIn URL in a bulk job | Waterfall result; credits on find per docs; callback or polling design to verify | Improving coverage without integrating every provider | Team needs full control over each underlying source and its provenance |
| People Data Labs | Person identifiers including profile URL | Matched person record, likelihood, configurable threshold; check email field and API credit |
General person matching and enrichment | Need a simple verified-work-email-only endpoint |
No row is an accuracy result. Provider documentation establishes interface and charging concepts; it does not establish your match rate, current contract price, permission to contact a person or actual inbox deliverability. Ask for the exact API entitlement and permitted storage/use on the plan you intend to buy.
1. ContactOut
Best for: a team with regular LinkedIn profile URLs that wants a direct lookup and distinct work-email status in the response.
ContactOut's API reference documents a LinkedIn Profile endpoint taking a regular profile URL. It specifically says the endpoint does not accept Sales Navigator, Talent or Recruiter LinkedIn product URLs. That single detail can determine whether a current GTM list is ready for the integration. A team exporting a proprietary Sales Navigator URL should first determine whether it has a corresponding regular public profile URL through supported means; it should not assume the API will normalize a different format.
The documented response has work_email, personal_email and work_email_status fields. For a business-outreach workflow, request and store only the fields needed. A personal address may be present, but that does not make it appropriate for the campaign. The Contact Info endpoint describes one email credit if an email is found, with a separate phone credit when phone is requested and found. The broader profile endpoint also describes cases where a search credit is used if only profile data is requested or no contact information is available. Read the price and credit rule for the endpoint you will call, not a product-wide “one lookup” slogan.
The docs offer single and bulk contact endpoints. They describe V2 bulk as attempting a real-time work-email guess and verification when its database has no work email. That can improve coverage, but it changes the method behind the result. In the accepted-record table, distinguish a database address from a generated-and-verified result if the response and contract support that distinction. Store verification status and retrieval time. Set a no-result path rather than retrying the same URL until it costs more.
ContactOut's API keys are obtained through a sales conversation according to its documentation. Ask for call rate, batch size, allowed uses, retention, work-only output, no-result costs and a trial credit allocation. Non-fit: a team that cannot turn its input into supported URL form or needs full control over the sources in a waterfall.
2. Prospeo
Best for: a team seeking a predictable, focused email-enrichment call from a profile URL, with mobile lookup kept as a separate decision.
Prospeo's Enrich Person API lists linkedin_url as a sufficient identifier on its own. It also accepts combinations such as full name plus company name or website, an existing email, or a Prospeo person ID. This lets a pipeline use the strongest identifier it already holds instead of guessing an email pattern first. The documentation shows a JSON request with data.linkedin_url; use that schema as the contract in a test, not an improvised browser automation.
The cost distinction is concrete. A found email is one credit for person, company and email data. A found mobile is ten credits, with email included, and the docs say no result is not charged. They also document flags to control whether only a verified email or mobile qualifies. If the business task is email, do not ask for mobile on every record merely because an endpoint supports it. On 1,000 successful results, the difference between one and ten credits is significant even before the plan's dollar conversion.
Run ambiguous identities through the API: common name at a large employer, recently changed job, and profile with old company in the URL or title. Check how the response represents no match, a match without email and a verified email. Log the email status and current employer separately. A returned address should not overwrite an existing first-party confirmed email unless the change passes a recency rule.
Prospeo publishes plan pricing, but the page's billing toggle was not reliably readable in our text review. Search results from that official page showed per-user tiers and different annual-versus-monthly figures. Record the selected billing term and included credits from checkout, then divide by accepted emails; a bare “$49/month” copied without allowance and term can mislead. Non-fit: a pipeline needing deep person history or multi-provider source control beyond a focused enrichment call.
3. FullEnrich
Best for: a team that wants one API to try several underlying contact sources before declaring no result.
FullEnrich markets a waterfall: it checks sources sequentially, stops when its criteria are met and returns the contact result. Its bulk API documentation describes requests of up to 100 contacts and a LinkedIn URL as an input. The credit guidance says credits are consumed when a result is found. Confirm which result qualifies: an email, a mobile, either, or a provider-specific match. Ask whether a verified, unverified or catch-all address changes the charge.
The operational advantage is that your engineering team does not maintain separate API contracts and fallback rules for every data vendor. The tradeoff is less direct control over source order, result provenance and verification method. In the pilot, request the provider's result schema and show how an analyst could explain why a returned work email is believed to belong to the person. A waterfall can produce more non-empty fields while increasing wrong-person risk if the identity match is loose.
Treat a bulk request as a job. Store your own request ID, normalized input and client record ID; receive a webhook or poll for completion according to the documented endpoint. Make processing idempotent so a timeout followed by retry does not create duplicate CRM writes. Track accepted, no-result, failed and still-pending rows. A webhook arriving twice should not charge twice on your ledger or update the contact twice. FullEnrich's site mentions a low monthly starting price, but an API buyer needs a written quote for volume, credit units, webhooks, throughput and data rights.
Non-fit: teams that require the exact underlying source for every candidate address or want to tune their own waterfall independently. The buyer should also test whether slow asynchronous results fit the list-production deadline.
4. People Data Labs
Best for: a data engineering team that needs person identity matching and broader profile enrichment as part of a governed pipeline, with work email only one possible output.
PDL's Person Enrichment API returns a person record and a likelihood score from 1 to 10. The API allows a min_likelihood request parameter, and its documentation shows a default of 2. That default is meant to preserve recall, not to certify a record as suitable for automatic email outreach. The team should choose a higher threshold through a labeled sample and route ambiguous matches to review. likelihood is a person-match measure; it is not an SMTP verification score or proof the person still works at the returned employer.
The response can support broader identity work: person profile data, professional history and identifiers. That may be valuable if you are merging duplicate people across Salesforce, a warehouse and outreach tools. It also creates responsibility to minimize requested fields, restrict raw responses in logs and honor retention rights. Keep the matched PDL ID, input identifiers, score and timestamp in a controlled record. Do not dump an entire response into a rep-facing note when the only relevant field is a work email.
Before a purchase, ask which inputs, fields and API credits apply to Person Enrichment at your volume, whether a no-match consumes a credit, and what distribution to clients or downstream platforms is permitted. The documentation's quickstart describes a free monthly credit allocation, but that is a test allowance, not a production price. Non-fit: a team that only needs one verified work email and does not have an identity-resolution workflow.
The request and response contract
Implement a vendor-neutral record between the source list and CRM. The following JSON is an illustrative internal contract, not a copied vendor response:
{
"input_id": "crm-contact-4812",
"profile_url": "https://www.linkedin.com/in/example-person",
"provider": "selected_api",
"person_match": "confirmed_or_review_required",
"work_email": "person@example.com",
"email_status": "verified_or_unverified_or_unknown",
"employer_domain": "example.com",
"observed_at": "2026-09-27",
"credit_event": "email_found",
"crm_action": "stage_for_review"
}
Normalize URL variants and remove tracking parameters before deduplication. Preserve the original input, because two profile URLs that look similar may still refer to different people. Never let the provider's response overwrite a first-party, recently confirmed address without a comparison step. Keep work and personal emails distinct; many teams will not use personal addresses at all. Record suppression centrally so that finding a new address does not revive a do-not-contact record.
For bulk processing, use an idempotency key based on input record, normalized URL, provider and run version. Rate-limit calls to the purchased plan. Separate an API failure from a genuine no-match; the former may be retried, while the latter should usually stop until a new identifier is available. Validate callbacks before updating results, and keep raw personally identifying payloads out of general application logs. The implementation is complete only when an analyst can answer: which input produced this address, what matched, what verified it, what did it cost and why did Salesforce accept it?
A 500-profile benchmark
Build 500 profiles from your own lawful workflow, selected before providers see them: 250 ordinary target contacts, 100 common-name or multi-office cases, 75 recent job changes and 75 across the hardest countries or industries. For a known-answer subset, record the verified current employer and work address before making API calls. Do not feed all 500 to a vendor and then label its output as ground truth.
Call each candidate with equivalent information. Some APIs can use more than a URL; test both the URL-only path and, if relevant, the richer name-plus-company path. Measure correct person match, correct current employer, work email returned, verification status, wrong-person address, no result, time to completed result and credits actually consumed. Review a sample of results the API calls “verified”; a deliverable mailbox is not enough if the address belongs to the wrong Alex Morgan.
Distinguish coverage from usefulness. An illustrative vendor might return 320 addresses but have 40 wrong-person or stale-employer matches; another might return 260 with only five such errors. The first has a higher raw fill rate, but the second could deliver more safe, accepted outreach records per dollar. Do not use these example numbers as vendor results. Re-run a smaller sample quarterly: job changes and provider methods can change the ranking.
Cost per accepted work email
Suppose a team submits 500 profiles. The API returns 300 work emails, reviewers accept 240 after person and employer checks, and the run consumes $180 of API allocation plus four analyst hours at $45. Direct cost is $360, or $1.50 per accepted work email. Dividing by 300 returned addresses would produce $1.20 and hide the 60 rejected records. Add the cost of verification, integration and downstream bounce handling if those are outside the included service.
This example is a unit-economics template, not a vendor price. For ContactOut, include any search credits and separate email or phone credits for the endpoint used. For Prospeo, keep one-credit email calls separate from ten-credit mobile calls, then apply the selected plan's dollar cost per credit. For FullEnrich, record the result type that triggers a charge and the bulk-job completion rate. For PDL, count charged person-enrichment calls, then only the matched records that yielded an accepted email. The cheapest credit can be the most expensive accepted address if identity errors force manual repair.
Which API should a GTM team choose?
Choose ContactOut when you already have regular profile URLs and want its documented contact output and status fields. Choose Prospeo when the priority is a focused email result with an explicit one-credit found-email unit. Choose FullEnrich when a managed waterfall is preferable to maintaining several provider integrations. Choose PDL when person resolution and reusable identity data justify a more general enrichment API.
For high-volume lists, compare dedicated email verification APIs as a separate layer. Verification can improve deliverability classification; it cannot establish that a wrong-person match is right. Keep the buying test on accepted, current, permitted work emails and the engineering work needed to maintain them.
Use the Clay Waterfall Enrichment Guide to define matching, verification and fallback rules for the LinkedIn-to-email path.
FAQ
Can an API find a work email for every LinkedIn URL?
No. Some profiles have no matching record or current work address, and vendors differ by country and job change. Require explicit no-result and ambiguous-match states. A workflow that guesses indefinitely can spend more while producing a less trustworthy address.
Does a valid email mean the API matched the right person?
No. Deliverability and identity are different tests. A mailbox can be valid but belong to another employee with the same name, or to a former employer. Check current person and company evidence before accepting the address.
Are Sales Navigator URLs accepted by ContactOut's profile API?
Its documented LinkedIn Profile endpoint accepts regular LinkedIn URLs and explicitly excludes Sales Navigator, Talent and Recruiter URL forms. Verify the URL type in your source list before designing a batch integration.
How do Prospeo email and mobile credits differ?
Its Enrich Person documentation says one credit is charged for a found email and ten for a found mobile, with email included in the mobile result. It says no-result requests are not charged. Apply the current plan's actual dollar-per-credit terms and avoid mobile requests when the campaign only needs work email.
What does PDL's likelihood score verify?
It estimates confidence that the returned person profile matches the requested person. It is not a verified-email or outreach-permission score. Set a threshold using labeled examples, and review ambiguous or high-impact records.
Should a new API address replace an existing CRM email?
Only under an explicit source, recency and verification rule. Preserve a recently confirmed first-party address; stage conflicting results for review. Carry suppression and opt-out state across address changes so enrichment never reactivates someone who should not be contacted.
