An email verification API cannot prove that a person will reply, that a mailbox will remain reachable, or that a Lead fits a Business. Its useful job is narrower: return current, documented evidence that a validation workflow can preserve, explain, and combine with other Validation Checks before routing.

Method, verified August 25, 2026: We included the seven providers named in Lucidity's August content plan because each has public first-party API documentation for email validation. Products are listed alphabetically. We compared only fields and processing behavior visible in current official docs, did not create accounts or run vendor accuracy tests, omitted volatile prices, and mark absent public evidence as not documented.

Email validation API evidence matrix

Seven email validation APIs compared by result taxonomy, identity signals, mail evidence, and processing model
API Primary result and reasons Role, disposable, catch-all Mail evidence Processing shape
Abstract API Documents deliverability status and detail. Richer public response examples add quality and risk objects by plan. Public product documentation lists role, disposable, and catch-all checks; response depth is plan-dependent. Format, SMTP, and MX validity plus MX records are shown in current response examples. Real-time REST API with documented bulk operations and plan-based limits.
Emailable Returns state, reason, and score. States include deliverable, undeliverable, risky, and unknown. Separate role, disposable, accept_all, and free-provider fields. Returns MX record, SMTP provider, mailbox-full, and no-reply evidence. SMTP and accept-all checks can be configured. Single verification plus an asynchronous batch workflow with callbacks.
Hunter Returns detailed status and score. The older three-value result is documented as deprecated. Separate disposable, webmail, and accept-all fields. A role flag is not shown in the public Email Verifier response schema. Exposes regular-expression, MX-record, SMTP-server, SMTP-check, and SMTP-block fields. Single verifier can return HTTP 202 for polling when work exceeds 20 seconds.
Kickbox Returns result, reason, and a Sendex value, with deliverable, undeliverable, risky, and unknown results. Separate role, free, disposable, and accept-all fields. The public single-verification response does not expose raw MX or SMTP booleans. Single verification endpoint; no fixed rate limit is stated on that page.
Mailgun Returns result, risk, and a reason array. Results include deliverable, undeliverable, do not send, catch-all, and unknown. Separate role and disposable fields; catch-all and accept-all appear in the result or reason taxonomy. Provider lookup is configurable. Reasons include no MX, SMTP error, timeout, and mailbox conditions rather than raw SMTP booleans. Current docs state that single and bulk validation are available via the EU API.
Verifalia Returns a broad classification plus a specific status. Classifications are deliverable, undeliverable, risky, and unknown. Separate disposable, role-account, and free-provider fields. Catch-all is a specific status such as ServerIsCatchAll. Exposes syntax and international-address details. Public entry fields do not present raw MX or SMTP success booleans. Job API accepts arrays, supports polling or bounded waiting, and exposes retention.
ZeroBounce Returns status and detailed sub_status values for invalid, uncertain, abuse, and temporary conditions. Catch-all and free-provider fields are separate; role and disposable appear in the documented sub-status taxonomy. Returns MX presence, preferred MX record, and an SMTP provider field. Single validation supports a timeout; real-time batch validation is separately documented.

Important boundary: a provider's deliverable result is field-level evidence, not a Lucidity qualified outcome. Lead Validation can combine email evidence with phone, name, duplicate, source, and Business rules. Delivery begins only after the overall Validation Outcome allows routing.

How should ambiguous email results be handled?

Common email validation evidence and safe workflow actions
Evidence What it means Safe default Do not infer
Catch-all or accept-all The domain accepts recipients too broadly to prove this mailbox exists. Keep the uncertainty visible and apply Business policy or review. That the address is valid or invalid.
Unknown, timeout, or temporary error The provider could not finish a conclusive check at that time. Record an unknown check and retry only under a bounded policy. That the Lead supplied bad contact data.
Disposable The address uses a provider identified as temporary or disposable. Combine with the stated Business requirement and other contact evidence. That every disposable address is abusive.
Role address The local part may represent a team function such as sales or support. Use as a qualification or review signal only when relevant. That no reachable person monitors it.
No MX or failed syntax The address has a structural or domain-level obstacle to receiving mail. Preserve the specific reason and weigh stronger independent contact paths. That the entire Lead must always be blocked.

This is where a normalized Validation Check helps. Store the provider's original status and reason, map them into a small local status such as valid, invalid, risky, or unknown, and preserve when the check ran. The Business policy can then decide whether email is required, whether another contact path is sufficient, and whether the Lead should be qualified, held for review, blocked, or treated as an error.

What distinguishes the seven APIs?

Abstract API

Best fit when a tiered response can combine deliverability with additional sender, domain, quality, or risk blocks. Verify the exact plan schema before integration.

Emailable

Best fit when state and reason need separate role, disposable, accept-all, mailbox-full, no-reply, score, and provider fields in one response.

