Build email verification into your own systems
A REST API with key-based authentication, webhooks for delivery and engagement events, and SMTP sending — so verification runs at the boundary of your system rather than as a cleanup job.
What you get
- REST endpoints for single and batch verification under /api/v1
- API keys you can scope and rotate, without sharing account credentials
- Webhooks for delivery, bounce, open and click events
- Credit-based billing, so integration cost tracks usage rather than seats
/api/v1
Versioned REST surface
Single and batch verification endpoints with key-based authentication.
Webhooks
Event delivery
Bounces, opens and clicks pushed to your endpoint rather than polled.
2-step
Verification per address
DNS/MX resolution, then a live SMTP mailbox check — not a regex.
Validate at the boundary, not in a cleanup job
Most teams discover email data quality late: a marketing campaign bounces, someone exports a CSV, and a cleanup runs. By then the bad address has already propagated into the CRM, the warehouse, the support tool and the billing system — and each of those has its own copy.
The alternative is to treat an email address like any other untrusted input and validate it at the boundary where it enters your system, which is what an API call at signup actually buys you.
| Periodic cleanup | Validation at capture | |
|---|---|---|
| When you find out | After the bounce | Before the record is written |
| Blast radius | Every system holding a copy | One rejected form submission |
| User can fix the typo | No — they have left | Yes, while they are on the page |
| Reputation cost | Already incurred | None |
| Recurring work | Ongoing cleanup cycles | One integration |
What you integrate with
REST verification endpoints
Single-address and batch verification under a versioned /api/v1 surface, returning JSON with a classification rather than a bare boolean.
Scoped API keys
Issued and revoked from your account, independent of login credentials, so rotation does not disrupt human access.
Event webhooks
Delivery, bounce, open and click events pushed to your endpoint, so suppression can be enforced in your own systems.
Bulk jobs for list cleaning
Queue a whole list and collect results asynchronously rather than holding open thousands of synchronous requests.
SMTP sending with per-account DKIM
Campaign delivery over direct SMTP, signed with your account's own key on your own sending subdomain.
Credit-based usage
Consumption scales with calls rather than seats, which suits integrating into a flow whose volume you do not control.
Integrating without breaking your signup flow
The main implementation risk is latency. A real verification involves an SMTP conversation with someone else's mail server, and that server's response time is not yours to control. Design for that rather than assuming it returns instantly.
- 1
Call verification asynchronously where you can
If the signup does not strictly require an instant decision, verify after submission and act on the result rather than blocking the form.
- 2
Set a timeout and decide the fallback deliberately
If the check times out, accept the signup and flag the record rather than rejecting a legitimate user because a third-party server was slow.
- 3
Handle catch-all as a distinct state
Treating it as invalid rejects real customers on accept-all domains. Store it as unknown and let engagement resolve it.
- 4
Fail open, log loudly
A verification outage should degrade to accepting signups with a flag, not to blocking registration. Log the fallback so the gap is visible.
- 5
Consume webhooks for suppression
Write bounce events straight into your own suppression table so every system that sends mail honours them, not just the campaign tool.
- 6
Re-verify on a schedule for stored records
A record verified at signup two years ago is not verified now. Batch re-verification keeps long-lived customer data current.
Read the endpoint reference
Request and response shapes, authentication, result classifications and batch behaviour — documented for direct integration.
See the API documentationInterpreting results in code
The most common integration bug is collapsing a five-state result into a boolean. Each classification implies a different action, and flattening them either rejects real users or admits addresses that will bounce.
| Result | Meaning | Suggested handling |
|---|---|---|
| valid | Mailbox confirmed to accept mail | Accept |
| invalid | Syntax, domain or mailbox failure | Reject and ask for a correction |
| catch-all | Domain accepts every recipient — unknown | Accept, flag, confirm via engagement |
| disposable | Temporary-mail domain, expires shortly | Reject for trials and paid signups |
| role_based | Shared functional mailbox such as info@ | Accept, but exclude from consumer nurture |
- Read the per-type detail in the catch-all, disposable and role-based explainers before finalising your handling rules.
- Store the raw classification, not a derived boolean — you will want to revisit the policy later.
- Record the verification timestamp, so you know when a stored result has aged out.
Frequently asked questions
Syntax, then DNS and MX resolution for the domain, then an SMTP conversation with the receiving mail server to confirm whether that specific recipient is accepted. Results distinguish valid, invalid, catch-all, disposable and role-based rather than returning a single boolean.
With API keys issued from your account, sent as a bearer credential. Keys are separate from your login so they can be rotated or revoked without changing account access.
There is a batch path for bulk verification as well as a single-address endpoint. Use batch for list cleaning and the single endpoint for real-time checks at the point of capture, where latency matters.
It depends on the receiving mail server, because the check involves a real SMTP conversation with it. Design your signup flow to handle a slow or timed-out response gracefully rather than blocking submission indefinitely on a third-party server.
Do not treat it as invalid. A catch-all domain accepts every recipient, so the result is genuinely unknown rather than negative. Accept the signup and flag the record for engagement-based confirmation later.
The API is plain REST over HTTPS with JSON, so any HTTP client works. Rather than claim SDK coverage that may not match your stack, the endpoints are documented for direct integration.
Yes — campaign sending goes through direct SMTP delivery with per-account DKIM signing, and delivery events are available via webhooks. Verification and sending are separate concerns you can adopt independently.
Credits are consumed per verification rather than billed per seat or per stored contact, so a spike in signups raises usage rather than requiring a plan change.
Get an API key and try a call
Free credits included — enough to integrate and test before paying.