# PeopleDB — Full Reference > PeopleDB is a contact intelligence API for developers. It accepts a LinkedIn profile identifier or GitHub username as input and returns a unified contact record containing verified email addresses (classified as personal or work), phone numbers, and linked social handles. Pricing is credit-based with no monthly subscription. Credits range from 15¢ per lookup at the 100-credit tier down to 6¢ per lookup at 50,000 credits. Credits do not expire. New accounts receive 10 free credits with no payment method required. This file contains the full reference content. A shorter index is at https://peopledb.co/llms.txt ## Pricing Credit-based, pay per successful lookup (a lookup that returns at least one email address). No subscription. Credits never expire. | Credits | Price | Per lookup | |---|---|---| | 100 | $15 | 15¢ | | 500 | $60 | 12¢ | | 2,000 | $200 | 10¢ | | 10,000 | $750 | 7.5¢ | | 50,000 | $3,000 | 6¢ | New accounts receive 10 free credits, no payment method required. Volumes above 50,000 lookups: contact@peopledb.co for a custom contract. ## API Reference Base URL: https://peopledb.co/api/v1 (see https://docs.peopledb.co for the interactive reference and full schemas). Authentication: Bearer token in the Authorization header. ### GET /people Retrieve contact information for a person. Accepts exactly one of these query parameters: - linkedin_id: LinkedIn ID to search by - linkedin_public_identifier: LinkedIn public identifier (username) - github_id: GitHub ID to search by - github_login: GitHub login (username) Returns aggregated contact information: known email addresses (classified personal/work), phone numbers, and social usernames. email_addresses is only present when at least one address was found. Responses: 200 (profile found), 400 (missing parameters), 401 (invalid or missing bearer token), 402 (insufficient credits), 404 (no profile found). Credits are only charged when at least one email address is returned. ### GET /email_verifications SMTP-validate an email address. Parameters: - email_address: the address to validate (required) - timeout: SMTP check timeout in seconds (optional) Responses: 200 (validation completed), 400 (missing email_address), 401 (invalid or missing bearer token). ## Product Surfaces - Web tool, LinkedIn: https://peopledb.co/tools/linkedin-lookup (single lookups by LinkedIn profile URL) - Web tool, GitHub: https://peopledb.co/tools/github-lookup (single lookups by GitHub username, account ID, or profile URL) - Web tool, noreply decoder: https://peopledb.co/tools/github-noreply-decoder (decodes ID+username@users.noreply.github.com addresses; the number is the permanent account ID, the pre-2017 format has no ID; then resolves the person) - Email verification API page: https://peopledb.co/email-verification-api (what the /email_verifications endpoint checks, how the 0 to 100 score is built, and billing: one credit per check, invalid results free) - Chrome extension: https://peopledb.co/chrome-extension (lookups from LinkedIn profiles in the browser) - Zapier integration: https://peopledb.co/zapier (no-code enrichment automation) - Comparisons: /clearbit-alternative, /contactout-alternative, /apollo-alternative, /hunter-alternative - OpenAPI spec: https://docs.peopledb.co/openapi.yaml ## Guide: Contact Enrichment APIs (https://peopledb.co/contact-enrichment-api) A contact enrichment API takes an identifier you already have for a person (an email address, a name and company, a LinkedIn profile, or a GitHub username) and returns the contact information you don't have: verified email addresses, phone numbers, and social profiles, over HTTP. Every such API reduces to the same contract, identifier in and contact record out; the differences that matter are which identifiers it accepts, what the record contains, and how you pay when the lookup fails. Enrichment is not prospecting. Prospecting finds people you didn't know about, via filters like title and industry. Enrichment completes the record of a person you already identified. Platforms bundle both; enrichment-only APIs do just the second, which is why they can be priced per lookup instead of per seat. Direct providers maintain their own index and answer from it. Waterfall providers hold little data themselves; they relay each lookup through several underlying vendors and return the best hit, usually charging only for verified results. Waterfalls buy the market's combined match rate at the market's combined price; direct providers are cheaper per lookup and faster, but bounded by their own coverage. How to evaluate one: run a sample of your own identifiers through it and measure match rate and bounce rate, because generic accuracy claims don't transfer across audiences. Then check what happens on a miss (the honest models charge on results, not attempts), whether the API is self-serve, and whether addresses are verified before you are charged for them. Match rates differ between vendors because coverage is shaped by how each index is built and how aggressively stale records are pruned. PeopleDB is a direct, person-first enrichment API with a deliberately narrow contract: a LinkedIn or GitHub identifier in, verified emails (classified personal or work), phone numbers, and social handles out. Lookups are prepaid (15¢ down to 6¢ at volume), charged only when at least one email is returned, and credits never expire. There is no discovery, no platform, and no sales call. ## Blog Posts (full text) --- ### There's no clean way to verify an email address. Here's what works anyway. Published 2026-05-08 · https://peopledb.co/blog/verify-email-address · by Erik Strömberg You have a list of addresses. Maybe they came from a signup form, a partner CRM, an enrichment run, or last quarter's webinar. You want to know which ones are real before you put them on a campaign and torch your sender reputation. You search "email verification" and find a hundred services with landing pages claiming 99% accuracy. You install the obvious package, run it on your list, and 95% come back "valid." You send. A quarter of them bounce, and the major inbox providers start flagging your domain. What happened? Some combination of: syntax-valid addresses that don't exist, mail servers that lie, catch-all domains, greylisting, and anti-probe behavior. "This is a real mailbox" is much harder to prove than it looks. Here's how the protocol actually works, where it breaks, and what a serious verifier has to do about it. ## Syntax checks filter the obvious garbage and nothing else Run a regex against `[email protected]` and you'll catch the obvious malformed strings. Use a real RFC 5322 parser and you'll catch a few more (`john..doe@example.com`, leading whitespace, addresses with control characters). ```python import re EMAIL_RE = re.compile(r"^[^@\s]+@[^@\s]+\.[^@\s]+$") EMAIL_RE.match("definitelynotreal@gmail.com") # matches ``` `definitelynotreal@gmail.com` passes every syntax check ever written. It does not exist. Syntax validation tells you whether a string *could* be an address; it tells you nothing about whether it *is* one. You still want this as a first pass — there's no point burning network calls on `not an email`. But anyone who ships a regex as their email verifier is solving a different problem than they think they are. ## DNS proves the domain accepts mail (and nothing else) ```bash dig +short MX example.com # 0 mail.example.com. ``` If a domain has no MX record (and no fallback A record per [RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321)), it doesn't accept mail at all. Marking the address invalid is correct. This catches typo-domains, expired domains, and domains that were never set up for email. But `gmail.com` has MX records. So does every Fortune 500. So does every catch-all spam trap. MX-exists tells you the domain is in the mail business, not that the address you care about exists on it. ## Talking SMTP to the server This is where every "real" verifier lives. You connect to the destination MX server, walk through the SMTP handshake, and stop one step short of actually sending the email: ``` $ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -crlf 220 mx.google.com ESMTP ready EHLO verifier.example.com 250-mx.google.com at your service ... MAIL FROM: 250 2.1.0 OK RCPT TO: 550 5.1.1 The email account that you tried to reach does not exist QUIT ``` The signal is in the `RCPT TO` response: - `250` → server says it would accept mail for this address - `550` / `551` → mailbox doesn't exist - `4xx` → temporary failure, try again later - nothing, eventually a timeout → ¯\\\_(ツ)\_/¯ A naive verifier writes this loop in twenty lines and ships. It is wrong roughly as often as it is right, for reasons that have nothing to do with the code. ## Why the SMTP handshake lies Modern mail servers know that automated probers exist, and they don't make life easy for them. **Catch-all domains.** Many companies configure their inbound to accept *any* address at their domain and route unmatched ones to a default mailbox or a black hole. Probe `xq8z29zz@somecompany.com` and you get `250 OK`. Probe `ceo@somecompany.com` and you get `250 OK`. They both look identical from the outside; one of them is the CEO and the other is gibberish. If the domain is catch-all, RCPT TO is meaningless. You detect this by sending a deliberate-fake probe first and inferring catch-all from a positive response — something like `definitely-does-not-exist-12345@domain.com`. Any verifier that doesn't do this catch-all check is silently classifying random nonsense as valid mail on every catch-all domain it sees. **Greylisting.** A receiver returns `451 try again later` on first contact from an unknown sender. Legit MTAs queue and retry minutes or hours later. Probers usually don't. Naive verifiers mark these as failed; the addresses are fine. **Anti-probe behavior on the big providers.** Gmail, Outlook, Office 365, Proofpoint, Mimecast, and several other large inbound systems either always return `250` regardless of the mailbox, or always return `4xx` to anything that smells like a verifier. A handshake against `gmail.com` does not tell you whether the address exists on Gmail; it tells you that Gmail received a connection. Any verifier that reports a clean "valid" on a Gmail address from a single RCPT TO probe is making it up. Serious tools maintain a list of these providers and fall back to other signals when they hit one. **Outbound IP reputation.** Even when the receiver is willing to give you a real answer, it'll only do it if your sending IP doesn't look hostile. If you've been hammering a domain — or, more likely, if the IP block you happen to be on has been hammering it — you'll be tarpitted, throttled, or refused at HELO. Running verification from a residential IP, an EC2 box without rDNS, or a VPN basically doesn't work. **Tarpitting.** Some servers respond to `RCPT TO` slowly on purpose — 30 seconds per probe, deliberately — to make automated verification economically unviable. Your verifier needs to handle long timeouts on some domains without falling over on the rest. **Some servers only check on DATA.** They accept any `RCPT TO` and only bounce after you've sent the body. Verification-without-sending is impossible against those servers; the most you can do is flag them. **Port 25 is often blocked outbound.** Most cloud providers and residential ISPs block outbound 25 to limit spam. A naive verifier from your laptop or your default EC2 instance will silently fail the SMTP step on every domain. Real verifiers connect from infrastructure with port 25 open, and fall back to 587/465 with STARTTLS when needed. ## What "good" verification looks like A serious verifier does, roughly: 1. Syntax-check the address. 2. Suggest typo corrections for common domains (`gmial.com` → `gmail.com`). 3. Look up MX (and A as fallback). 4. Check disposable-domain lists (Mailinator, 10MinuteMail, Guerrilla Mail, and a few hundred others). 5. Identify the receiver: Gmail, Outlook/Office 365, Yahoo, ProtonMail, Proofpoint, Mimecast, an in-house Postfix, etc. The provider determines which signals are trustworthy. 6. For receivers known to give honest `RCPT TO` responses, probe — from a warmed-up IP with valid rDNS, sensible HELO, and conservative pacing per destination domain. 7. Detect catch-all by probing a fake address first. 8. Honor `4xx` by retrying with backoff over hours, not seconds. 9. For receivers known to lie, fall back to historical signals: has this address shown up in our previous deliveries? Has it bounced before? 10. Classify each result honestly. "Valid / invalid" is the wrong vocabulary; you need at least three buckets — *deliverable*, *undeliverable*, and *risky* (catch-all, greylisting timeout, large-provider unknown). Sending into the risky bucket is a business decision, not a technical one. The infrastructure question is harder than the protocol question. You need a pool of warmed sending IPs, a monitoring system for IPs starting to bounce, per-receiver rate limiters, a queue that respects greylist retry intervals, and a database of which providers behave how. Get any of that wrong and the answers you get are noise. ## Things people get burned by - **Treating "catch-all" as "valid."** Catch-all means *I don't know whether this mailbox exists*, not *yes, it does*. Sending into a catch-all domain blindly is one of the cleanest ways to end up flagged for spam, because spam traps love catch-alls. - **Trusting role-based addresses.** `info@`, `support@`, `sales@`, `noreply@` are almost always deliverable. They're almost never the right address for cold outreach, and many ESPs treat marketing mail to role addresses as a strong spam signal. - **Running checks at send time.** Don't verify in your signup form's request handler. The verification call can take seconds, sometimes tens of seconds. Verify async, or against a cached lookup, never inline. - **Bulk-probing without pacing.** A loop that fires 1,000 RCPT TO calls at the same Google Workspace tenant gets that tenant's whole verification surface to lock you out for the rest of the day. Per-domain pacing is mandatory. - **Ignoring the score.** A binary "valid: true" hides a lot. An address that passes syntax + MX + disposable but where the SMTP step had to be assumed (problematic provider, timeout, IP-blocked) is a different animal from one that got a clean `250` from a non-catch-all server. Anything that doesn't expose its confidence is hiding bad news. ## The shortcut This is what `/api/v1/email_verifications` does at PeopleDB. The protocol piece, the receiver classification, the catch-all detection, the IP reputation, the disposable-domain list, and the typo suggestions all run on the server side; you get one HTTP call: ```bash curl "https://peopledb.co/api/v1/email_verifications?email_address=somebody@example.com" \ -H "Authorization: Bearer $PEOPLEDB_TOKEN" ``` ```json { "email": "somebody@example.com", "valid": true, "classification": "valid", "score": 95, "checks": { "syntax": true, "mx_record": true, "smtp_deliverable": true, "disposable": false, "typo_suggestion": null, "accepts_any_email": false }, "warnings": [], "errors": [] } ``` The classification has three states: `valid`, `risky`, `invalid`. *Risky* is the honest one — catch-all domains, large providers that won't tell you the truth over SMTP, and disposable addresses all surface there. The score is 0–100 so you can pick your own threshold per use case (a stricter cutoff for cold outreach than for password reset). If you've got a list, run it through this before you put it on a sender. SMTP is a thirty-year-old protocol layered with anti-abuse, and the difference between a verifier that knows that and one that doesn't is the difference between a clean send and a deliverability incident. --- ### There is no LinkedIn email API. Here's what to use instead. Published 2026-05-04 · https://peopledb.co/blog/linkedin-email-api · by Erik Strömberg You have a LinkedIn URL. You want the person's email. You search "linkedin email api" and find a maze of marketing pages and Stack Overflow threads from 2018 that all say roughly the same thing: there isn't one. That's true. There is no first-party LinkedIn API that takes a profile URL and returns an email address. There never has been, and there isn't going to be. But there is a perfectly normal way to do this, and it's been quietly running under the hood of every CRM, sales tool, and recruiting platform for a decade. Here's what's actually going on. ## What LinkedIn's APIs actually return LinkedIn does have APIs. They are aggressively gated and aggressively scoped: - **Marketing Developer Platform** — ad campaign management, ad analytics, posting on behalf of pages. No contact data. - **Talent Solutions API** — for ATS integrations. Returns candidates *who applied to your job*, not arbitrary lookups. - **Sales Navigator API** — internal use by Sales Nav itself, not really a public developer surface. - **Sign In With LinkedIn (OIDC)** — returns the email of the *signed-in user*, with their consent, scoped to that session. You cannot use this to look up anyone else. - **Profile API** — restricted to LinkedIn-approved partners with formal agreements; even then, contact info isn't part of the schema for anyone other than the authenticated user. Every LinkedIn API exposes data about the authenticated user (consent-driven) or paid customer activity within your own account. None of them lets you say "give me the email for `linkedin.com/in/somebody`." Why? Because that's not what LinkedIn sells. LinkedIn's product is the platform — the network effect, InMail, recruiter seats. Letting third parties bypass that with a `GET` would directly compete with their own monetization. ## What "LinkedIn email API" actually means When developers search for it, they almost always mean this: ``` GET /lookup?linkedin_url=https://linkedin.com/in/somebody → { "email": "somebody@example.com", ... } ``` That's not a LinkedIn endpoint. It's an *enrichment* endpoint, served by a third-party service that maintains its own contact database and uses the LinkedIn URL as a join key. Aggregators have been building these databases for over a decade by combining: - **Public-web signals** — corporate websites, conference speaker bios, GitHub commits, press releases, paper authorships, podcast guest pages. - **Contributed data** — address books voluntarily uploaded by users of various email and CRM tools, contact graphs from sales acceleration platforms, opt-in business directories. - **B2B partnerships** — companies that have shared customer lists in business-data co-ops in exchange for access to the pooled data. - **Verification feedback** — every time a user marks an email as bounced or correct, the database learns. None of this requires LinkedIn's permission, because none of it comes *from* LinkedIn. The LinkedIn URL is the lookup key, not the source. ## The two LinkedIn identifiers worth knowing Before you can hit any of these APIs, you need to extract a stable identifier from the LinkedIn URL the user gave you. There are two: **1. The public identifier (slug):** ``` https://linkedin.com/in/williamhgates ^^^^^^^^^^^^^^^ public_identifier ``` Stable until the user customizes it. Most enrichment APIs accept this as the input. **2. The numeric LinkedIn ID:** Sometimes you'll see URLs like: ``` https://linkedin.com/in/ACoAAA-3B7U-_b0123abc/ ``` That long string is an opaque, account-scoped encoding of the user's internal numeric ID. It looks intimidating, but for lookup purposes it functions as just another stable identifier — useful when the slug isn't available (e.g. some recruiter or Sales Navigator URLs). When parsing user-supplied LinkedIn URLs, handle both: ```python from urllib.parse import urlparse def parse_linkedin_url(url): path = urlparse(url).path.strip("/") if not path.startswith("in/"): return None slug = path.split("/")[1] # ACoAA... = numeric URN, anything else = public identifier if slug.startswith("ACoAA"): return ("linkedin_id", slug) return ("linkedin_public_identifier", slug) parse_linkedin_url("https://linkedin.com/in/williamhgates") # → ("linkedin_public_identifier", "williamhgates") ``` ## What the lookup actually does Pseudocode for what a serious enrichment API runs when you hit it: ```python def lookup(identifier): # 1. Find every record across every source that matches this identifier matches = profiles.where(linkedin_public_identifier=identifier) if not matches: return None # 2. Expand: pull in any other records that share an email or # secondary identifier with the initial matches. # A person often has separate records from separate sources; # this is how you merge them. matches = expand_by_shared_attributes(matches) # 3. Collect emails, phones, social handles emails = dedupe([e for m in matches for e in m.emails]) return { "linkedin_public_identifier": identifier, "email_addresses": emails, "phone_numbers": [...], "github_login": ..., "twitter_username": ..., } ``` Two non-obvious things going on here: - **Identity resolution is the hard part.** There's no canonical "person ID" across sources. You have to chain matches: this LinkedIn record shares an email with a CRM record, which shares a phone with a conference-speaker entry, etc. Done well, you end up with a merged view. Done badly, you accidentally fuse two different people who happen to share a generic `info@` inbox. - **Email classification matters more than people think.** Anyone serious will separate personal addresses (`@gmail.com`, `@protonmail.com`) from work addresses. Outreach into a personal inbox has very different deliverability and acceptable-use implications than reaching someone at their employer. ## A practical example Here's enriching a CSV of LinkedIn URLs into emails, end to end: ```python import csv import requests from urllib.parse import urlparse API = "https://peopledb.co/api/v1/people" TOKEN = "YOUR_TOKEN" def parse(url): path = urlparse(url).path.strip("/") if not path.startswith("in/"): return None slug = path.split("/")[1] return ("linkedin_id", slug) if slug.startswith("ACoAA") else ("linkedin_public_identifier", slug) def lookup(url): parsed = parse(url) if not parsed: return None param, value = parsed r = requests.get( API, params={param: value}, headers={"Authorization": f"Bearer {TOKEN}"}, ) return r.json() if r.ok else None with open("input.csv") as f, open("output.csv", "w", newline="") as out: reader = csv.DictReader(f) writer = csv.DictWriter(out, fieldnames=["linkedin_url", "name", "work_email", "personal_email"]) writer.writeheader() for row in reader: result = lookup(row["linkedin_url"]) or {} writer.writerow({ "linkedin_url": row["linkedin_url"], "name": row.get("name", ""), "work_email": (result.get("work_email_addresses") or [""])[0], "personal_email": (result.get("personal_email_addresses") or [""])[0], }) ``` That's the whole pipeline: parse, look up, write. The interesting work happens server-side; the client is twenty lines. ## Things to keep in mind A few things worth being honest about: - **Coverage is not 100%.** Aggregator APIs hit on a meaningful fraction of profiles — but never all of them. Plan for misses, not just hits. - **Data ages.** People change jobs, drop addresses, move to new domains. Anything you enrich today should be re-validated before you use it months later. - **Verify before sending.** A correctly-resolved email that bounces is still a bounce. SMTP-level validation (or a verification endpoint, if your provider has one) before bulk outreach is table stakes. - **Compliance is on you.** If you're enriching contacts at scale and reaching out from the EU or UK, GDPR's legitimate-interest tests apply. CCPA in California, CASL in Canada, similar regimes elsewhere. The API gives you data; what you do with it is your problem. - **Don't scrape LinkedIn directly.** Aside from the ToS issues, you'll be fighting CAPTCHAs and IP bans within minutes. The whole point of an enrichment API is that someone else has already absorbed that operational cost — across many sources, not just LinkedIn. ## The shortcut This is what PeopleDB does. The endpoint accepts either identifier: ```bash # By public identifier (the slug) curl "https://peopledb.co/api/v1/people?linkedin_public_identifier=williamhgates" \ -H "Authorization: Bearer $PEOPLEDB_TOKEN" # By numeric ID curl "https://peopledb.co/api/v1/people?linkedin_id=ACoAAA-3B7U-_b0123abc" \ -H "Authorization: Bearer $PEOPLEDB_TOKEN" ``` ```json { "linkedin_public_identifier": "williamhgates", "linkedin_id": "...", "github_login": null, "email_addresses": ["..."], "personal_email_addresses": ["..."], "work_email_addresses": ["..."], "phone_numbers": ["..."] } ``` The same identity-resolution layer also accepts `github_login` and `github_id`, so if a person shows up under both LinkedIn and GitHub in the index, you get the union — useful when you've got a contributor's GitHub handle but want to reach them at their work address. There is no first-party LinkedIn email API. There probably never will be. What there is, is a category of enrichment APIs that have been quietly solving this for years. That's the trade. --- ### Why finding a GitHub user's email is harder than you'd think Published 2026-05-03 · https://peopledb.co/blog/finding-github-users-email · by Erik Strömberg You've found a contributor whose work you depend on. The maintainer of a package you use, a developer who fixed something for you upstream, the author of a CVE you need to coordinate with. You have their GitHub username. You'd like their email. You'd think this would be a `GET` away. It isn't. Here's why — and what it actually takes to find one. ## The GitHub API doesn't have it `GET /users/:login` returns an `email` field. For the vast majority of users, that field is `null`. GitHub flipped private-by-default years ago. When you sign up today, your commit email is set to `+@users.noreply.github.com` and the public profile email field is empty. Older accounts that opted in still expose addresses, but they're a minority — and the people you actually want to reach (active maintainers, security-conscious developers) are exactly the ones who turned this off. So that's out. ## The commits don't have it either (mostly) The next obvious move: look at the user's commits. Every commit has an author email in its metadata. Pick a public repo, fetch the commit, get the email. ```bash curl https://api.github.com/repos/torvalds/linux/commits | jq '.[0].commit.author.email' # "torvalds@linux-foundation.org" ``` That works for Linus. It does not work for most people. Run this against any reasonably modern repo and you'll see a lot of: ``` "49699333+dependabot[bot]@users.noreply.github.com" "12345678+somecontributor@users.noreply.github.com" ``` GitHub rewrites commit emails to the `noreply` form whenever the author has the "Keep my email addresses private" setting on, which is the default. The `+` part is the user's GitHub ID and login — useful if all you wanted was to identify them, but you already had their login. You wanted to *email* them. ## The events archive: harder, but real data There's another source that dev tooling people sometimes forget about: the public events stream. GitHub publishes a firehose of public events (pushes, opens, comments, releases) and [GH Archive](https://www.gharchive.org/) has been recording it hourly since 2011 — terabytes of newline-delimited JSON, gzipped, freely downloadable. Each `PushEvent` carries the underlying commit metadata, including author name and email. In principle, if a developer ever pushed a commit *before* they turned on private email — or if they push from a CI pipeline that uses a real address — that email is in the archive. The job that processes it looks roughly like this: ```ruby gz = Zlib::GzipReader.new(StringIO.new(http.get(archive_url).body)) gz.each_line do |line| event = JSON.parse(line) next unless event["type"] == "PushEvent" login = event.dig("actor", "login") event.dig("payload", "commits").to_a.each do |commit| author_name = commit.dig("author", "name") author_email = commit.dig("author", "email") # ... we have a (login, name, email) triple. Now what? end end ``` You scan a few hours of archive and immediately find a problem. A lot of those emails look like this: ``` 8a3f9b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80@gmail.com ``` Forty hex characters. That's a SHA-1 hash. The local part of the email has been one-way-hashed; only the domain is in the clear. This is a historical artifact of how the events feed has been emitted for stretches of GitHub's history — commit emails arriving with the local part obfuscated. Great. Now you have a hash. ## Reversing the hash SHA-1 of an arbitrary string is a one-way function. SHA-1 of an email local part is not, because email local parts are not arbitrary. They're drawn from a tiny, predictable distribution: `firstname`, `firstname.lastname`, `f.lastname`, `firstnamelastname`, `firstname_lastname`, `firstname1985`, and a few hundred other patterns layered over a finite list of names. If you precompute a table of `sha1(local_part) → local_part` for every plausible candidate — every name you've ever encountered, every email you've ever seen published — you can reverse most of these in O(1). ```ruby if email =~ /^([a-f0-9]{40})@(.+)$/ hash, domain = $1, $2 if (record = Sha1Hash.find_by(sha1_hash: hash)) real_email = "#{record.text}@#{domain}" end end ``` The lookup table is the asset. Building it well is most of the work. Mine is hundreds of millions of rows and grows every time the world publishes another address. ## The harder problem: was that actually them? You now have a `(login, author_name, real_email)` triple. The temptation is to claim the email belongs to the login. Don't. Anyone can configure git locally. People commit with `user.name` set to their full legal name, their nickname, "John", "John D.", "johndoe", "John Doe via Acme Corp", "Acme CI Bot", or — frequently — *someone else's name entirely*, because they cloned a repo on a coworker's machine and never reconfigured. A login pushes hundreds of commits over the years; many of them carry author names that don't actually identify the person behind the login. So you need a confidence layer. Mine is a separate pass over the same archive that builds a `(login, author_name) → observation_count` table: ```sql CREATE TABLE github_login_author_name_mappings ( login text, author_name text, observation_count int, PRIMARY KEY (login, author_name) ); ``` When a hash reverses to a candidate email, I look up every author name that login has ever been observed pushing under, and ask: what fraction of this login's total commits use *this* author name? ```ruby total_count = all_names.sum { |_, count| count } name_count = all_names.find { |name, _| name == author_name }&.last || 0 percentage = (name_count.to_f / total_count.to_f) * 100 # Need at least 10 commits for any signal at all return false if total_count < 10 # With a long history, 50% co-occurrence is enough; with little, demand 80% threshold = total_count > 100 ? 50.0 : 80.0 percentage >= threshold ``` This rejects the noise. The contributor who once pushed a commit signed "Test User" doesn't get linked to a `test.user@example.com` reversal. The CI bot pushing under a real engineer's login but with `git config user.name "Buildkite"` doesn't pollute the index. What survives is the set of (login, name) pairs that consistently co-occur — a fairly trustworthy proxy for "this is the human behind this login." ## What's left Doing this for one user, end to end: 1. Identify which monthly archive shards likely contain their activity. 2. Stream and decompress hundreds of gigabytes of JSON. 3. Maintain a SHA-1 lookup table of every plausible email local part you've ever seen. 4. Maintain a parallel `(login, author_name)` co-occurrence index across the entire archive. 5. For every reversed hash, run the confidence check. 6. Validate the resulting email isn't already claimed by a different GitHub login (people misconfigure git constantly). 7. Verify the address actually accepts mail before you rely on it. That's a multi-day backfill the first time, hundreds of gigabytes resident, and a continuous trickle of new data forever. Perfectly reasonable to build if finding email addresses for GitHub users is your full-time job. Absurd to build if you just need to email three maintainers about a CVE. ## The shortcut This is the work PeopleDB does in the background. The pipeline above — archive ingestion, hash reversal, identity correlation, deduplication, SMTP validation — runs continuously. The answer is one HTTP call: ```bash curl "https://peopledb.co/api/v1/people?github_login=octocat" \ -H "Authorization: Bearer $PEOPLEDB_TOKEN" ``` ```json { "github_login": "octocat", "github_id": 583231, "linkedin_public_identifier": "...", "email_addresses": ["..."], "personal_email_addresses": ["..."], "work_email_addresses": ["..."] } ``` The endpoint also accepts `github_id`, `linkedin_id`, and `linkedin_public_identifier` — the same identity-merging logic runs across all of them, so if a person has both a GitHub and a LinkedIn record in the index, you get the union. If you're doing security disclosure, contributor outreach, or any kind of identity resolution where you start with a username and need to actually reach the human, that's the trade: spin up the pipeline, or skip it. --- ### Clearbit is gone. Here's what to use instead. Published 2026-08-27 · https://peopledb.co/blog/clearbit-alternatives · by Erik Strömberg If you landed here from a search for "Clearbit alternative", here is the situation in one paragraph: Clearbit no longer sells to new customers. HubSpot acquired it in December 2023 (for $140M, per HubSpot's 10-K), folded its data into what became Breeze Intelligence, shut down the free Clearbit platform and Connect in April 2025, and sunset the free Logo API in December 2025. Today clearbit.com is a banner announcing the acquisition and a login link for existing customers. If you want Clearbit's data now, the answer is "become a HubSpot customer." If that's not your plan, you need a replacement, and the right one depends entirely on what you were using Clearbit for. I build one of the tools below, so read the recommendations knowing that. I've tried to be precise about what each tool is for, including the cases where mine is the wrong choice. ## What actually happened to Clearbit The timeline, for the record: - **November 2023**: HubSpot announces the acquisition. - **December 2023**: Deal closes. - **September 2024**: HubSpot unveils Breeze Intelligence at INBOUND, built on Clearbit's dataset ("over 200 million company and buyer profiles"). - **April 2025**: The free Clearbit platform, Weekly Visitor Report, Clearbit Connect, and the free Slack integration are discontinued. - **December 2025**: The free Logo API (`logo.clearbit.com`), the way half the internet's side projects rendered company logos, goes dark. Clearbit's own changelog points people to Logo.dev. The API docs now redirect to a login page. There was never a single announced cutoff date for new standalone customers; the door just quietly closed during 2024. Enrichment survives inside HubSpot subscriptions, where it draws on HubSpot's dataset and third-party sources. That's a fine outcome for HubSpot customers and a dead end for everyone else, which by traffic volume appears to be most people searching for this. ## How to pick a replacement Clearbit was several products wearing one brand: a company-data API keyed by domain, a person-enrichment API, a visitor-deanonymization pixel, and the logo endpoint. No single tool replaces all of it, so start from the question that actually matters: **what's the input at the start of your workflow?** - You have a **domain** and want company data or email addresses at it: Hunter. - You have a **name and company** and want to discover and sequence prospects: Apollo, or Lusha if compliance certifications matter to procurement. - You're a **recruiter clicking through LinkedIn**: ContactOut. - You have **assorted identifiers** and want the highest possible match rate, cost be damned: FullEnrich's waterfall. - You want **straightforward person lookups** with a self-serve API: RocketReach. - You want **person and company data from one key**, the way Clearbit used to work: LinkFinder AI. - You have a **LinkedIn or GitHub identifier** in a database column and want emails and phones back over HTTP: PeopleDB, the one I build. - You just want **logos**: Logo.dev, per Clearbit's own recommendation. Second question: do you want to pay per seat per month, or per result? Subscriptions favor steady, high, human-driven volume. Per-result pricing favors bursty, programmatic use. Most of the pain people report with these tools is a pricing-model mismatch, not a data-quality problem. All details below were checked against each vendor's public pages on August 27, 2026 (LinkFinder AI on October 11, 2026). Several vendors render pricing client-side, so where I had to lean on third-party pricing guides I say so. Numbers drift; treat them as coordinates, not quotes. ## The alternatives ### Hunter The domain-first choice. Give it a domain, get the email addresses and patterns at it; give it a name plus a domain, get a specific person's address; verify anything before sending. Pricing is credit-based with a permanent free tier (50 credits a month), paid plans from €49/mo (it localizes currency), and, notably, an API key on every plan including the free one, with fully public docs. If your Clearbit usage was "domain in, company and email data out," Hunter is the closest drop-in and the easiest to evaluate this afternoon. ### Apollo Not an enrichment tool so much as an entire outbound sales platform (database, sequences, dialer) that happens to have an enrichment API. Claims 240M+ contacts. Pricing is per seat plus credits, roughly $49 to $149 per user per month depending on tier per third-party pricing guides (their page renders client-side). The API is documented publicly and keys are self-serve, though person enrichment wants a work-email account, and phone numbers cost extra credits. Choose Apollo if you want the whole sales stack in one place. Skip it if you only need enrichment; you'd be buying a platform to use one endpoint. ### ContactOut A recruiter tool: Chrome extension over LinkedIn, search portal, campaigns. Strong on personal emails and phone numbers. Self-serve plans run $49 to $99 per user per month with a fair-use ceiling (their terms cap "unlimited" at 2,000 email credits a month) and a free tier of 5 emails a day. The API exists with public docs, but keys come from booking a sales meeting and API pricing isn't published. Right if you're sourcing candidates by hand all day. Wrong if you wanted an API you can start using today. I wrote a [detailed comparison](https://peopledb.co/contactout-alternative) if this is your shortlist. ### Lusha Contact data for go-to-market teams with the compliance paperwork procurement asks about: SOC 2 Type II, ISO 27001, ISO 27701, GDPR and CCPA language on the homepage. Credit-based and transparently priced ($49.90 to $399.90 a month, with a 40-credit free tier); note that a phone reveal costs 10 credits to an email's 1, which changes the math if you're phone-heavy. The API starts self-serve but has no public price list. A sensible Clearbit replacement for sales teams whose blockers are legal review rather than engineering time. ### RocketReach The plainest of the bunch: a very large lookup database (they claim 700M+ profiles) behind seat-priced plans, roughly $29 to $149 a month annual per third-party guides. The API is documented publicly and keys are self-serve from account settings, with person lookups accepting a name plus employer, or a single identifier like an email or LinkedIn URL. Good when you want simple person-lookup coverage without adopting a platform. The catch: full API access reportedly sits on the top tier, so the entry price and the API price aren't the same number. ### LinkFinder AI The closest thing on this list to Clearbit's original shape: [LinkFinder AI](https://linkfinderai.com) is one API that covers both people and companies. Give it a name, email, domain, or LinkedIn URL and it returns work emails, phone numbers, LinkedIn profiles, and company firmographics. The extras (a Google Sheets add-on, bulk CSV, HubSpot sync, an MCP server) come on every plan instead of being tiered off. Pricing is credit-based and published, from $25 for 1,000 credits that don't expire, with 25 free credits and no card. The catch is the exchange rate: an email costs 10 credits and a phone 50, so the $25 pack works out to 25¢ an email and $1.25 a phone. The monthly plans ($99 for 20,000 credits) bring an email down to about 5¢, if your volume is steady enough to use them. A sensible pick for RevOps teams who want CRM records enriched from one self-serve key without becoming a HubSpot customer to get it. ### FullEnrich A different animal: a waterfall. It cascades your lookup across many upstream vendors and charges only for verified hits, at roughly $0.055 a credit ($55/mo for 1,000). A work email costs 1 credit, a mobile number 10. This is the "maximize match rate" option, effectively paying a broker to query the rest of the market for you. If your list is small and precious (say, hard-to-reach founders), the economics work. If your volume is high and steady, the per-hit cost adds up fast compared to going direct. ### PeopleDB Mine, so the pitch will be short and you can [check the comparison table yourself](https://peopledb.co/clearbit-alternative). PeopleDB is an API for one job: pass a LinkedIn or GitHub identifier, get back verified emails (split personal/work), phone numbers, and linked social handles. Pricing is published to the cent (15¢ a lookup at the smallest tier, 6¢ at volume), credits never expire, you're only charged when a lookup returns an email, and a new account has a working key and 10 free credits in about two minutes with no card. It is deliberately narrow. There's no discovery, no search filters, no sequences, no extension. If your workflow starts with a search box, use Apollo or Lusha. If it starts with a database column full of identifiers, especially GitHub logins, which nothing else on this list resolves, this is the one. (Why GitHub lookups are genuinely hard is [its own story](https://peopledb.co/blog/finding-github-users-email).) ## The short version | Tool | Model | Entry | Self-serve API | Best for | |---|---|---|---|---| | Hunter | Credits + subscription | Free tier; €49/mo | Yes, all plans | Domain-first email finding | | Apollo | Per seat + credits | Free tier; ~$49/user/mo | Yes | The full outbound stack | | ContactOut | Per user / month | Free 5/day; $49/mo | No, sales-gated | Recruiters in LinkedIn | | Lusha | Credits + subscription | Free 40 cr/mo; $49.90/mo | Partly | Compliance-minded GTM teams | | RocketReach | Per seat / month | ~$29/mo annual | Yes, top tier | Simple person lookups | | LinkFinder AI | Credits | 25 free credits (2 emails); $25 | Yes, all plans | Person + company enrichment | | FullEnrich | Per verified hit | 50 free credits; $55/mo | Yes, Pro plan | Max match rate, waterfall | | PeopleDB | Per lookup | 10 free credits; $15 | Yes, all accounts | Identifier-to-contact over HTTP | Clearbit's disappearance mostly hurt one specific user: the developer who wanted good data behind a clean API without talking to sales. Most of the industry answered by building platforms. A few of us answered by building APIs. Pick whichever matches the way you actually work, and verify current pricing on the vendor's own site; every number above was true when checked, and some of them won't stay that way. --- ### Seven Apollo alternatives, and the case for staying put Published 2026-09-06 · https://peopledb.co/blog/apollo-alternatives · by Erik Strömberg If you searched for "Apollo alternative", here is the situation in one paragraph. Apollo is a full outbound platform: a database it says holds 240M+ contacts and 30M+ companies, sequences, a dialer, deal boards, a Chrome extension, and an enrichment API, sold per seat with credits on top. Nobody leaves it because it lacks features. People leave for four reasons: they pay for seats they barely use, the phone numbers or European coverage fall short of what the reps need, they want one piece of the bundle and not the rest, or they want an API and not a login. Which of those is yours decides which tool below is the answer, and one of the honest answers is "stay". I build one of the tools on this list, so read the recommendations knowing that. I have tried to be exact about what each tool is for, and to say plainly where mine is the wrong choice. ## What Apollo does well, and who should stay Fairness first. Apollo's free plan is the most generous in the category: unlimited email credits within a fair-use ceiling of 10,000 a month for non-paying accounts, a handful of mobile and export credits, and access to most of the product. Paid seats run $49, $79, and $119 per user per month on annual billing, or $59, $99, and $149 billed monthly, per third-party pricing guides (Apollo's own pricing table renders client-side and would not load for me). The top tier requires a minimum of three seats. Mobile numbers cost credits on top of the seat, roughly 75 to 200 a month depending on tier, again per third-party guides. The API is self-serve, documented publicly, and available even on the free plan, though free accounts get tight limits on enrichment endpoints (Apollo's docs list 50 requests a minute plus hourly and daily ceilings), while paid plans get 1,000 a minute with only the credit balance as a brake. Enrichment consumes credits either way. If your team runs prospecting, sequencing, and calling out of one tool, and you have a few reps who use it every day, Apollo is priced fairly for that and nothing below does all of it better at the price. Stay. Read on if your usage looks like one of the four cases above. ## How to pick Start from the input at the front of your workflow, because that is what actually determines the tool. Pricing model second. - Your input is a **search filter** (title, industry, headcount), you build lists from scratch at enterprise scale, and you have procurement and an integration team behind you: ZoomInfo. - The same, but your reps sell into **Europe** and phone connect rate is the metric that matters: Cognism. - Your input is a **name and company** and reps reveal contacts one at a time from LinkedIn or a search box: Lusha. - Your input is a **spreadsheet of rows** and you want to route each one through several providers and some AI before it lands in the CRM: Clay. - You want an **Apollo-shaped database** at a smaller price with a trial you can start today: Lead411. - Your input is a **domain** and you want the email addresses at it, verified: Hunter. - Your input is a **LinkedIn or GitHub identifier** already sitting in a database column, and you want emails and phones back over HTTP: PeopleDB, mine. Then the pricing question. Per seat per month rewards steady, human-driven daily use. Per result rewards programmatic, bursty, or low-volume use. Most complaints about Apollo I have read are a mismatch between these two rather than a data complaint, and moving to another per-seat tool will not fix a per-seat problem. Vendor facts below were verified from their public pricing pages on September 6, 2026. Where a page would not load or a number came from a third-party guide, I say so. Numbers drift; check their sites before you sign anything. ## The alternatives ### ZoomInfo The incumbent, and the tool Apollo is usually the cheaper alternative to. ZoomInfo sells a contact and company database with intent data, an engagement product, and a large integration catalog, aimed at teams with a RevOps function. Pricing is not published; every button on the site leads to a demo request or a sales conversation. Third-party pricing guides put a three-seat entry contract at roughly $15,000 a year, with median contracts around $30,000, and describe annual terms only. There is an API, but it comes with the contract, not a signup form. Best for enterprise sales organisations that want one vendor, a named account manager, and a procurement-grade paper trail. The honest caveat: if you are leaving Apollo over cost, this is the wrong direction, and you will not learn the real price until the second call. ### Cognism The European specialist. Cognism leads with phone-verified mobile numbers (it claims up to 3x higher connect rates), decision-maker records refreshed every 30 days, and compliance posture: GDPR and CCPA sourcing, Do-Not-Call coverage across Europe, and claimed parity with ISO 27001 and SOC 2 frameworks. Two tiers, Standard and Pro, each bundling five seats, plus CRM Enrichment and Data-as-a-Service as add-ons or standalone products. Prices are not published; every path ends at "talk to sales". A credit is one revealed contact, and a revealed contact can be reused without spending another credit unless the data changes. API access requires a prospecting seat. Best for teams selling into EMEA whose reps live on the phone. The caveat: no free trial and no public price, so evaluating it is a project rather than an afternoon. ### Lusha The simplest per-seat option with prices you can read. A free tier with 40 credits a month, then Starter at $49.90 a month (or $37.45 on annual billing) for 400 credits, Professional at $69.90 ($52.45 annual) for 600, and Premium at $399.90 ($299.95 annual) for 3,400. An email reveal costs 1 credit and a phone reveal costs 10, which changes the arithmetic if your reps mostly want phones. Lusha leans on its compliance certifications in its marketing, which helps when legal review is the blocker. The API is self-serve: the API page promises a key "in seconds" for testing or production, but API pricing is not published and is quoted per use case. Best for small sales teams that want Apollo's contact reveal without Apollo's everything else. The caveat: at 10 credits a phone, the 400-credit Starter plan is 40 phone numbers a month. ### Clay Not a database. Clay is a spreadsheet that calls other people's databases: each row goes through a waterfall of providers (it says 150+ in its marketplace) and any AI or HTTP step you add, then out to your CRM. Two meters run at once: "actions" for orchestration work and "data credits" for buying data. Free gives 500 actions and 100 data credits a month with tables capped at 200 rows and no phone enrichment. Launch starts at $54 a month on annual billing ($60 monthly) at the lowest point on its action slider, with 3,000 data credits; Growth starts at $185 ($205 monthly) and is where HTTP API integrations and webhooks unlock. Enterprise is custom with an annual commitment. Best for a growth engineer who wants full control of the enrichment pipeline and is happy to build it. The caveat: there is no Clay endpoint you call for a person; Clay is the thing that calls endpoints, and you pay Clay's margin on every provider underneath it. ### Lead411 The closest like-for-like swap on this list: a US-centred contact database with verified emails, direct dials, intent signals, and a Chrome extension, at a price that is on the page. Spark is $49 a month for 1,000 exports (or $490 a year for 12,000), Ignite starts at $150 a month ($1,500 a year) with flexible export volumes, and Blaze is custom. A 7-day trial with 50 exports needs no sales call. API access is on Ignite and Blaze only. Best for a small team that wants an Apollo-style database and finds Apollo's credit arithmetic tiring. The caveat: it is a smaller database and a smaller company than the names above, and the API is a $150-a-month feature, not a $49 one. ### Hunter Domain-first. Give Hunter a domain and it returns the addresses and email pattern at it; give it a name plus a domain and it finds the person; verify anything before you send. The free plan carries 50 credits a month and, unusually, an API key. Paid plans start at €34 a month on annual billing (€49 monthly) for 2,000 credits, then €104 for 10,000 and €209 for 25,000 (it localises currency, so you may see dollars). API access is on every plan. Best for anyone whose input is a company website rather than a person, and for cheap, dependable verification. The caveat: it is not a prospecting database with filters, and it has nothing for phones. ### PeopleDB Mine, so I will keep it short and let you [check the head-to-head yourself](https://peopledb.co/apollo-alternative). PeopleDB does one thing: you send a LinkedIn identifier or a GitHub login, and you get back verified email addresses labelled personal or work, phone numbers, and social handles. Pricing is prepaid credits and nothing else: 15¢ a lookup at 100 credits ($15), 12¢ at 500 ($60), 10¢ at 2,000 ($200), 7.5¢ at 10,000 ($750), and 6¢ at 50,000 ($3,000). You are charged only when a lookup returns at least one email. Credits never expire, there is no subscription, and a new account gets 10 free credits and a working API key with no card. There is a separate endpoint for SMTP email verification. The [docs](https://docs.peopledb.co) are public and the [pricing page](https://peopledb.co/pricing) has the full table. It is deliberately narrow. No prospecting database, no search filters, no sequences, no dialer, no CRM. If your workflow starts with a filter, use one of the six above. If it starts with a column of identifiers and a script, this is the one, and it is the only tool on this list that resolves GitHub logins. I wrote up [what an enrichment API should look like](https://peopledb.co/contact-enrichment-api) if you want the longer argument. ## The short version | Tool | Model | Entry | Self-serve API | Best for | |---|---|---|---|---| | Apollo | Per seat + credits | Free tier; ~$49/user/mo annual | Yes, all plans | The whole outbound stack | | ZoomInfo | Annual contract | Not published; ~$15k/yr per third parties | No, with contract | Enterprise RevOps | | Cognism | Seat bundle + credits | Not published | No, needs a seat | EMEA phone-led sales | | Lusha | Credits + subscription | Free 40 cr/mo; $49.90/mo | Yes, price on request | Small teams revealing contacts | | Clay | Actions + data credits | Free tier; $54/mo annual | No person endpoint; HTTP steps on Growth | Custom enrichment pipelines | | Lead411 | Per seat / month | 7-day trial; $49/mo | Yes, Ignite and up | Apollo-shaped database, plainer bill | | Hunter | Credits + subscription | Free 50 cr/mo; €34/mo annual | Yes, all plans | Domain-first email finding | | PeopleDB | Per lookup | 10 free credits; $15 | Yes, all accounts | Identifier-to-contact over HTTP | Apollo's real competition is not one tool. It is the realisation that you were paying for a platform and using a feature. If the feature is prospecting, ZoomInfo, Cognism, Lusha, and Lead411 are the same category at different prices and geographies. If the feature is enrichment, Clay, Hunter, and PeopleDB are three different shapes of the same job, keyed on what you already have. And if you use most of the platform, the cheapest alternative to Apollo is Apollo. Every number above was true on September 6, 2026; verify on the vendor's site before you sign, because several of them will not stay true for long. --- ### Hunter is fine. Here's when you need something else. Published 2026-09-06 · https://peopledb.co/blog/hunter-alternatives · by Erik Strömberg If you searched for "Hunter alternative", the situation is simpler than the listicles make it sound. Hunter is not dead, not acquired, and not hiding its prices. It is a domain-first email finder: give it a company domain and it lists the addresses and the naming pattern it knows at that domain, give it a name plus a domain and it guesses one address and verifies it, and it has had a permanent free tier with an API key attached for years. People go looking for something else for four reasons. The jump from the €49 Starter plan to the €149 Growth plan is steep. Monthly credits reset whether you used them or not. It returns no phone numbers. And the whole model assumes you start from a company, when a lot of workflows start from a person. I build one of the tools below, PeopleDB, so read the rest knowing that. I have tried to be exact about what each tool starts from and what it charges, including the cases where mine is the wrong choice and the cases where the right move is to stay on Hunter. ## What Hunter does well Credit where due. Its pricing page, checked on September 6, 2026, shows a free plan with 50 credits a month, Starter at €49 a month for 2,000 credits (€34 on annual billing), Growth at €149 for 10,000, and Scale at €299 for 25,000, displayed in your local currency. The API is listed on every tier including the free one, and the docs are public. Verification is built into the paid plans and draws on the same credits. There is also a Discover database and email sequences, so a small outbound team can live in it end to end. Stay on Hunter if your question is "who can I email at acme.com", your monthly volume fits inside 2,000 credits, and you like having finding, verifying, and sending in one place. Nothing below does the domain-first job better at that price. The rest of this post is for people whose question is different. ## How to pick Start from the thing you actually have at the top of your workflow. - **A company domain**, and you want the people at it: Snov.io or Skrapp, and honestly Hunter itself. - **A name and a domain**, and you want one deliverable address: Voila Norbert or Anymail Finder. - **LinkedIn profiles** you are clicking through, and you want emails and phones: Lusha, or Skrapp if email is enough. - **A database column of LinkedIn or GitHub identifiers** and an HTTP client: PeopleDB, the one I build. - **A list of addresses** you already have and need to check before sending: ZeroBounce. Then ask how you want to pay. Hunter and most of its peers sell a monthly credit allowance that resets. Some tools charge only when they return a result (Anymail Finder, PeopleDB). Some sell credits that never expire (ZeroBounce, PeopleDB). If your usage is bursty, a subscription is the wrong shape regardless of data quality. Vendor facts below were verified from their public pricing pages on September 6, 2026. Numbers drift; check their sites. Where a page would not load and I had to lean on third-party pricing guides, I say so. ## Domain-first email finders Hunter's direct peers: same input, different packaging. ### Snov.io Snov.io is Hunter with more platform bolted on: domain search, a name-plus-domain finder, a LinkedIn extension, bulk CSV search, verification, drip campaigns, warm-up, and a small CRM. Starts from a domain, a name plus domain, or a LinkedIn URL. Pricing is a subscription with monthly credits: a free Trial tier with 50 credits that renews every 30 days, Starter at $39 a month for 1,000 credits, Pro S at $99 for 5,000, up to Ultra at $738 for 50,000. API and webhooks are on every paid plan but not the free one. Found emails are verified before they are shown to you. Best for a small team that wants the Hunter workflow plus outreach at a lower entry price. Caveat: one credit pool feeds finding, verifying, and campaign features, so 1,000 credits go faster than they would in a plain finder. ### Voila Norbert Norbert does one thing: name plus domain in, one address out, with bulk upload and an API. Starts from a name and a domain, or a CSV of them. Plans are monthly lead allowances: Valet at $49 a month for up to 1,000 leads ($39 on annual), Butler at $99 for 5,000, Advisor at $249 for 15,000, Counselor at $499 for 50,000. "Bulk & API usage included" is printed on every plan, and you get 50 free credits on signup. Verification is sold separately and cheaply: $0.003 per email up to 500,000, $0.001 above that, $2 minimum. Best for anyone who wants a plain finder with an API on the cheapest tier. Caveat: there is no domain search, so if you want the whole list at a company rather than one named person, this is the wrong tool. ### Anymail Finder Anymail Finder's pitch is that you only pay for deliverable addresses. Starts from a name plus a company or domain, a bare domain, or a LinkedIn profile URL. Pricing is a monthly subscription sized by credits, from $29 a month for 400 credits (about 7.3¢ each) down to $799 for 100,000 (0.8¢), with 33% off on annual billing. A credit is only spent when a verified email comes back, unused credits roll over while you stay subscribed, and repeat searches within 30 days are free. The API key is self-serve from the dashboard and passed as a Bearer token; there is a 100-credit trial, though the API trial asks you to verify a card first. Best for a developer who wants domain-first finding with per-result economics. Caveat: it is still a subscription underneath, so the rollover stops if you cancel. ### Skrapp Skrapp is a LinkedIn extension and a company search that share one credit pool, with verification included on every tier including free. Starts from a LinkedIn profile, a company website, or its own lead search. Free plan with 50 credits, Professional at $39 a month or $29 a month billed annually for 2,000 credits, Enterprise at $349 a month for 50,000. The fact that matters for this audience: API access is an Enterprise-only add-on, so the $39 plan gets you a browser tool, not an endpoint. Best for a solo recruiter or SDR who lives in LinkedIn and wants work emails cheaply. Caveat: the pricing page does not say whether the free plan's 50 credits renew. ## Person-first enrichment Different question. You already know who the person is and want their contact details, and the company domain may be unknown, stale, or beside the point. ### Lusha Lusha is contact data for sales teams: a browser extension over LinkedIn, a prospecting search, and an enrichment API, with the compliance paperwork procurement tends to ask about. Starts from a name plus company or a LinkedIn URL. Pricing is a subscription with monthly credits: Free with 40 credits a month, Starter at $49.90 for 400, Professional at $69.90 for 600, Premium at $399.90 for 3,400, with about 25% off on annual billing. An email costs 1 credit and a phone number costs 10, which changes the math quickly if phones are the point. The API page has a "Generate API Key" button, so it is self-serve, but API pricing is not published and the pricing page does not say which plans include it. Best for a go-to-market team that wants phones and emails from LinkedIn with legal review already done. Caveat: 400 credits at 10 per phone is 40 phone numbers a month. ### PeopleDB Mine, so briefly, and the [1:1 comparison with Hunter](https://peopledb.co/hunter-alternative) has the full table. PeopleDB is an API for one job: pass a LinkedIn identifier or a GitHub login or ID, get back email addresses classified personal or work, phone numbers, and social handles. Pricing is prepaid credits with no subscription: 15¢ a lookup at 100 credits ($15), 12¢ at 500 ($60), 10¢ at 2,000 ($200), 7.5¢ at 10,000 ($750), 6¢ at 50,000 ($3,000). A lookup is only charged when it returns at least one email, credits never expire, and a new account gets 10 free credits and a working API key with no card. Verification is a separate endpoint, `GET` or `POST /api/v1/email_verifications`, that runs an SMTP check on any address you pass it; [how that check works](https://peopledb.co/blog/verify-email-address) is its own post. Now the part Hunter users need to hear plainly. PeopleDB does not do domain search. It cannot tell you who works at acme.com or what their address pattern is, and it has no prospecting, no extension, and no outreach. If your workflow starts with a domain, it is the wrong tool. If it starts with a column of LinkedIn or GitHub identifiers, especially GitHub, which nothing else on this page resolves, it is the right one. The [contact enrichment API guide](https://peopledb.co/contact-enrichment-api) covers request and response shapes, [pricing](https://peopledb.co/pricing) is on one page, and the [docs](https://docs.peopledb.co) have the rest. ## Verification only If you already have the addresses and only need to know which ones will bounce, you do not need a finder at all. ### ZeroBounce ZeroBounce is a verification service with a bulk checker, an API, and a few adjacent products. Starts from an email address, or a file of them. The published anchor is the ZeroBounce ONE subscription at $99 a month for a minimum of 10,000 credits, with a Freemium tier of 100 credits a month. Pay-as-you-go prices are set through a calculator rather than a table on the page; per third-party pricing guides, entry packs run around $39 for 2,000 credits. Credits never expire, unknown results are free, and one credit checks one address. API keys come from the account dashboard. Best for cleaning a list before a send or gating a signup form. Caveat: it finds nothing. Pair it with a finder. ## The short version | Tool | Starts from | Model | Entry | Self-serve API | Verifies | Best for | |---|---|---|---|---|---|---| | Hunter | Domain, or name + domain | Monthly credits | Free 50/mo; €49/mo | Yes, all plans | Yes | Domain-first finding plus outreach | | Snov.io | Domain, name + domain, LinkedIn | Monthly credits | Free 50/mo; $39/mo | Yes, paid plans | Yes | Hunter's workflow plus campaigns | | Voila Norbert | Name + domain | Monthly leads | 50 free; $49/mo | Yes, all plans | Yes, $0.003/email | Plain finder, API on cheapest tier | | Anymail Finder | Domain, name + domain, LinkedIn URL | Monthly credits, charged on hits | 100 free; $29/mo | Yes | Yes | Per-result domain-first finding | | Skrapp | LinkedIn, company site | Monthly credits | Free 50; $39/mo | Enterprise only | Yes | Recruiters in LinkedIn, no API needed | | Lusha | Name + company, LinkedIn URL | Monthly credits | Free 40/mo; $49.90/mo | Yes, price unpublished | Not separately | Sales teams needing phones and compliance | | PeopleDB | LinkedIn or GitHub identifier | Prepaid per lookup | 10 free; $15 | Yes, all accounts | Yes, separate endpoint | Identifier columns over HTTP | | ZeroBounce | Email address | Credits, never expire | 100 free/mo; $99/mo | Yes | Only | List cleaning before a send | Hunter's peers mostly compete on price and packaging, and the differences are real but small. Snov.io is cheaper and bundles outreach, Norbert puts the API on the cheapest tier, Anymail Finder only charges for hits, Skrapp is the budget LinkedIn extension. None of them changes the shape of the question. If the shape is wrong, no discount fixes it. Everything above was true on September 6, 2026, and some of it will not be by the time you read this, so confirm on the vendor's own page.