400 Twitter and LinkedIn Profiles Run Through Enrichment APIs: Coverage Numbers Nobody Publishes

Last quarter I ran a test I couldn't find real data on anywhere: take B2B contacts whose social handles I already know — specifically their Twitter/X handle and LinkedIn URL — and see what each enrichment tool returns when I start from that social identity rather than from a company domain or email address.

The setup: 400 contacts from SaaS companies with 50–500 employees. I verified each one manually — job title, company, work email — before running them through the APIs. The goal wasn't to find emails from scratch. It was to understand what social-first enrichment actually yields when you know someone's Twitter handle or LinkedIn URL and want to get to a working email.

Why social-first matters and who actually uses it

Domain-first enrichment (enter company.com, get a list of employees) is the standard workflow. But it breaks down for:

• Founders who bounce between companies and keep their Twitter audience
• IC developers who are more findable by GitHub or Twitter than by current employer
• Outbound to conference speakers, newsletter writers, or podcast hosts
• Signals from social engagement (who liked your content, who retweeted a competitor)

In all those cases, you have a social identity first and need to get to an inbox. That's a different starting point than domain search, and the coverage numbers are completely different.

The 400-contact dataset

I split 400 contacts into four buckets:

• Group A (n=100): Twitter handle known, LinkedIn URL unknown
• Group B (n=100): LinkedIn URL known, Twitter handle unknown
• Group C (n=100): Both Twitter and LinkedIn known
• Group D (n=100): Twitter handle from a public list (event speakers, OSS contributors)

All 400 had verified work emails I used as ground truth. I ran each group through the APIs, tracking email match rate (does the tool return any email?), accuracy rate (is the returned email the verified one?), and phone coverage.

Email coverage by starting point

Tool	Twitter-first coverage	LinkedIn-first coverage	Accuracy (of found)
Apollo	41%	78%	84%
People Data Labs	67%	81%	79%
Wiza	12%	89%	91%
RocketReach	38%	74%	82%
Lusha	19%	71%	88%
Clay (waterfall)	71%	93%	80%

The LinkedIn-first column looks like what you'd expect. The Twitter-first column is where it gets interesting — and where most tools quietly fall apart.

What's happening with Twitter-first enrichment

Apollo returns an email on 41% of Twitter-first lookups. That sounds usable until you look at how. Apollo's matching on Twitter is fuzzy — it uses the handle plus the name to find a profile in its contact graph, then returns the email associated with that profile. I found 14 cases where the Twitter handle matched a former employee at the same company (the company's generic @CompanyName handle mapped to the wrong individual). Accuracy on the 41 found emails was 84%, so roughly 7 of those 14 mismatches landed in my verified set.

People Data Labs performed best on Twitter-first at 67%. PDL's data model explicitly links social handles to person records, and their API accepts twitter_username as a match field directly. The tradeoff: PDL returns email with lower confidence tagging than LinkedIn-first matches, and accuracy dropped to 79% on Twitter-first versus 81% on LinkedIn-first. They're doing more probabilistic matching.

Wiza is built for LinkedIn extraction and it shows — 89% LinkedIn-first coverage is the highest in my test, but Twitter-first drops to 12%. Wiza doesn't accept a raw Twitter handle; you'd need to already know the LinkedIn URL or find it separately. That's a tool design choice, not a data gap.

Clay's waterfall approach (combining PDL, Apollo, and Clearbit in sequence) hit 71% Twitter-first and 93% LinkedIn-first, but costs stack. For a 400-record run I was looking at roughly $180 in credits doing Twitter-first enrichment through a three-provider waterfall versus about $85 doing domain-first.

What Group D (public lists) revealed

The 100 contacts from public event speaker lists and OSS contributor pages were the hardest to enrich. These folks often have:

• Separate personal and work email addresses
• Twitter as their primary public identity, LinkedIn as an afterthought
• Frequent job changes (conference speakers move around)

LinkedIn-first coverage for Group D dropped to 58% (versus 78–89% for Groups A–C). PDL Twitter-first held at 59%. The email accuracy fell sharply — 68% for PDL on this group, because the returned email was often a personal Gmail or a stale work address from a previous employer.

I ran 40 of these through Maigret to see what OSINT could find. Maigret found active profiles on Substack, GitHub, and personal sites for 31 of 40. In 18 cases those profiles listed a contact email. Of those 18 emails, 11 matched the verified work inbox. Not a workflow for scale, but useful for high-value targets where data quality matters more than speed.

Phone coverage from social lookups

This was the most disappointing part of the test.

Tool	Twitter-first phone coverage	LinkedIn-first phone coverage
Apollo	8%	22%
People Data Labs	11%	19%
Lusha	5%	31%
Kaspr	3%	28%
Cognism	2%	18%

Social-first enrichment is almost useless for phone numbers. This tracks — phone data comes from professional databases and verified directory sources, not from social profile matching. If you need mobile numbers you still need to start from a domain or run LinkedIn profile extraction at scale through a tool built for it.

The company enrichment gap

A consistent gap I found: when I queried PDL or Apollo with a Twitter handle alone (no company context), the tool often couldn't determine which company the person currently worked at. Twitter bios are free-form and stale. 23% of the handles in my dataset had bios that listed a company the person had left in the previous 18 months.

Clay partially solves this by running a waterfall that cross-references the Twitter handle against LinkedIn data through the People Data Labs enrichment step. But that adds a step and credits. If you're building a workflow that starts from Twitter engagement data — who liked your tweet, who your competitor's followers are — you need to budget for at least two enrichment calls per contact.

Verifying the emails you find

On emails returned from social-first lookups, bounce rates are higher than domain-first. I sent cold campaigns to two groups: 200 LinkedIn-first verified emails and 200 Twitter-first verified emails (both running through my standard validation step with ZeroBounce first). LinkedIn-first: 3.2% bounce. Twitter-first: 7.8% bounce. The Twitter-first group had significantly more catch-alls and more soft bounces after 72 hours.

If you're doing Twitter-first enrichment for outbound, add ZeroBounce or NeverBounce before sending. Budget for roughly double the invalid rate compared to what you'd see from domain-first list building.

What I actually use

For LinkedIn-first enrichment, Wiza gives the cleanest email quality when I have LinkedIn URLs. For domain-first enrichment, Hunter.io remains fast and honest about confidence scores. For building contact data from a mix of Twitter handles and LinkedIn URLs, I run a PDL lookup first (it handles both natively), then waterfall into Apollo for the PDL misses.

For Twitter/Facebook profiles specifically — the cases where I'm enriching OSINT signals or running intelligence on social-active founders — Ziwa has been faster for me than PDL's direct API for returning profile context and linked contact data. It doesn't replace a full enrichment waterfall, but for social-first lookups on a smaller list it cuts the workflow from three tools to one.

For Group D contacts (public figures, conference speakers), I skip automated enrichment entirely on the first pass. Fifteen minutes with Maigret and a look at their Substack or personal site usually gets me further than running credits through tools that weren't built for that data profile.

The main takeaway from 400 contacts: the tool that works best depends almost entirely on what you're starting with. LinkedIn URL = use LinkedIn-optimized tools. Twitter handle = use PDL or a waterfall. Public OSINT target = skip the APIs and look at their digital trail first.