Enriching a List When All You Have Is Email Addresses

You have a spreadsheet of email addresses and nothing else. Maybe they came from a form, maybe from an event, maybe from a list somebody handed you. What you need is a name, a company and a title, and the question is whether an address alone is enough to get there.

The short answer is sometimes, and the useful answer is how often. Monid is the OpenRouter for agent tools, so rather than describing the endpoint we can run it and report what came back.

Fair disclosure: you are on the Monid blog. Three of our four test addresses returned nothing, and that number is the most useful thing in this guide.

Can you get a person from an email address alone?

Sometimes, and the rate matters more than the capability.

We ran four real email addresses through pdl /v5/person/enrich on 2026-08-19:

monid run -p pdl -e /v5/person/enrich -i '{"email":"<address>"}' -w

sundar@google.com      200, a full person record
patrick@stripe.com     404
info@apify.com         404
support@tikhub.io      404

One of four. Not a benchmark, not a coverage claim, and not a number to plan a quarter around, but it is a real result on real addresses and it is the right order of magnitude to expect from a cold list.

The second finding matters as much as the first. We checked the balance before and after the four calls, and it fell by exactly one call's worth. The three misses billed nothing.

That changes the arithmetic completely. On a per-attempt model, a list with a low hit rate is expensive to discover and the discovery is wasted. Here, you pay for the people you find, which means running the whole list is the cheapest way to learn how much of it is usable. There is no reason to sample first.

What did the addresses that failed have in common?

Two of the three were role addresses, and the third is the interesting one.

info@apify.com and support@tikhub.io are not people. A shared inbox has no person behind it, so a person lookup correctly returns nothing. These should never have been in the batch, and filtering them out beforehand is free: role prefixes are a fixed, short list, and anything matching one can be dropped before it reaches an endpoint.

patrick@stripe.com is the one worth thinking about. It is a personal-format address at a large, well-documented company, and it still returned 404. A dataset built from public professional profiles has no reliable way to connect a specific mailbox to a specific person unless that pairing was published somewhere. Guessable format plus real person does not equal resolvable.

The rule underneath both: an email resolves when the pairing has been observed, not when it is plausible. No provider derives the person from the address; they look it up in what they have collected. That is why role addresses fail by definition and personal addresses fail by luck.

Three practical filters before any batch:

Drop role prefixes. info, support, sales, hello, admin, contact, billing, careers, press. Free to apply and it removes rows nothing will ever resolve.

Separate free-mail from corporate. A gmail address carries no company signal and resolves at a different rate from a corporate one. They are two populations and averaging them hides which half is working.

Check the domain is live first. An address at a dead domain cannot resolve to a current job, and domain checks cost far less than person lookups. Verifying an email before it hits your list covers the mechanics.

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-key> -l main

What does a hit actually return?

Considerably more than a name, and the company half is the part people underestimate.

The single successful record carried well over a hundred fields. Grouped by what they are for:

person       full_name, first_name, last_name, birth_year, gender, id
location     country, continent, countries, geo, address, region, locality
work         job_title, job_title_role, job_title_levels, job_company_name,
             job_start_date, experience (the full history)
company      job_company_id, job_company_industry, job_company_founded,
             job_company_size, job_company_linkedin_url,
             job_company_location_country, job_company_location_metro
social       linkedin_url, github_url, github_username, facebook_url,
             twitter_url, profiles
contact      emails, is_primary, phone_numbers, mobile_phone
education    education, degrees, gpa, end_date
signals      interests, skills, industry, activity_score

Three of those change what you can build:

job_title_levels is normalised seniority as an array, so routing branches on cxo or director in code without parsing free text. This is the field that makes automated lead routing possible rather than approximate.

The job_company_* block means one person lookup also returns the firmographics. If your next step was a separate company enrichment call, check this block first: you may already have what you were about to pay for again.

experience is the full history, not just the current role. Useful for a genuine reason: someone who joined four months ago buys differently from someone in year six, and the start date is right there.

The field that flatters: activity_score. It describes how much profile activity the provider has observed, not how engaged the person is with anything of yours. Reading it as intent is a mistake the field name invites.

