Example
See a validation request, response interpretation, suppression policy, retry behavior, and webhook path for valid, invalid, risky, catch-all, and unknown results.
The simplest validation call accepts one email address and returns status, sub_status, confidence, provider evidence, and individual signals.
A practical product policy usually suppresses invalid and disposable addresses, segments catch-all and role addresses, and retries unknown results.
| Result | Policy | Reason |
|---|---|---|
| valid | Accept | Evidence suggests the mailbox is reachable. |
| invalid | Suppress | Hard failures damage reputation and waste sends. |
| risky | Segment | Risk depends on campaign and recipient context. |
| unknown | Retry or send conservatively | The provider did not produce reliable evidence. |
Production pattern
Keep the request, response, policy decision, and asynchronous follow-up connected. Store identifiers and reason codes so support and engineering can explain why an address was suppressed or why a release check failed.
| Stage | Application action | Evidence to retain |
|---|---|---|
| Request | Send an authenticated API call with bounded input. | request id and workflow owner |
| Response | Parse status and reason fields without coercing uncertainty. | status, sub-status, confidence, reasons |
| Decision | Apply a versioned suppression or review policy. | policy version and decision |
| Async follow-up | Poll or process a verified webhook when work continues. | job id, event id, final state |
Failure handling
Separate temporary delivery problems from validation evidence. Retry bounded transport failures, preserve uncertain outcomes, and make asynchronous processing safe to repeat without turning missing evidence into a confident result.
How to use this example
Examples are not decorative screenshots. They should show the request, evidence, interpretation, decision, and next internal link. Use them when you need to explain a result to a teammate or convert a diagnostic finding into a policy.
Decision policy
A good example does not stop at valid, risky, pass, or fail. It says whether to accept, suppress, segment, retry, fix DNS, change a template, open an owner task, or retest after propagation.
Use /test when the question is whether the exact production email is technically ready.
Use /validator or /validator/bulk before imports, outbound, newsletters, and reactivation.
Use /docs/api when deliverability QA belongs in CI, release tooling, or an internal workflow.
Related
Capture development messages, inspect source, and run reusable CI checks.
Review authenticated endpoints, request shapes, errors, and quotas.
Verify HMAC signatures and process asynchronous events safely.
Use Node, Python, and command-line helpers for common workflows.
Review the product workflow for teams operationalizing email validation api and bulk verification.
Understand how risky, catch-all, unknown, role, disposable, and invalid verdicts should drive product decisions.
Compare single-address checks, bulk jobs, result statuses, and follow-up evidence before using a list.
Review the CSV upload, progress, export, and webhook behavior for larger recipient-list checks.
Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.
FAQ
No. A sandbox verifies message generation, source, rendering, and configured checks. Run a real-message test through the production sender path before relying on the result.
Verify the signature, store a stable delivery or event identifier, and make processing idempotent before returning success.
Use the request and policy patterns, but replace sample keys, domains, tokens, and thresholds with your own account and risk policy.
