Apollo Email Finder API: Two Providers, One Mailbox, Two Owners
Apollo says patrick@stripe.com is the CEO, verified. Hunter.io says it is an IT administrator, observed. Same address, one day apart, both confident.
Copy this line to your agent to find a person's work email from their name and company.
set up https://monid.ai/SKILL.md and use apollo /people/match with a name and domain
On 2026-09-15 we asked Apollo's email finder for Patrick Collison at stripe.com. It returned patrick@stripe.com, status verified, title Co-Founder and CEO. The day before, a reverse lookup on that exact address through Hunter.io returned Patrick Bosmans, IT Administrator, with a flag saying the match was direct rather than guessed. Two providers we resell, one mailbox, two owners, both confident. This guide runs through Monid, the OpenRouter for agent tools.
What does the Apollo email finder actually return?
A person record with an email and a status on it, a company record, and a set of flags that matter more than the email does.
The record
apollo/people/match for first name Patrick, last name Collison, domain stripe.com:
{
"name": "Patrick Collison",
"title": "Co-Founder & Chief Executive Officer",
"seniority": "founder",
"email": "patrick@stripe.com",
"email_status": "verified",
"match_confidence": "high",
"email_domain_catchall": true,
"email_domain_catchall_verdict": "allow",
"departments": ["c_suite"],
"linkedin_url": "http://www.linkedin.com/in/patrickcollison",
"city": "San Francisco", "state": "California",
"organization": { "name": "Stripe", "primary_domain": "stripe.com", "estimated_num_employees": 8000, "founded_year": 2010 }
}
The second record, same company
Sudheer Anne at stripe.com, same call shape:
{
"name": "Sudheer Anne",
"title": "Head of Engineering - Capital Core",
"seniority": "head",
"email": null,
"email_status": "unavailable",
"match_confidence": "high",
"email_domain_catchall": false,
"employment_history": [ "13 entries" ]
}
Apollo found the person with high confidence, attached him to Stripe, returned thirteen prior roles, and had no email. It billed the base rate anyway, which the endpoint notes say it will: a match that attaches a name to a known company is charged whether or not an email comes with it.
The three fields that matter
email_status, match_confidence and email_domain_catchall. The first says whether Apollo has confirmed the address deliverable. The second says whether it believes this is the right person. The third says whether the domain accepts everything, which decides whether the first means anything. Read them in that order, and read the third one twice, because it is about to contradict itself.
📖 See also Hunter.io API: Domain Search Finds, Email Finder Guesses
Why do Apollo and Hunter.io disagree on who owns the address?
Because they built their records from different sources, and neither one is checking the other's claim.
The two disagreements, side by side
| Apollo, 2026-09-15 | Hunter.io, 2026-09-14 | |
|---|---|---|
patrick@stripe.com belongs to | Patrick Collison, CEO, email_status: verified | Patrick Bosmans, IT Administrator, fuzzy: false |
| Sudheer Anne's email | null, email_status: unavailable | sudheer@stripe.com, confidence 85, verified valid, one source |
| Guessing Collison's address | Not needed; returned patrick@ as verified | Email finder generated pcollison@, score 16, no source |
Two providers, two people, and they disagree in opposite directions. Apollo has an email for the person Hunter can only guess at, and Hunter has an email for the person Apollo has nothing on.
What "verified" and "observed" each mean
Apollo's verified means its own verification pass believes the mailbox is deliverable. Hunter's fuzzy: false means it observed this exact address attached to this exact person somewhere public. Those are different claims. A mailbox can be deliverable and belong to someone other than the person a provider has filed it under, and that is the most likely reading here: patrick@stripe.com is a real, working address, and the two databases have attached two different Patricks to it.
We do not know which is right. That is the point. A pipeline that consumed either provider alone would have stored a confident, verified, wrong-or-right answer with no signal that the other provider disagreed.
The catchall flag disagreed with itself
Apollo returned email_domain_catchall: true on the Collison record and false on the Anne record. Same domain, stripe.com, one day, two calls. A catchall setting is a property of a mail server, not of a person, so one of those two values is stale. Hunter's domain block the day before said accept_all: true, which sides with the first.
Read this as: the flag is stored on the person record at the time the record was built, and it is not recomputed per call. Trust it when it says true, because that is the conservative reading, and do not trust a false as permission to skip verification.
The rule this produces
Two providers, one mailbox, two owners is not a data quality bug you can file. It is what B2B contact data is. The defence is the one that keeps coming up across this whole series: keep the provider, the status field and the date on every row, and when the address matters, get a second reading before you send. The reverse direction of this exact lookup is measured in the reverse email lookup guide.
How do you use the Apollo email finder through one key?
Three steps, and the middle one is where the money is.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Read the tiers before the first call
What it does. Shows you the three prices this one endpoint can charge.
The call.
monid inspect -p apollo -e /people/match
What comes back. A tiered price: a base per call, an additional charge when reveal_personal_emails is true, and a much larger additional charge when reveal_phone_number is true and a mobile number is actually returned. The notes add that a no-match costs nothing, and a match with no email still costs the base. Read all four sentences before you loop.
Step 2. Match one person
What it does. Returns the person, their company and an email with a status.
The endpoints. apollo/people/match, tiered per call, takes any mix of first_name, last_name, name, email, domain, organization_name, linkedin_url.
The call.
monid run -p apollo -e /people/match \
--query '{"first_name": "Patrick", "last_name": "Collison", "domain": "stripe.com"}'
Leave reveal_personal_emails and reveal_phone_number off unless you need them. Each one is a separate charge, and the phone tier is the expensive one.
What comes back. The record above. On 2026-09-15 the Collison match returned a verified email and the Anne match returned none, and both billed the base.
What it costs. A few cents per matched call at the base tier, more with the reveal flags. Current figures at monid.ai/tools.
Step 3. Cross-check the address that matters
What it does. Catches the disagreement before it reaches a send.
The endpoints. hunterio/combined/find, per call, takes the email Apollo returned.
The call.
monid run -p hunterio -e /combined/find --query '{"email": "patrick@stripe.com"}'
What comes back. Whoever Hunter has filed under that address. On this address it was a different person. When the two agree, send. When they do not, you have learned something a single provider could never have told you, at the cost of one more cheap call.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to find the work email for each person on my list using apollo, then run the address through a hunterio reverse lookup and flag any row where the two providers name a different person.Is there an email lookup API that reduces bounce rates?
Not by itself, and the Apollo response shows exactly why: it carries a status field and a catchall flag, and on a catchall domain the status cannot mean what you want it to.
What email_status: verified can and cannot promise
On a normal domain, verified means Apollo's check found a mailbox that accepts mail for that address specifically. On a catchall domain, every address accepts mail, so the check passes for real addresses and invented ones alike. Stripe is catchall, by Apollo's own flag on one record and by Hunter's the day before. So verified on patrick@stripe.com tells you the server accepted the probe, not that the person Apollo named reads that inbox.
What actually lowers a bounce rate
Verification, run as a separate step, on the address you are about to send to, and on a domain where verification means something. On catchall domains, provenance replaces verification: an address observed in the wild with a source beats a generated or inferred one regardless of what any status field says. That is the whole argument of bounce rates and spam traps, and the measured comparison of verification providers is in the email verification comparison.
Where the finder fits
Before verification, not instead of it. Apollo's finder gives you a candidate address and a company, verification tells you whether to send to it, and on a catchall domain a second provider's observation is the closest thing to verification you can get.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
apollo/people/match | Name plus company to person and email | Any identifier mix | Person, org, email_status, flags | The finder step | Tiered per call |
hunterio/combined/find | Email to person and company | email | Person with fuzzy, company | Cross-checking who owns the address | Per call |
hunterio/domain-search | All observed addresses at a domain | domain | Address rows with sources | Finding people you have not named | Per result |
pdl/v5/person/enrich | Third provider's view | Email, LinkedIn URL, name plus company | Person with likelihood | A tie-breaker when the first two disagree | Per call |
apollo/mixed_people/api_search | People by title and company filters | Filters | Person list | Building the list before matching | Per call |
Every row was verified with monid inspect on 2026-09-15. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The first two rows are the pair this article is about, and the reason to run both is measured above. The third row is the alternative when you do not have a name: Hunter's domain search found Sudheer Anne's address when Apollo's match, given the name, did not.
When is Apollo's email finder the wrong tool?
Four cases.
You already have the email and want the person. That is the reverse direction, and combined/find or people/match with the email parameter does it more directly than a name-and-domain match.
The domain is catchall and the send matters. verified cannot mean deliverable on a catchall domain. Get a second provider's observation, and if neither has seen the address in the wild, treat it as a guess whatever the status says.
You want the mobile number by default. The phone tier is the expensive one, it is charged only when a number actually returns, and most B2B outreach does not need it. Leave reveal_phone_number off unless the workflow specifically calls someone.
You want Apollo's platform. Sequences, a dialer, a Chrome extension, team seats. The API is one endpoint of that product and it does not replace the UI a sales team lives in. If the question is about Apollo's pricing plans rather than per-call access, that is a plan-versus-metered decision, and the split is laid out in the provider comparison.
And the disclosure: this is Monid's blog and we resell Apollo and Hunter.io both. The finding of this article is that they disagree about who owns a mailbox, which is not a thing either would put on its own landing page, and the recommendation is to buy one cheap cross-check rather than more matches.
Conclusion
Apollo's email finder is one call that returns a person, a company and an address with a status, and on a well-known founder it returned all three in four seconds. The address it returned is one that another provider, the day before, attached to a different employee with a flag saying the match was direct. Both are confident. One of them is wrong, and neither response contains any hint that the other exists.
What matters more than which provider you pick is that contact data is a set of independent claims, not a lookup table, and the fields that let you weigh those claims are email_status, match_confidence, the catchall flag and the provider name. Store all four, and when two providers name different people for one mailbox, that disagreement is the most valuable row in your table, not an error to resolve by picking one.
Free next step: run monid inspect -p apollo -e /people/match and read the three tiers, then match one person whose email you already know and check whether email_domain_catchall says what you expect. Start at monid.ai.
FAQ
What are the best alternatives to Apollo.io with better data quality?
"Better" is a property of a provider against your segment, not a property a provider has, and the measurement in this article is the shape of the answer: Apollo had a verified email where Hunter.io had a guess, and Hunter.io had an observed email where Apollo had nothing, on two people at one company. The alternative that is better for you is the one that covers the people you actually contact, which you find out by running fifty of them through two providers and counting. The wider comparison across People Data Labs, Apollo and ZoomInfo is in the provider comparison.
What are the personal email and phone tiers?
Two optional flags on the same call. reveal_personal_emails asks Apollo to include non-work addresses and adds a charge when set. reveal_phone_number asks for a mobile number and adds a much larger charge, but only when a number is actually returned; setting the flag on a person with no number costs nothing extra. Both default to off. For most B2B outreach the base tier is the whole job, and the phone tier is worth enabling only for a workflow that dials.
Why was I billed for a match that returned no email?
Because the endpoint bills the base rate when it attaches the name you gave to a known company, and it did: Sudheer Anne matched with high confidence to Stripe, with a title, a seniority and thirteen prior roles, and no email. The notes on the endpoint say this plainly. A true no-match, where Apollo cannot place the person at all, is free. The distinction matters for budgeting a list where many people will match but few will have addresses.
Is the Apollo API the same as the Apollo UI?
Same data, different product. The UI bundles the database with sequences, a dialer, a Chrome extension and seats, priced as a plan. The API exposes the match and search calls over the same records, priced per call through Monid with no plan. If a sales team opens Apollo every morning, the UI is the purchase. If a pipeline calls it a thousand times a night, the API is. Most of the confusion about Apollo's cost is those two purchases being compared as if they were one.
Last updated September 2026.
