Reverse Email Lookup API: What One Address Actually Returned
A reverse email lookup on a Stripe address returned an IT administrator, not the CEO. That is the endpoint working, and the fuzzy flag says why.
Copy this line to your agent to look up who is behind an email address.
set up https://monid.ai/SKILL.md and use hunterio /combined/find with an email address
On 2026-09-14 we ran a reverse email lookup on patrick@stripe.com. It returned Patrick Bosmans, IT Administrator, Madison, Wisconsin, with a LinkedIn handle and a phone number. Most people who type that address are thinking of the CEO. The endpoint was not wrong, and the one field that explains why is the one most pipelines drop. This guide runs through Monid, the OpenRouter for agent tools.
What does a reverse email lookup actually return?
A person record keyed on the mailbox, plus a company record if you ask for it, and about a third of the person fields will be empty on any given address.
The record
hunterio/people/find for patrick@stripe.com:
{
"name": { "fullName": "Patrick Bosmans", "givenName": "Patrick", "familyName": "Bosmans" },
"email": "patrick@stripe.com",
"location": "Madison, Wisconsin, United States",
"employment": { "domain": "stripe.com", "name": "Stripe", "title": "IT Administrator", "role": "it", "seniority": null },
"linkedin": { "handle": "patrick-bosmans-549746b4" },
"phone": "+1 307 512 2554",
"fuzzy": false,
"emailProvider": "google.com",
"indexedAt": "2026-09-13",
"activeAt": "2026-09-14",
"bio": null, "site": null, "avatar": null,
"github": { "handle": null }, "twitter": { "handle": null }
}
What was populated and what was not
Name, title, company, location, LinkedIn and phone came back. Bio, personal site, avatar, GitHub and Twitter came back null. That is not a thin record; it is a record of a person who has a LinkedIn profile and no public GitHub, which is most people in most job functions.
A "full profile" is whatever the provider has observed, not a fixed shape. Design the downstream table for nulls in the social columns, because they will be null more often than not.
The two dates
indexedAt is when the provider last processed this record. activeAt is the most recent signal that the mailbox is live. On our call they were a day apart and both within 24 hours, which is unusually fresh. Store both. A record with indexedAt from eighteen months ago is a record about a job someone may no longer hold, and the date is the only thing that tells you.
The combined shape
hunterio/combined/find on the same address returned the identical person object, byte for byte, plus a company block: legal name, domain aliases, industry, employee band, founding year, social handles, identifiers and a technology list. Same billing shape, same price magnitude, strictly more data. We could not find a reason to call the narrower endpoint.
📖 See also An Email In, a Full Person Profile Out
How do I enrich a list when all I have is email addresses?
Split the list by domain type first, then run the lookup only on the corporate half, and verify before you enrich.
Why the split comes first
A corporate address already tells you the company: @stripe.com is Stripe before you spend anything. A free-provider address (gmail.com, outlook.com, yahoo.com) tells you nothing about an employer, and reverse lookup on it is resolving a person from a personal mailbox, which is a different and much weaker operation.
Our record carried emailProvider: "google.com", which looks like a free-mail flag and is not: Stripe runs its mail on Google Workspace. Do not use emailProvider to detect personal addresses. Split on the domain you can see in the address itself.
The order that saves money
- Verify the address is deliverable. That is cheap and it removes dead rows before anything expensive runs.
- Reverse lookup the corporate survivors with
/combined/find, so you get the company for free. - Route the free-mail survivors to a name-based search if you have a name, or accept that an email alone is not enough.
Enriching an unverified list means paying to learn about mailboxes that bounce. That ordering is argued in full in enriching a list from email addresses.
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. Look up one address
What it does. Returns the person and their company from a single mailbox.
The endpoints. hunterio/combined/find, billed per call, requires email.
The call.
monid run -p hunterio -e /combined/find --query '{"email": "patrick@stripe.com"}'
What comes back. data.person with the fields above and data.company with firmographics.
What it costs. A fraction of a cent per call, and the charge does not change with how much comes back. Current figures at monid.ai/tools.
Step 2. Read fuzzy before anything else
What it does. Tells you whether the match is direct or inferred. The next section is about this field.
Step 3. Fall back to search for the ones that miss
What it does. Finds a person the lookup could not, from name plus company.
The endpoints. pdl/v5/person/enrich, per call, accepts email, LinkedIn URL, or name plus company.
What comes back. A second provider's view of the same person, which matters because the two disagree more often than you would expect. The measured comparison is in the provider comparison.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to take this list of email addresses, split out the free-mail ones, run a reverse lookup on the rest, and give me name, title, company and the fuzzy flag for each.Is there an email lookup API that reduces bounce rates?
Not directly, and the confusion between two different jobs is why people ask.
Two jobs that share a word
Reverse lookup answers "who is behind this address". It returns a person.
Verification answers "will mail to this address deliver". It returns a status.
An address can pass verification and have no person record, and an address can return a rich person record and still bounce because the person left last month. They are independent facts and no single endpoint gives you both with equal confidence.
What reverse lookup does tell you about deliverability
Indirectly, two things. activeAt is a recent-activity signal, and a very stale value is a soft warning. And an employment record that names a different company from the domain in the address is a near-certain bounce: the person moved and the old mailbox is dead or forwarding.
Neither replaces a verification call. Bounce rate is a verification problem, and the measured answer to that question is in bounce rates and spam traps.
The order again
Verify first, look up second. Verification is the cheaper call by a wide margin and it is the one that protects your sending domain. Reverse lookup is what you run on the addresses that survived.
📖 See also Best Email Verification API in 2026
Which field tells you the match is real?
fuzzy, and on our record it was false.
What it means
fuzzy: false says the provider matched this exact mailbox to this exact person from direct observation. fuzzy: true says the record was inferred, typically from a name pattern on the domain: patrick@ on a company where someone named Patrick works, so the provider filled in the most likely Patrick.
The difference is the difference between a fact and a guess, and the record shape is identical in both cases. Nothing else in the response changes. If you drop this field on the way into your database, you have made every inferred row look like an observed one.
Why the Stripe result is the right result
patrick@stripe.com is Patrick Bosmans. It is not Patrick Collison, and there is no reason it should be: a company mailbox belongs to whoever was given it, and a famous name at the same company does not change that. An endpoint that returned the CEO here would be pattern-matching on fame, which is exactly the fuzzy behaviour you do not want presented as a direct match.
A row that surprises you is not a wrong row. It is a row to check fuzzy on, and if it says false, the surprise is the fact.
The rule to encode
person = resp["data"]["person"]
confidence = "observed" if person["fuzzy"] is False else "inferred"
row.update(name=person["name"]["fullName"], title=person["employment"]["title"],
confidence=confidence, indexed_at=person["indexedAt"])
Two extra columns, and they are the only thing that will let a later run tell a careful match from a lucky one. The same bookkeeping argument runs through the company website resolution guide, where the candidate count plays the role fuzzy plays here.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
hunterio/combined/find | Person plus company from an email | email | Person record and firmographics | The default reverse lookup | Per call |
hunterio/people/find | Person only from an email | email | Person record | Never; the combined route costs the same | Per call |
pdl/v5/person/enrich | Second provider's view | Email, LinkedIn URL, or name plus company | Person record with likelihood | Cross-checking a row you will act on | Per call |
hunterio/email-finder | The reverse direction: name to email | domain, first_name, last_name | A candidate address with a score | When you have the person and not the address | Per result |
Every row was verified with monid inspect on 2026-09-14. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The second row is in the table so you can see why not to use it. Identical person object, no company block, same price. The only reason to prefer it is a response-size constraint, and that is rare.
When is reverse lookup the wrong tool?
Four cases.
The address is personal. A gmail or outlook mailbox is a person's private identifier, and resolving it to a name and phone number is a different kind of act from looking up a corporate contact. Coverage is thin, the ethics are different, and in many jurisdictions the legal basis is different too. Treat free-mail addresses as out of scope for B2B enrichment and route them elsewhere.
You already have the person. If the spreadsheet has name and company, reverse lookup is the wrong direction. Go straight to enrichment on the identifier you hold; the lookup step exists for the case where the mailbox is all you have.
You need it to be current to the day. indexedAt on our record was yesterday, which is good and not a guarantee. A person who left last week will still resolve to their old employer until the provider re-observes them. For anything consequential, verify the employment against a second source. The decay problem is measured in the provider comparison.
You are trying to reduce bounces. As above: that is verification, not lookup, and running lookup instead will not lower a bounce rate by a single point.
And the disclosure: this is Monid's blog and we sell per-call access to these endpoints. The central recommendation here is to call one endpoint rather than two, and to spend on verification before enrichment, which is not much of a pitch for volume.
Conclusion
A reverse email lookup returns the person who owns the mailbox, and on a company domain that is a specific employee rather than the famous name you associate with the company. patrick@stripe.com is an IT administrator in Madison. That is the endpoint working, and a pipeline that expected the CEO has misunderstood what a mailbox is.
The field that matters more than any other is fuzzy. It is the only thing in the response that separates an observed match from an inferred one, the record looks identical either way, and it is the first column dropped when a response is flattened. Keep it, alongside indexedAt, and every row you store carries its own confidence and its own age.
Free next step: run monid inspect -p hunterio -e /combined/find to read the schema without spending, then look up one address you already know the answer to and read fuzzy and employment.title before anything else. Start at monid.ai.
FAQ
Is there a free reverse email lookup?
Partially, and the free tier of every tool in this category is limited by design: a handful of lookups a month, or a result with the name shown and the contact details hidden behind a paywall. On Monid the lookup is metered per call at a fraction of a cent, with no monthly plan, so a hundred addresses costs less than a coffee and there is no tier to exhaust. What is genuinely free is the inspect step, which shows you the exact schema and current price before anything bills.
Does reverse email lookup work on Gmail addresses?
Rarely, and you should not rely on it. Corporate lookup works because the domain names the company and the provider has observed employees at that company. A free-mail address carries no company signal, coverage drops to whatever the person has linked publicly, and the privacy considerations are different: you are resolving a private individual rather than a business contact. Split these out before running the batch.
Is reverse email lookup legal under GDPR?
It can be, and it depends on your lawful basis and your purpose, which is a question for your legal counsel rather than a blog post. The general shape: looking up a business contact's professional details for a legitimate business purpose is commonly relied on under legitimate interest, with obligations around transparency and the right to object. Looking up a private individual's personal mailbox is a different matter. Keep records of what you looked up and why, and do not assume that because an API returned data you were entitled to use it.
How current is the record?
As current as the two dates in it. Our call returned indexedAt of 2026-09-13 and activeAt of 2026-09-14, which is unusually fresh. Records on less-observed people can be months old, and a job change is invisible until the provider re-observes the person. Store both dates, let them age visibly in your table, and re-check any record older than a quarter before acting on the title.
Last updated September 2026.