Hunter

Best fit when a workflow wants explicit MX and SMTP check booleans plus polling behavior for a single verifier request that does not finish immediately.

Kickbox

Best fit when a compact result and reason contract with role, disposable, accept-all, free-provider, typo suggestion, and Sendex evidence is sufficient.

Mailgun

Best fit when a mail platform integration can use result, risk, reasons, and an optional provider lookup with documented single and bulk validation.

Verifalia

Best fit when validation is job-oriented and needs arrays, quality levels, retention, progress, deduplication, specific statuses, and broad classifications.

ZeroBounce

Best fit when a workflow needs a wide status and sub-status vocabulary, MX details, catch-all evidence, free-provider evidence, and temporary failure detail.

These descriptions are fit statements derived from the documented response shapes, not performance rankings. A smaller schema may be easier to normalize. A larger schema may preserve more evidence but also requires more policy and versioning work.

Single checks, bulk jobs, latency, and rate limits

Real-time form validation and retrospective list cleaning are different jobs. A request that waits on a remote mail server can be too slow for an Intake, while an asynchronous job can be the safer shape for large imports. Treat every vendor limit as publication-date evidence and recheck it before capacity planning.

Publicly documented single, bulk, timeout, and rate-limit behavior
API Single or bulk evidence Timeout or asynchronous behavior Public rate evidence reviewed
Abstract API Real-time endpoint and bulk operations are documented. Response speed is a vendor claim; no universal latency guarantee assumed. Public page shows plan-dependent requests per second.
Emailable Single verify and asynchronous batch endpoints. Single timeout is configurable from 2 to 10 seconds; batch supports callbacks. No fixed account-wide rate used in this comparison.
Hunter Public Email Verifier docs describe a single endpoint. After 20 seconds it can return HTTP 202 for later polling. 10 requests per second and 300 requests per minute.
Kickbox Single-verification response reviewed. Request timeout is configurable on the documented endpoint. No fixed limit stated on the reviewed page.
Mailgun Single and bulk validation are documented via the EU API. Reasons distinguish SMTP timeout and other uncertain outcomes. No fixed limit stated on the reviewed validation pages.
Verifalia One job can accept one or many addresses. Clients can poll or request bounded internal waiting up to 30 seconds. Throttling can be configured per user; no universal fixed value assumed.
ZeroBounce Single validator plus a separate real-time batch endpoint. Single timeout can be set from 3 to 60 seconds. Current v2 docs publish 80,000 single requests per 10 seconds.

Privacy and failure handling belong in the selection

An email address is personal data in many contexts, and provider responses can add more derived evidence than routing needs. Send only the email field required for the check. Do not forward the raw Lead, Interest, source payload, or other contact fields to an email provider by default. Review processing location, retention, deletion, subprocessors, authentication, incident terms, and whether optional enrichment can be disabled.

The API contract should also separate four failure classes: invalid input, provider transport failure, inconclusive mailbox evidence, and a completed negative result. Only the last two belong in a Validation Check. A provider outage or rate limit must not silently become evidence that a Lead supplied an invalid address.

A five-step selection flow

  1. Write the decision first. State whether email is required, optional, or one of several acceptable contact paths for the Business.
  2. List the evidence that decision needs. Choose status detail, role, disposable, catch-all, MX, SMTP, typo, free-provider, or temporary-error fields only when each changes an explicit action.
  3. Match the processing model. Use bounded single checks for Intake decisions and asynchronous bulk jobs for imports or revalidation where appropriate.
  4. Normalize without erasing detail. Preserve provider status and reason values beside the local Validation Check status and policy version.
  5. Test uncertainty and failure. Cover catch-all, greylisting, timeout, rate limit, malformed input, provider outage, disposable, role, and no-MX cases before allowing automatic Delivery.

For the larger system boundary, read the Lead Validation API response guide. The Lead qualification software guide explains when a provider, rules engine, or orchestration layer fits, while the Lead qualification checklist covers the other evidence a routing decision may need.

Primary sources checked August 25, 2026

Frequently asked question

Which API returns the evidence my validation workflow needs, and how should ambiguous results be handled?

Choose the API whose documented response exposes the field-level evidence your policy actually uses, such as status and reasons, role, disposable, catch-all, MX, SMTP, or temporary failure details. Preserve the provider's raw result, map it into a normalized Validation Check, and let Business policy produce the overall outcome. Catch-all, timeout, and unknown responses are ambiguous evidence and should normally trigger review, retry, or another policy-specific action rather than an automatic block.

Turn provider evidence into explainable outcomes

Bring the email response fields and Business policy your workflow needs. See how Lucidity preserves each Validation Check, holds ambiguous evidence for review, and routes from one explicit Validation Outcome.

Request a Lead Validation walkthrough