Apollo.io Email Finder: How It Works and What It Costs Per Address

Apollo's email finder is two mechanisms wearing one name. The first is a lookup against Apollo's own contact database, which either has the person or does not. The second is waterfall enrichment, which sends the request out to third-party data vendors you configure and charges you according to what comes back, and sometimes according to what does not.

Knowing which one answered your request changes how much you should trust the address and how much it cost you. Apollo documents both, and the documentation is more candid than most vendors manage.

How a lookup actually resolves

The people enrichment endpoint takes what you know about a person and returns what Apollo holds. Match rates depend heavily on the identifier you supply, and Apollo names the ones that work: first name and last name together, a LinkedIn URL, or an email address.

Anything weaker than that is a documented failure mode rather than an edge case. Apollo states that requests with missing or insufficient identifiers may be accepted but return no matches or fail validation. The request succeeds, the response is empty, and on a waterfall-enabled call it may still have cost you credits.

1. Step 1You supply identifiers

   Name pairs, a LinkedIn URL, or an email. Weak identifiers are accepted and return nothing.

2. Step 2Apollo checks its own data

   1 credit if demographics or an email come back, charged only when qualifying data is returned.

3. Step 3Waterfall runs if enabled

   Configured third-party vendors are queried in sequence. Typically 1 to 4 credits for email, occasionally past 20.

4. Step 4Results arrive by webhook

   Waterfall is asynchronous. The synchronous response carries demographics and a status; the addresses arrive later.

That asynchronous split catches people out. A waterfall call returns immediately with demographic data, a request ID and a status of accepted, partial_accepted or failed. The email addresses themselves are delivered to a webhook URL you supply when the vendors finish. If you have not stood up a publicly reachable HTTPS endpoint to receive them, the request runs and the results have nowhere to go.

What the credits actually buy

Apollo's published costs for the email path are specific enough to budget from.

A person enrichment returning demographics or an email costs 1 credit. It costs 9 if a mobile phone number is also returned, because the phone carries an 8-credit surcharge. If you only want email addresses, not requesting phone numbers is the single largest saving available on this endpoint.

Email waterfall enrichment typically consumes 1 to 4 credits, though Apollo notes some vendor configurations or successful higher-cost matches can push past 20. And the line worth pinning to the wall: some waterfall vendors consume credits per lookup even when no data is found.

That last rule inverts how people usually think about enrichment spend. Your cost is driven by attempts, not by successes, which means a poorly targeted list is expensive precisely because it does not work. Match rate stops being only a quality metric and becomes the main cost variable.

Accuracy is a question the documentation cannot answer

Here is where we will be straight with you rather than helpful in the wrong direction.

We have not run a controlled accuracy test of Apollo's email finder. We do not send from Apollo. Our own stack is Email Bison for sending, HeyReach for LinkedIn, and a MillionVerifier, Prospeo and Findymail waterfall for finding addresses, so any accuracy figure we published for Apollo would be borrowed from someone else's test or invented, and neither belongs in a decision you are making with money.

What is worth saying instead is that a returned address is a claim, not a verified mailbox, and that is true of every provider including the ones we use. Apollo's enrichment tells you it found something. Whether that mailbox exists and accepts mail is a separate question answered by a verifier, and skipping that step is how bounce rates climb.

Running your own accuracy check

• ✓Yes: Draw 100 contacts from your real ICP, not a convenience sample
• ✓Yes: Record the match rate: how many of the 100 returned any address at all
• ✓Yes: Verify every returned address with an independent verifier
• ✓Yes: Track catch-all domains separately, since those verify as neither valid nor invalid
• ✓Yes: Divide total credits spent by verified-deliverable addresses for a true unit cost
• ✕No: Judge a provider on match rate alone
• ✕No: Treat a vendor's published accuracy percentage as applying to your niche

Two of those lines carry most of the value. Match rate and accuracy are different numbers, and a provider optimising the first will hand you plausible-looking addresses that bounce. Cost per verified deliverable address is the only figure that compares providers honestly, because it folds in the misses you paid for.