📖 See also an email in, a full person profile out for the step-by-step version of this call, and the provider comparison for how the datasets differ.

How do you plan a batch around a partial hit rate?

By designing for the misses, because they are the majority and they are not failures.

Run the whole list. Misses cost nothing, so sampling to estimate coverage costs the same as doing the work. Run everything, then count.

Record why each miss missed. A 404 on a role address is expected and permanent. A 404 on a personal corporate address is a coverage gap that a second provider might fill. Storing the reason turns a list of failures into a routing decision.

Send the personal-address misses down a second path. If you have a name and a company from somewhere else, name-plus-company enrichment is a different query with different coverage, and it frequently resolves what an address alone could not. We walked that route in automating email to profile enrichment.

Never fill a gap with a guess. A record with an inferred title is worse than an empty one, because everything downstream treats it as known. Leave it null and let the segmentation logic see the null.

Re-run rather than re-buy. Coverage improves as datasets grow. The misses from this quarter are worth retrying next quarter, and because misses are free, retrying costs only what newly resolves.

What a partial list is still good for

The instinct on a 25% hit rate is that the list failed. It usually has not, and three things are worth doing with what came back before writing the rest off.

Segment on what resolved, then infer nothing about the rest. The people you found tell you what kind of list this is: seniority mix, company sizes, industries. That is a real description of the resolvable quarter and it is silent about the other three quarters, which is exactly how it should be read. Treating the found segment as representative is the mistake that turns a partial list into a wrong strategy.

Use the company block to rescue rows the person lookup lost. Every hit carried its employer's firmographics, and the domains from the misses are still domains. A company enrichment on those costs a different call and answers a different question, and for account-based work knowing the company is often enough to act.

Route the misses by why they missed, not as one bucket. Role addresses go to a different acquisition motion entirely, because no enrichment fixes a shared inbox. Personal-address misses go to the name-plus-company retry. Dead domains get dropped. Three fates, three costs, and only one of them is worth another lookup.

The framing that keeps this honest: a hit rate measures your list against a dataset, not the quality of either. A list of enterprise decision-makers and a list of newsletter signups resolve at completely different rates against the same provider, and the number tells you which one you have.

Which endpoint should I use for which job?

Verified present on 2026-08-19 with monid discover. The billing column gives the shape rather than a figure; monid inspect prints the current figure for free.

The first two rows are the same endpoint with different inputs and materially different coverage, which is the single most useful thing to know here. An address that returns 404 may resolve immediately from a name and a company, so the two are a sequence rather than alternatives.

When should you not use Monid?

Your list is mostly role addresses. Then enrichment is not the problem and no provider will help. You need a different acquisition path, because shared inboxes have no person to find.

You need guaranteed coverage. Nobody sells that on email-to-person, and a vendor quoting a coverage percentage is quoting it against their sample rather than your list. Run yours.

You need a compliance-grade identity link. This is commercial data assembled from public profiles, not identity verification. For anything with a legal consequence, that distinction matters.

You want a UI and a saved-search workflow. ZoomInfo and its peers sell a product a person opens. We ship an endpoint, a CLI and an MCP server.

And the caution about us. Our measured hit rate was one in four. That is one small sample on one day and your list will differ, but it is the right expectation to carry into planning, and it is a long way from the impression a coverage page gives. Run a hundred of your own before you build anything on the output.

Conclusion

An email address alone resolves to a person sometimes, and planning around sometimes is the whole skill. Our four test addresses produced one hit, and the three misses split cleanly into two role addresses that could never have worked and one personal address at a large company that simply was not in the dataset.

Two things matter more than which provider you pick. Misses billing nothing inverts the usual advice: there is no reason to sample, because running the full list is the cheapest way to learn its coverage, and the number you get is about your list rather than somebody's benchmark. And an address resolves when the pairing was observed, not when it is plausible, which is why a guessable corporate address at a famous company can fail while a less obvious one succeeds.

Start with the free part: filter the role addresses out at no cost, check the domains resolve, and only then run the enrichment across everything that survives. Begin at monid.ai.

FAQ

Last updated August 2026.