Hunter.io API: Find Emails by Domain or Name for Many Companies

List the email addresses at a company domain, and find one person's address, in one prompt. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to run a Hunter domain search on stripe.com for 10 addresses, then find the address of Patrick Collison at stripe.com, and give me a table with the address, name, job title, confidence, and whether the address was found or generated.

One prompt lists and finds the addresses. 1 min setup · 12-24 hrs saved.

You have a company domain, or a few hundred, and you want the email addresses that go with them, plus the address of one named person when you have a name. Hunter does both, through two endpoints that behave differently. This guide shows the quick route, one call per domain from your agent, what comes back (we ran both endpoints live on 2026-10-16), and the fields that tell a found address from a generated one. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to use the Hunter.io API?

Monid. Install it once, add a key, and your agent calls Hunter's domain search and email finder with a domain or a name, with no Hunter account to set up and no plan to choose.

• Pay per call. A domain search costs $0.0245 per block of 10 addresses returned, and an email finder lookup costs $0.0245 when it finds an address (Verified 2026-10-16 on the people enrichment tools page). Buy calls as you need them: no monthly plan and no minimum top-up. A search with zero results and a finder lookup with no address both bill nothing. Discovery and inspection are free; only a run bills.
• One install, every API. The same key and the same balance call Hunter and every other tool on Monid. To verify an address, or to add a second provider when Hunter finds nothing, you add one more call on the same balance, as in a fall-through across providers.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tool is there whenever your agent needs it, on demand, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

The two calls we ran for this guide cost $0.049 in total (Verified 2026-10-16 from the billed amounts).

How do you find email addresses for a list of domains?

Run one domain search per domain and loop it over your list. The endpoint is /domain-search from the provider hunterio. It takes a domain (or a company name of at least three characters) in the request body, and a limit of up to 100 addresses.

Monid fits a list because the job is the same call repeated, and you pay for the domains you search and nothing between runs.

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

Inspect, then run one

monid inspect -p hunterio -e /domain-search
monid run -p hunterio -e /domain-search -i '{"domain": "stripe.com", "limit": 10}'

Note -i, the body flag. The domain search endpoint reads its input from the body, not from query parameters, and monid inspect shows which one an endpoint wants before you spend anything.

Loop it over your list

Put one domain per line in domains.txt, and write one file per domain:

mkdir -p out
while read -r d; do
  monid run -p hunterio -e /domain-search -i "{\"domain\": \"$d\", \"limit\": 10}" > "out/$d.json"
done < domains.txt

Each domain bills one block of 10 addresses. A hundred domains at 10 addresses each is $2.45 (Verified 2026-10-16). For one named person, the finder takes a name instead:

monid run -p hunterio -e /email-finder \
  --query '{"domain": "stripe.com", "first_name": "Patrick", "last_name": "Collison"}'

Or hand the whole job to an agent

Can you scrape Hunter.io yourself?

You can read the Hunter website by hand for a few domains, and you cannot reproduce what it sells by writing a scraper. The data in a domain search is not on one site to scrape. It is collected from pages across the web, and each address carries the list of pages it came from.

Our domain search for stripe.com showed it. Each address row came with up to dozens of source entries, each one a page URL with an extracted_on date, a last_seen_on date and a still_on_page flag. The sources on the first rows were documentation pages, a state attorney general's letter and blog posts, from many different domains. A collector of your own needs a crawler, an address extractor, a name matcher and a freshness check before it touches deliverability.

If you only need an address for a person whose domain you know, the cheap DIY route is a guessing script: take a name, apply a pattern such as first.last@domain, and check it. That is what the finder's generated answers are, and it is where the trouble starts, covered below. Browser extensions cover a handful of lookups for a person at a keyboard, not a list or an agent.

The Monid route is the choice for anything you will run more than once. The collection is maintained for you, the output is typed JSON with a source_type and sources on each row instead of HTML you parse, and a block of ten addresses is $0.0245 (Verified 2026-10-16). A lookup by name from Apollo is the same job on another provider, covered in the Apollo email finder API.

What does Hunter.io domain search return, and what can you build with it?

A domain search returns a block describing the domain and a list of address rows, each with a person, a job and the evidence for the address. We ran it on 2026-10-16 for stripe.com with limit 10 and read what came back.

The domain block and the total

{
  "domain": "stripe.com",
  "disposable": false,
  "webmail": false,
  "accept_all": true,
  "pattern": "{first}{last}",
  "organization": "Stripe",
  "linked_domains": [],
  "emails": [ "..." ]
}

webmail: false says this is a company domain and not a free-mail provider. pattern is the provider's inference of how the company forms addresses, and accept_all: true is the flag to read before you trust any verification result on the domain. Outside the block, meta.results was 3,964, the total for that domain, with results_approximate: false. You asked for 10, and you can page with offset.

The address rows

{
  "value": "john.collison@stripe.com",
  "type": "personal",
  "source_type": "generated",
  "confidence": 84,
  "sources": [ { "domain": "stripe.ae", "uri": "https://...", "extracted_on": "2026-10-16",
                 "last_seen_on": "2026-10-16", "still_on_page": true } ],
  "first_name": "John", "last_name": "Collison",
  "position": "Co-Founder", "position_raw": "Co-Founder",
  "seniority": "executive", "department": "executive", "decision_maker": true,
  "linkedin": null, "twitter": null, "phone_number": null,
  "verification": { "date": "2026-10-16", "status": "valid" }
}

