In 2022, a sponsored conference handed me 1,400 attendee LinkedIn URLs. And zero emails.
My first attempt at automating LinkedIn email finding with Python was a Selenium scraper from a blog post. It broke twice in one afternoon (selectors changed, sessions expired), and then LinkedIn flagged my own account with a warning. Fun times.
The second attempt is this article: a Python pipeline built on an email finder API instead of scraping. It processed all 1,400 URLs overnight and I woke up to a CSV with roughly 900 verified work emails. No drama, no flagged account.
Here’s the pipeline, start to finish.
Why an API beats scraping LinkedIn
Scraping breaks constantly, violates LinkedIn’s rules, and risks your account; an API does none of that. Three reasons the scraper route keeps failing people:
- Fragile selectors: LinkedIn’s markup changes, and your script dies at 2am
- The rules: automated scraping violates the LinkedIn User Agreement
- Your account: LinkedIn actively detects automation, and it’s YOUR profile on the line
An email finder API works differently. The profile URL is just a lookup key into the finder’s licensed contact database: nothing logs into LinkedIn, nothing touches your session. Same input, same output, none of the risk.
One scope note before we build. This page is the hands-on tutorial. If you want the strategy side (which lead-gen workflows this feeds, deliverability, compliance thinking), that lives in the workflow guide. Here, we write code.
The whole build in one line:
CSV of LinkedIn URLs → validate → API lookup → parse → verified emails CSV
Set up your Python environment
Two packages: requests for the HTTP calls, and python-dotenv so your API key lives in a file, not in your source code.
pip install requests python-dotenvGrab your key from the CUFinder dashboard (Account » API key), put it in a .env file, and add that file to .gitignore. Then the top of your script looks like this:
# .env (never commit this file)
# CUFINDER_API_KEY=your-api-key-here
import csv
import os
import time
import requests
from urllib.parse import urlparse
from dotenv import load_dotenv
load_dotenv()
API_KEY = os.getenv("CUFINDER_API_KEY")That’s the whole environment. No browser drivers, no session cookies. Feels good already.
Your first email lookup in Python
The endpoint is a form-encoded POST to https://api.cufinder.io/v2/fwe with one parameter: linkedin_url. Documentation lives in the LinkedIn Profile Email Finder API reference. A successful response looks like this:
{
"status": 1,
"data": {
"confidence_level": 94,
"query": "linkedin.com/in/iain-mckenzie",
"work_email": "iain.mckenzie@stripe.com",
"credit_count": 9787
}
}Look closely at the shape. The email sits at data.work_email, nested one level down. I’ve seen more than one script (including an early version of mine) read result.get('work_email') at the top level and print None for every single profile. Parse the nesting once, in one function, and return a flat dict:
def find_email_from_linkedin(linkedin_url, api_key):
"""Find a verified work email for one LinkedIn profile URL."""
endpoint = "https://api.cufinder.io/v2/fwe"
headers = {
"Content-Type": "application/x-www-form-urlencoded",
"x-api-key": api_key,
}
data = {"linkedin_url": linkedin_url}
try:
response = requests.post(endpoint, headers=headers, data=data, timeout=30)
response.raise_for_status()
result = response.json()
except requests.exceptions.RequestException as e:
return {"linkedin_url": linkedin_url, "error": str(e)}
# the email is nested under data, NOT at the top level
if result.get("status") == 1:
payload = result["data"]
return {
"linkedin_url": linkedin_url,
"work_email": payload.get("work_email"),
"confidence": payload.get("confidence_level"),
"credits_remaining": payload.get("credit_count"),
}
return {"linkedin_url": linkedin_url, "work_email": None}📌 Remember: the email is at data.work_email, NOT at the top of the response. If your script prints None for every profile, this nesting is almost always why.
Prefer not to hand-roll the HTTP? The official Python SDK wraps the same endpoint in one call:
from cufinder import Cufinder
client = Cufinder('your-api-key-here')
result = client.fwe('linkedin.com/in/iain-mckenzie')
print(result)Cost and quality, from the docs: 5 credits per record found, with a 94% confidence score, backed by a database of 1B+ profiles. No-match lookups generally aren’t charged.
Validate LinkedIn URLs before you spend credits
Exported lists are full of junk rows. Validate before you pay.
Of my 1,400 conference rows, 31 were malformed: company pages, search URLs, one literal “LinkedIn” as text. A five-line validator catches all of that before it hits the API:
def is_valid_linkedin_url(url):
"""Accept only real profile URLs like linkedin.com/in/name."""
if not url or not isinstance(url, str):
return False
candidate = url.strip()
if not candidate.startswith(("http://", "https://")):
candidate = "https://" + candidate
parsed = urlparse(candidate)
host_ok = parsed.netloc.lower().endswith("linkedin.com")
path_ok = parsed.path.startswith("/in/") and len(parsed.path) > 4
return host_ok and path_okProfile URLs live under /in/. Company pages (/company/) belong to a different endpoint entirely, so filtering them here saves you both credits and confusion.
Process a whole list with rate limiting
That’s one profile. Now the whole list.
The API allows 100 requests per minute per key, on a fixed 60-second window. A sleep of about 0.7 seconds between calls keeps a long batch comfortably under that ceiling:
def process_linkedin_batch(linkedin_urls, api_key, delay=0.7):
"""Process a list of profile URLs with rate-limit pacing."""
results = []
for i, url in enumerate(linkedin_urls, start=1):
print(f"Processing {i}/{len(linkedin_urls)}: {url}")
if not is_valid_linkedin_url(url):
results.append({"linkedin_url": url, "error": "invalid_url"})
continue
results.append(find_email_from_linkedin(url, api_key))
# 100 requests/minute, fixed window; ~0.7s stays safely under
time.sleep(delay)
return resultsAt that pace, 1,400 URLs take about 20 minutes of wall-clock time. My “overnight run” was really an after-dinner run; I just didn’t want to watch it.
Handle retries and 429s like an adult
So what happens when the API says 429? That’s the Too Many Requests status. You’ve crossed the per-minute window, and the right response is to back off and retry, not crash:
def make_api_request_with_retry(endpoint, headers, data, max_retries=3):
"""POST with exponential backoff on 429s and timeouts."""
for attempt in range(max_retries):
try:
response = requests.post(endpoint, headers=headers,
data=data, timeout=30)
if response.status_code == 200:
return response.json()
if response.status_code == 429: # over the per-minute window
wait_time = 2 ** attempt
print(f"Rate limited. Waiting {wait_time}s...")
time.sleep(wait_time)
continue
return {"error": f"API error: {response.status_code}"}
except requests.exceptions.Timeout:
print(f"Timeout on attempt {attempt + 1}")
return {"error": "max_retries_exceeded"}Swap this in wherever requests.post appears and the pipeline survives flaky networks and enthusiastic pacing. For the rest of the non-200 family (401 means your key didn’t load, for instance), the status codes reference has the full map.
Enrich the contact while you’re at it
An email without context is half a lead. Send the same profile URL to the LinkedIn Profile Enrichment API (/v2/epp) and you get the person’s name, title, company, and company details back. It costs 1 credit, at a 93% confidence score:
def enrich_linkedin_profile(linkedin_url, api_key):
"""Add name/title/company context from the enrichment endpoint."""
endpoint = "https://api.cufinder.io/v2/epp"
headers = {
"Content-Type": "application/x-www-form-urlencoded",
"x-api-key": api_key,
}
result = make_api_request_with_retry(
endpoint, headers, {"linkedin_url": linkedin_url})
if result.get("status") == 1:
person = result["data"]["person"]
return {
"full_name": person.get("full_name"),
"job_title": person.get("job_title"),
"company_name": person.get("company_name"),
"company_website": person.get("company_website"),
"company_industry": person.get("company_industry"),
}
return {}Note the field path: the enrichment response nests everything under data.person. And note what’s NOT in there: an email. The two endpoints are complementary: epp for who they are, fwe for how to reach them.
One ordering trick worth stealing. My script enriches AFTER finding an email, because I wanted context on contactable people. But if your list is broad and your ICP is narrow, flip it: enrich first for 1 credit, check the title and company size against your ICP, and only run the 5-credit email lookup on the people who fit. Same functions, opposite order, much smaller bill.
💡 Credit math: enrichment (1 credit) before email lookup (5 credits) → filter to ICP first and a 1,400-row run stops burning credits on people you'd never email.
Save results and skip what you’ve already paid for
My first full run died at row 800 when my laptop went to sleep. Restarting from zero would have re-charged every lookup before the crash. That’s why the pipeline appends each row to the output file immediately, and skips anything already there on the next run:
FIELDS = ["linkedin_url", "work_email", "confidence",
"full_name", "job_title", "company_name", "error"]
def load_processed(output_file):
"""URLs we've already paid for; skip them on re-runs."""
try:
with open(output_file, newline="") as f:
return {row["linkedin_url"] for row in csv.DictReader(f)}
except FileNotFoundError:
return set()
def append_result(output_file, row, write_header):
with open(output_file, "a", newline="") as f:
writer = csv.DictWriter(f, fieldnames=FIELDS, extrasaction="ignore")
if write_header:
writer.writeheader()
writer.writerow(row)Python’s csv module does all the heavy lifting here. Dedupe is credit-saving too: duplicate lookups ARE charged, so a set-based skip pays for itself on the first messy list.
How did the run go? A tiny report
Five lines of counting tells you your real match rate, the number that shapes your sequencing plans:
def generate_automation_report(results):
"""Success/error rates for one run."""
total = len(results) or 1
found = sum(1 for r in results if r.get("work_email"))
errors = sum(1 for r in results if r.get("error"))
return {
"total_processed": len(results),
"emails_found": found,
"success_rate": round(found / total * 100, 1),
"error_rate": round(errors / total * 100, 1),
}The full pipeline script
Here’s the glue that assembles everything above into one runnable file. Paste the helper functions from this article above main(), then: copy it, run it, swap the file names.
"""LinkedIn email pipeline: CSV of profile URLs in, verified emails out.
Input CSV needs a 'linkedin_url' column.
Usage: python pipeline.py input.csv output.csv
"""
import csv
import os
import sys
import time
import requests
from urllib.parse import urlparse
from dotenv import load_dotenv
# paste above main():
# is_valid_linkedin_url, make_api_request_with_retry,
# find_email_from_linkedin, enrich_linkedin_profile,
# FIELDS, load_processed, append_result, generate_automation_report
ENRICH = True # False = emails only, no 1-credit context lookup
def main(input_file, output_file):
load_dotenv()
api_key = os.getenv("CUFINDER_API_KEY")
if not api_key:
sys.exit("CUFINDER_API_KEY missing, put it in .env")
with open(input_file, newline="") as f:
urls = [row["linkedin_url"].strip() for row in csv.DictReader(f)]
processed = load_processed(output_file)
write_header = not processed
results = []
for i, url in enumerate(urls, start=1):
if url in processed:
continue
print(f"[{i}/{len(urls)}] {url}")
if not is_valid_linkedin_url(url):
row = {"linkedin_url": url, "error": "invalid_url"}
else:
row = find_email_from_linkedin(url, api_key)
if ENRICH and row.get("work_email"):
row.update(enrich_linkedin_profile(url, api_key))
time.sleep(0.7) # stay under 100 requests/minute
append_result(output_file, row, write_header)
write_header = False
results.append(row)
print(generate_automation_report(results))
if __name__ == "__main__":
main(sys.argv[1], sys.argv[2])That’s the whole machine. Input CSV → validated lookups with retries → enriched rows → output CSV → report. Interrupt it anytime; it resumes where it stopped.
What does a run like this cost? For my 1,400 rows: about 900 email matches at 5 credits each, plus the enrichment credit on those same rows. The misses and the 31 junk rows cost nothing. So the bill tracks your MATCH count, not your list size, which is exactly the incentive you want.
What about parallel workers?
You can parallelize with concurrent.futures, and here’s the pattern. But read the warning after it:
from concurrent.futures import ThreadPoolExecutor, as_completed
def process_profiles_parallel(linkedin_urls, api_key, max_workers=3):
"""Parallel lookups; mind the shared 100/minute budget."""
results = []
with ThreadPoolExecutor(max_workers=max_workers) as executor:
futures = {
executor.submit(find_email_from_linkedin, url, api_key): url
for url in linkedin_urls if is_valid_linkedin_url(url)
}
for future in as_completed(futures):
results.append(future.result())
return resultsThe warning: the rate limit is per KEY, not per thread. Five unpaced workers just hit the 100-per-minute wall five times faster: a 429 festival. Below that ceiling, sequential-with-sleep processes 1,400 rows in ~20 minutes anyway. So parallelism buys you very little here. I keep it for re-runs over small failure lists, nothing else.
Troubleshooting the usual failures
Every long run hits a few of these. None of them should stop the pipeline:
- Timeouts: transient network stuff; the retry wrapper absorbs them
- 429s: you’re pacing too fast; raise the sleep or let the backoff handle it
- invalid_url rows: the validator caught junk; fix the export, not the script
- No email found: NORMAL. Not every profile matches; log it and keep moving
- 401 responses: your key didn’t load; check the .env file name and variable
🧠 Sanity check: run 20 rows before 1,400. A twenty-row test costs pocket change and shows you your real match rate before the overnight run.
Keep it clean: keys, privacy, and the rules
Three habits keep this pipeline respectable. Keys stay in .env, out of source control. One leaked key in a public repo and someone else spends your credits.
Privacy: the people in your CSV have rights under GDPR and similar laws: deletion on request, easy opt-outs. Build your outreach like you’ll be asked to honor both, because you will.
And the platform rule that started this article: never scrape. The API route exists precisely so your automation never touches LinkedIn itself.
Frequently asked questions
How do I find the email behind a LinkedIn account?
Pass the profile URL to an email finder API, which matches it against a licensed contact database and returns the verified work email. The first code block in this article does exactly that in about 25 lines.
Can you extract email addresses from LinkedIn?
Not by scraping: most emails aren’t displayed on profiles, and automated extraction violates the User Agreement. The working method is a URL-keyed database lookup through an API, which never touches LinkedIn itself.
How to scrape data from LinkedIn using Python?
You can, with Selenium or Playwright, but it breaks constantly, and it puts your account at risk. I’ve been flagged doing it. The API approach in this tutorial produces the same outcome without automating LinkedIn at all.
Does LinkedIn use Python?
LinkedIn’s core stack is largely Java and Kotlin, with Python showing up in data and tooling work. For OUR side of the fence, Python plus the requests library is all this pipeline needs.
How do I keep my API key out of the script?
Put it in a .env file, load it with python-dotenv at runtime, and add .env to .gitignore. Every code block in this tutorial reads the key from the environment, never from a string in the source.
What match rate should I expect from a list of profile URLs?
Expect a real gap: my 1,400-row conference list returned about 900 emails. Active professionals at established companies match best; students, tiny companies, and stale profiles drag the rate down. Source-list quality drives everything.
How fast can I process 1,000 profiles?
Roughly 12-15 minutes. The limit is 100 requests per minute on a fixed window. A paced sequential run with 0.7-second sleeps and a few retries lands in that range comfortably.
Go run it
One more time, the whole thing:
input.csv → validate → fwe lookup (retry, pace) → epp context → output.csv → report
Copy the script, run your 20-row test, then let the real list rip. And when you’re deciding what to DO with 900 fresh work emails, the API workflow guides cover the strategy side.
Hit a weird failure mode I didn’t cover? Tell me about it; my error logs and I have probably met it before.
Bad
Okay
Good
Amazing
