How to extract email addresses from a website

POST /web_emails starts at a URL you give it, crawls several pages of the site, and returns the email addresses it found along with how many pages it read.

Get 100 free credits — no card

url is the root to start from and it is the only required field. max_pages controls how far the crawl goes, and cache (default false) decides whether a recent result can be reused instead of crawling again.

The response is two keys:

{
  "emails": [],
  "pagesCrawled": 1
}

pagesCrawled is the honest half of that. A call that returns pagesCrawled: 1 and an empty array did not fail to find addresses across the site. It read one page. Check it before you conclude anything about a domain, especially when the addresses live on a /contact page the crawl never reached.

The addresses on a website are the addresses a company chose to publish. Expect info@, support@, sales@, press@, and a careers@ that routes to a system nobody reads. Those are routing addresses, not people, and treating them as prospects is how a domain ends up on a blocklist.

Expect misses too, for ordinary reasons: contact details rendered as an image, addresses obfuscated behind a JavaScript click-to-reveal, or a contact form instead of an address. None of that is a bug in the crawl; it is what the modern web does to avoid exactly this.

And expect the list to be stale. Nobody removes an address from a website when the person leaves. Which is why the next step is not optional.

Run every address out of this endpoint through the email verification API before it touches a sending system. The verifier tells you whether the mailbox is real, whether the domain is disposable, and whether it can receive mail at all — and because it is a multi-source waterfall endpoint, a verification the waterfall cannot resolve bills zero credits.

Extract, then verify. The extraction gives you candidates; the verification gives you addresses. Sending to the raw output of a crawl is how deliverability gets wrecked, and it is wrecked quietly, weeks before anyone notices the reply rate.

This endpoint is not a waterfall. Billing is on HTTP 2xx. A thin 2xx still bills. 4xx and 5xx bill nothing, on any endpoint. The miss-free rule on the email finder, phone finder and email verifier does not apply here.

1. Get a key. Sign up at app.richapi.ai. 100 free credits, no card.

2. POST a root URL.

curl -X POST https://api.richapi.ai/api/v1/web_emails \
  -H "x-api-key: $RICHAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

3. Point it at the right place and widen the crawl. Starting from /contact or /about beats starting from a homepage that links to a single-page app:

curl -X POST https://api.richapi.ai/api/v1/web_emails \
  -H "x-api-key: $RICHAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/contact", "max_pages": 10}'

4. Verify everything that comes out.

curl -X POST https://api.richapi.ai/api/v1/email_verifier \
  -H "x-api-key: $RICHAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "hello@example.com"}'

5. Or run the pair from an agent. The hosted MCP server exposes both tools, so the chain is one sentence:

Get the emails published on example.com, verify each one, and list only the ones that come back valid.

pagesCrawled is the honest half of this response. It tells you whether an empty emails array means "this site publishes no addresses" or "we only looked at one page." Log it; when you re-run a domain later and the count differs, the comparison is meaningless.

An empty emails array still bills. This is not a waterfall endpoint, so a 2xx that found nothing costs the same as one that found nine addresses. Budget on domains attempted, not on addresses returned.

What comes back is whatever the site chose to publish: info@, support@, a careers alias. Those are roles, not people. Run them through the verifier before they touch a sequence, and do not treat them as prospect rows.

Flat 2 credits per call, billed on any 2xx, regardless of how many addresses come back or how many pages were crawled. Verification is billed separately per address, and a verification the waterfall cannot resolve bills zero. Credit rates are tiered by package on the pricing page.

The cost shape rewards going deep rather than wide. One call with a larger max_pages costs one call; ten separate calls at the shallow default cost ten. If you are crawling a list of domains, decide the page depth once and set it explicitly rather than calling repeatedly and hoping.

Local and SMB lists where nobody is on LinkedIn. Trades, clinics, restaurants, independent retail — these businesses have a website with an address on it and often no findable decision-maker profile. The crawl is the only path that works, and it works better on them than on enterprise sites.

Finding the right inbox for a specific kind of message. Press, partnerships, security disclosure and vendor enquiries usually have their own published addresses. If your message genuinely belongs in one of those inboxes, the published address is the correct route and better than guessing a person.

Filling a gap the identity-based finders cannot. The email finder resolves a named person to their address, which is the better tool whenever you have a name. When you have a domain and no name, this is what you have — accepting that what you get back is a routing address rather than a person.

• Email verification API — the mandatory next step, zero-billed on a soft fail
• Email finder API — better whenever you have a person's name
• Technology lookup API — what the same site runs on
• Company enrichment API — the firmographics behind the company
• All endpoints — the full catalog
• Pricing — credit packages and tier rates

What am I charged for?
Any 2xx, at the flat per-call cost, whether the crawl returns forty addresses or none. This is not a waterfall endpoint, so there is no zero-on-miss rule. Errors bill nothing.

The array came back empty. Was the site really empty?
Check pagesCrawled first. One page crawled means the crawl barely started. Then consider the ordinary reasons a site exposes no address: a contact form, an image, or a click-to-reveal script. Re-run pointed at /contact with a larger max_pages before you write the domain off.

Are these addresses verified?
No. They are strings found on web pages, some of them years old. Run them through the verifier before any of them reaches a sending system.

Why are most of them info@ and support@?
Because those are the addresses companies publish. Role accounts are what this endpoint finds by its nature. If you need a named person's address, start from the person with the email finder instead.

What should max_pages be?
Enough to reach the contact page from wherever you started. Deeper crawls cost the same as shallow ones on this endpoint, so the setting is about the crawl doing its job rather than about the bill — but confirm the current default before relying on it.

Is scraping published addresses allowed?
Publication is not consent to be emailed. GDPR, CAN-SPAM and their equivalents govern what you may send and to whom, independently of how you obtained an address, and that judgement is yours to make. We are the data layer, not your compliance review.

Do I need a credit card?
No. 100 free credits on signup, no card.

Crawl your first site in two minutes. Get 100 free credits