Catch-all domains deserve their own handling. On an accept-all mail server every address verifies as neither valid nor invalid, so a list heavy in enterprise domains will produce a large ambiguous tier that no verifier can resolve. Counting those as successes inflates every accuracy claim you will read, including ones vendors make in good faith.

Give it better inputs

Match rate responds to input quality more than to anything else you can control, and the identifiers are not equally useful.

A LinkedIn URL is the strongest single identifier you can supply, because it is unique to the person and does not change when they switch employer or when a company rebrands its email domain. If your sourcing motion captures profile URLs, keep them; they are worth more at enrichment time than a name and company string.

First and last name together with a company domain works well and degrades badly. Nicknames, married names, accented characters stripped by an earlier export, and initials in place of first names all reduce the match. Normalising names before enrichment is unglamorous and it moves the number.

An existing email is useful even when the address you hold is stale, because it can resolve the person and return their current details.

What does not work is a name alone, or a name plus a company display string with no domain. Apollo accepts those and returns nothing, and on a waterfall-enabled call that empty result may still cost you.

What to do with the misses

Every enrichment run produces a tail of people it could not resolve, and the default handling of that tail is usually wrong in one of two directions.

Discarding it loses real work. These are contacts you already identified as fitting your ICP, and the sourcing effort behind them does not become worthless because one provider had no record. Bank the tail as a preserved artifact with the date and the provider that missed.

Re-running it repeatedly is the opposite error and it is expensive. A person Apollo could not resolve today is very likely a person it cannot resolve next week, and on a waterfall-enabled call each retry may bill again for the same absence. Cache the miss with a timestamp and set a re-check interval measured in months rather than days.

The middle path is to record what you tried. Store the identifier you queried with and the provider that came back empty, so that a later attempt with a better identifier, a LinkedIn URL you did not have the first time, is recognisably a different query rather than a repeat of the same one.

Verification is a separate job, and it is not optional

The gap between "an address was returned" and "an address is safe to send to" is where deliverability damage happens. A bounce is not a neutral event: mailbox providers read bounce rate as a sender-quality signal, and a bad batch degrades placement for everything else sending from that domain.

Our sequence is find, then verify, then send, with verification run fresh rather than trusted from whenever the record was first created. Addresses decay continuously as people change jobs, and an address verified four months ago is an assumption rather than a fact. The cold email bounce rate benchmarks cover what a healthy rate looks like, and the deliverability guide covers the wider infrastructure that bounce rate feeds into.

One address per company, not three

A rule that saves credits and prevents a specific kind of damage.

When a list contains several contacts at the same company, the temptation is to enrich all of them and email whoever resolves. That multiplies enrichment cost across people you were never going to contact, and it creates a worse problem at send time: several messages from the same sender landing at one domain in a short window is a pattern mail filters are built to notice.

Decide who you actually want at each company before enriching, and enrich that person. If they do not resolve, fall back to the next-best contact rather than running all of them in parallel. It is slower per company and considerably cheaper per conversation.

Using Apollo for finding without inheriting the risk

If Apollo is your data layer, the clean architecture is to let it do what it is good at and keep the consequences separate.

Enrich in bulk, cache aggressively including negative results so you do not pay twice for the same miss, verify independently before anything is queued to send, and send from infrastructure that is not tied to your data vendor's account. The domain-safe workflow sets that out step by step, and the API guide covers the caching and credit mechanics underneath it.

One cost to fold into the model: Apollo consumes export credits whenever a contact leaves the platform, including CSV exports and API enrichment synced to an outside system. An architecture that verifies elsewhere is an architecture that exports constantly, so budget for it rather than discovering it. The pricing breakdown covers how that meter works.

We run sourcing, verification and sending for clients on a pay-per-qualified-meeting basis, which puts the match rates and the bounce rates on our side of the line rather than yours. You can see what a campaign would look like for your market.

Enrichment credit costs, waterfall behaviour, identifier requirements and webhook mechanics are per Apollo's developer documentation, last updated 28 July 2026 for waterfall enrichment and 18 July 2026 for API pricing, both fetched 11 August 2026. No accuracy figures for Apollo are stated here because we have not tested it. Verify current terms with Apollo.

Sources: Waterfall enrichment, Apollo API pricing and credits, People enrichment reference