Each row has the address, a type, a source_type, a confidence, the sources, the person's name and job (the raw title and a cleaned one), a seniority, a department, a decision_maker flag, three contact fields and a verification. All ten rows were personal and valid, with confidence between 83 and 85. The linkedin field was filled on five of the ten, and twitter and phone_number were empty on all ten.

What you can build with it

• A target contact list. Search a list of account domains, then keep rows where decision_maker is true and department matches the function you sell to. The filters can also run server-side: the endpoint accepts seniority, department, decision_maker, type and verification_status in the body, so you pay for fewer blocks.
• An account map. The department and seniority fields let you count who is findable per team at a target company. Extracting leadership contact information shows the same job from public pages.
• A first-touch enrichment. Join the address, name and job title onto your account list, then mail the rows that pass the checks in the next section.

What goes wrong when you pull Hunter.io addresses at scale?

Four things show up once you read ten rows closely. All four are from the 2026-10-16 runs.

Why does domain search return generated addresses?

Because a row's source_type can be generated, and the confidence does not drop to show it. Of the ten rows, six were found and four were generated, with confidence 84, 84, 83 and 83. A generated row is a constructed address, such as john.collison@stripe.com, which sat next to a second generated address for the same person, johncollison@stripe.com. Both had a valid verification and sources attached, and the sources were pages on a different domain, stripe.ae. A row with sources is not necessarily a row that was found. Read source_type first. Our rule is to send only to found rows and to treat generated rows as a guess.

Why does the finder return an address with no sources?

Because the finder constructs the address from a name and the domain's pattern. For Patrick Collison at stripe.com it returned collison@stripe.com, score 80, source_type: "generated" and sources: []. The verification block said valid with a date of 2026-10-17. Those fields together tell you what you got: an address with a high score, no page behind it, and a clean verification. position, linkedin_url, twitter and phone_number were all null, so the person was not profiled either. The finder did what it is for. The mistake is storing the result as a find.

Why does "valid" not settle it?

Because the domain has accept_all: true, and the finder's answer above, an address no page backs, still came back valid. On an accept-all domain, treat verification as a first pass and rely on source_type instead. For a send list, run a separate verification step on anything you plan to mail, because a bounced address counts against the sender and a rising bounce rate costs sender reputation. Read bounce rates and spam traps before you decide how many bounces your sender reputation can take. The verifier endpoint, hunterio/email-verifier, costs $0.01225 per verdict (Verified 2026-10-16).

def sendable(row, domain):
    if row["source_type"] != "found":
        return False
    if domain["accept_all"]:
        return row["confidence"] >= 80   # then verify before sending
    return row["verification"]["status"] == "valid"

What does a list cost, and how long does it take?

Billing is per started block of 10 returned addresses, so limit sets the cost: a page of 10 is one unit at $0.0245 (Verified 2026-10-16), and a page of 100 is ten units, $0.245. The domain search call took about 1.6 seconds and the finder about 6.4 seconds, and the finder accepts a max_duration of 3 to 20 seconds. Paging a domain with offset bills each page separately.

Which endpoint should I use for which job?

Prices Verified 2026-10-16 with monid inspect, and current figures are on monid.ai/tools. Use domain search when you start from a company, the finder when you start from a name and the domain search did not list the person, and the verifier on anything you will mail. The combined lookup runs the other way, from an address to a person and their company, as in reverse email lookup. We inspected it and did not run it.

The people enrichment tools page lists the endpoints that sit on the same key and balance.

When is another route a better fit?

You want the Hunter website. A person who is not writing code and wants a UI with a browser extension, saved lists and campaigns is better served by Hunter's own product than by an API behind an agent.

Your targets are accept-all domains. If most of your list is large companies with permissive mail servers, verification neutralises itself and you rely on source_type and a second check. Budget for the verifier on every row you plan to mail.

You need the whole company, not the findable part. Domain search lists addresses the provider has seen, so it favours people with a public footprint. For every person in a function, a people-search endpoint filtered by title and company is the right shape.

And the disclosure: this is Monid's blog and we resell these endpoints. The most useful thing in this post costs nothing: read source_type before you read any score.

Conclusion

The quickest way to use the Hunter.io API from an agent is through Monid: $0.0245 per block of ten addresses and $0.0245 per address the finder produces (Verified 2026-10-16), one key for this and every other tool, about a minute to set up and ready inside your agent whenever you need it. Building a collector yourself costs hours and still leaves you without the sources.

Two things matter more than which endpoint you pick. A confidence number and a valid status do not tell you whether an address was found or constructed: source_type does, and four of our ten domain search rows were generated. And on an accept-all domain, "valid" is not proof of a mailbox, so verify before you send.

How we estimated the time saved: wiring a domain loop, the finder fallback, the found-or-generated filter and a verification step takes about 4 to 8 hours of building and testing, and a pattern guesser with a crawler of your own takes another 4 to 8, plus 4 to 8 hours in the first month for upkeep. That is 12 to 24 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p hunterio -e /domain-search, then search one domain whose staff you know and count how many of the ten rows are generated. Start at monid.ai.

FAQ

Published September 2026.