An email verification API is a web service you call from your own code to check whether an email address is real and deliverable — you send it an address, and it returns a structured result (a valid boolean plus a result like ok or catch_all_validated) without you ever touching a mail server. To integrate one you get an API key, send a POST request with the address, and branch on the response.
This guide walks the whole path: what the API checks, how to call it (with a working example), how to read what comes back, and how a good API handles the case that breaks most of them — catch-all domains. The full reference lives on the Enrichley developers page.
What Is an Email Verification API?
An email verification API is an HTTP endpoint that answers one question on demand: is this address deliverable? Instead of building and maintaining your own syntax parsing, DNS/MX lookups, and SMTP probing — and getting your sending IPs blocked in the process — you make a request to a hosted service and get back a clean, structured verdict. It's the programmable version of the email verification a tool does through a dashboard.
"Email validation API", "email verifier API", and "email checker API" all describe the same thing — the terms are used interchangeably. Wherever you need to keep bad addresses out of your data, an API is how you wire that check directly into your product:
Real-time at signup
Verify the address in the registration form before you create the account, so typos and disposable addresses never enter your database in the first place.
Before every send
Check a list programmatically ahead of a campaign to protect sender reputation. See our roundup of bulk email verification for the batch angle.
Inside enrichment pipelines
Confirm an address is deliverable as the last step of a lead-enrichment or CRM sync job, so downstream systems only ever see clean data.
In your own tooling
Build internal ops scripts, Zapier/Make steps, or admin dashboards that verify on demand — anything that can make an HTTP request can call the API.
How Does an Email Verification API Work?
An email verification API works by running an address through a series of escalating checks server-side and rolling the outcome into a single response. Each layer is cheaper and faster than the one after it, so the API resolves obvious cases early and only does the expensive work when it has to:
Syntax & format
Is it a well-formed address at all? Malformed strings are rejected immediately without touching the network.
Domain & MX records
Does the domain exist and publish mail-exchanger (MX) records? No MX means no inbox can receive mail there. The response reports the mail host as mx_domain and mx_provider.
Disposable & role-based checks
Is it a disposable (throwaway) domain, or a role address like info@ or support@? These factor into the verdict, and the response reports the kind of address as email_type (e.g. business).
SMTP mailbox check
The API opens an SMTP conversation with the receiving server and asks whether the specific mailbox exists — the same verify-without-sending handshake you'd do by hand. This mailbox check drives the result: ok for a confirmed inbox, or catch_all_validated when it resolves a deliverable inbox inside a catch-all domain.
Catch-all resolution
When the domain accepts mail for every address, the SMTP check alone can't confirm a real inbox. This is where APIs diverge — see below.
All of that happens server-side in a single call — average response time is under 200ms for most domains — and you get back one JSON object with the verdict and the individual signals that produced it.
How Do You Integrate an Email Verification API?
You integrate an email verification API in three steps: get an API key, send a POST request with the address, and handle the JSON response. With Enrichley the verification endpoint is POST https://api.enrichley.io/api/v1/validate-single-email, and you authenticate by putting your key in the X-Api-Key header on every request.
Get your API key
Sign up for a paid plan and copy your key from the dashboard. Keep it server-side — never expose an API key in client-side code.
Send the request
POST a JSON body of {"email": "[email protected]"} with your key in the X-Api-Key header.
Handle the response
Parse the JSON, branch on valid (or the detailed result), and act — accept, reject, or route to review.
Here's a complete request in three common forms. Same endpoint, same headers — pick your language:
cURL
curl -X POST "https://api.enrichley.io/api/v1/validate-single-email" \
-H "Content-Type: application/json" \
-H "X-Api-Key: YOUR_API_KEY" \
-d '{"email": "[email protected]"}'JavaScript (fetch)
const response = await fetch(
"https://api.enrichley.io/api/v1/validate-single-email",
{
method: "POST",
headers: {
"Content-Type": "application/json",
"X-Api-Key": "YOUR_API_KEY",
},
body: JSON.stringify({ email: "[email protected]" }),
}
);
const data = await response.json();
console.log(data.valid, data.result); // true "ok"Python (requests)
import requests
response = requests.post(
"https://api.enrichley.io/api/v1/validate-single-email",
headers={
"Content-Type": "application/json",
"X-Api-Key": "YOUR_API_KEY",
},
json={"email": "[email protected]"},
)
data = response.json()
print(data["valid"], data["result"]) # True "ok"Ready to wire it in?
The Enrichley developers page has the full endpoint reference, live code samples, and the response schema. Full API access is included on every plan.
See the API docsWhat Does the API Response Tell You?
The API response tells you both the headline verdict and the individual signals behind it, so you can make your own policy decision. A verification returns a JSON object like this:
{
"email": "[email protected]",
"valid": true,
"result": "ok",
"mx_domain": "example.com",
"email_type": "business",
"mx_provider": "google",
"mx_secure_email_gateway": false,
"credits_consumed": true
}The valid boolean is the headline — safe to send or not. The result field gives the detail, one of five values:
ok — the mailbox exists and is deliverable. Safe to send.
catch_all_validated — a catch-all (accept-all) address we confirmed is deliverable — the ones most tools give up on. valid is true; safe to send.
catch_all — an accept-all domain we couldn't resolve to a specific inbox. Uncertain; treat with caution.
invalid — the address is undeliverable. Drop it; sending will hard bounce.
unknown — the receiving server didn't give a definitive answer (e.g. a temporary block). Retry later.
Alongside the verdict, each response carries context — mx_domain and mx_provider (the mail host), email_type (e.g. business), mx_secure_email_gateway (whether the domain sits behind a security gateway), and credits_consumed (whether this call spent a credit). Rate-limit and balance state come back in response headers — x-ratelimit-remaining and x-credits-remaining — so a well-behaved client can self-throttle without a second call.
How Does the API Handle Catch-All Domains?
Catch-all domains are where email verification APIs quietly separate into good and mediocre. A catch-all (accept-all) domain is configured to accept mail for every address at the domain, whether the mailbox exists or not. That defeats the standard SMTP check: the server says "yes" to everything, so a plain check can't tell a real inbox from a typo. And catch-all isn't a rare edge case — 40-60% of B2B domains are catch-all.
Most APIs give up
They mark the address risky or unknown and hand the problem back to you — so a big slice of your list becomes unusable.
Enrichley resolves them
Proprietary techniques identify valid inboxes within catch-all domains with 98% accuracy — recovering 20-30% more valid emails competitors write off.
In the response, the result field tells you exactly which kind you're in: catch_all_validated when we confirm a deliverable inbox inside a catch-all domain (with valid: true), versus catch_all for an accept-all domain we couldn't resolve. A resolved catch-all comes back as a first-class deliverable result, not dumped into a "risky" pile. If catch-all handling is your main concern, the dedicated catch-all verifier and our guide on how to verify catch-all emails go deeper.
Pricing, Credits & Rate Limits
Enrichley bills the API by credit: each email verification costs one credit. Plans start at $59/mo for 5,000 credits (Starter) and scale up from there, and — this is the part that matters for developers — full API access is included on every tier, so the API isn't locked behind an enterprise contract. Credits roll over for as long as your subscription is active, and annual billing saves 15%.
1 credit
per email verification
10 req/s
default rate limit, 10 concurrent
<200ms
average response time
You can check your remaining balance any time with the GET /me endpoint, which returns your account status, remaining credits, and monthly allocation. Need more than 10 requests per second for a large batch job? Contact support about higher-throughput enterprise options. See the pricing page for the full tier breakdown.
Frequently Asked Questions
What is an email verification API?
How do you integrate an email verification API?
What's the difference between an email validation API and an email verification API?
How does an email verification API handle catch-all domains?
How much does an email verification API cost?
What are the rate limits on the email verification API?
Start Verifying in Minutes
Grab an API key, drop in the endpoint, and start returning verified addresses — catch-all included — from your own app. Full API access on every plan.