Choosing the best email verification API: what to test before you buy

The best email verification API for you is the one that's right on the answers it gives as definite, honest about the ones it can't give, priced in a way that matches your volume, and easy to wire into the tools your team already uses. There isn't one winner for every team: a growth team cleaning a quarterly newsletter list and a developer verifying signups in real time weigh those criteria differently. Test against your own data before you commit.

Below are the criteria we'd use, the questions to ask each vendor, and a test plan you can run in an afternoon. For side-by-side notes on specific vendors, see the verification API comparisons.

1. Accuracy on definitive results

Any verifier can be made to look accurate by calling everything "valid". What you want is a low error rate on the answers it gives as definite: valid should rarely bounce, and invalid should rarely be a real person.

Ask:

• What exactly does "valid" mean? Is it a mailbox the server accepted on a domain that rejects random addresses, or just "the domain has an MX record"?
• How are permanent rejections separated from rejections aimed at the verifier's own IP? A server blocking the checker isn't evidence the mailbox is missing.
• Does the vendor publish how it measures accuracy, and on which kinds of addresses?

The mechanics behind these questions are in email verification accuracy explained.

2. Catch-all and unknown handling

This is where vendors differ most. A catch-all domain accepts every address during the SMTP conversation, so no verifier can tell from that alone whether jane@ exists. Greylisting and rate limits produce temporary answers that a quick check can't resolve.

Look for:

• A distinct status or flag for catch-all, not a quiet "valid".
• Reasons attached to unknown (greylisted, blocked, timeout), so you can decide what to retry.
• Clear rules on whether you're charged for unknown results.

If your list is heavy on business domains, this criterion can matter more than headline accuracy. Our guide to catch-all email domains covers what to do with those addresses once you have them.

3. Pricing model

Compare the model, not just the price per check:

• Pay-as-you-go credits vs subscription. Credits suit occasional list cleaning; subscriptions suit steady real-time volume.
• Credit expiry. Some credits expire, some don't. Check the vendor's own pricing page.
• What counts as a check. Duplicates, cache hits, unknown results and API retries may or may not be billed.
• Rate limits and daily caps. A low price with a low throughput ceiling may not fit a large import.

4. API design and developer experience

Your developers will live with this part. Check:

• A single-address endpoint fast enough for a signup form, and a batch or bulk option for lists.
• A response with a status, a machine-readable reason and the underlying checks, not just a score.
• Typo suggestions (gmial.com to gmail.com) you can show users.
• Predictable errors: distinct codes for bad auth, rate limits and exhausted quota, so retry logic can tell them apart.
• An OpenAPI spec or clear reference, and copy-pasteable examples.

5. Integrations with the tools your team uses

Sales, marketing ops and RevOps rarely call an API by hand. Ask how the verifier fits into:

• The CRM (HubSpot, Salesforce, Pipedrive), at lead creation and for periodic re-checks.
• Outbound and sequencing tools, right before a list is loaded.
• Signup and onboarding flows, where latency matters.
• Email platforms, before a large campaign.

Native integrations are convenient. An HTTP API that works from automation tools, webhooks and small functions covers everything else.

6. Data handling

You're sending personal data to a third party. Ask what's stored after each check, in what form, for how long, and whether uploaded files can be deleted on demand. The GDPR side of this is covered in email verification and GDPR.

A test plan you can run this week

1. Collect 30 to 50 addresses you know are real (colleagues, customers who replied recently).
2. Make up the same number of addresses on those domains that you know don't exist.
3. Add addresses on a few domains you know are catch-all.
4. Run the list through each candidate.
5. Score agreement on real vs nonexistent only. Separately, note how each one labels the catch-all and unanswerable addresses.
6. Time the single-address endpoint from your own servers.

Where pingutil fits

pingutil is a verification API built for teams that want accurate answers they can act on, at a cost that makes sense for routine checks. POST /v1/verify handles one address and POST /v1/verify/batch handles up to 50. Each result has a status (valid, invalid, risky, unknown), a reason, a score, did_you_mean and the individual checks. Catch-all domains come back risky / accept_all, never valid, and servers that won't answer come back unknown with the reason. It never sends an email to the address.

It's built to be dropped into CRMs, sequencing tools, signup flows and email platforms through plain HTTP. Limits today are 60 requests a minute and 300 verifications a day per account, so very large one-off list cleans are better served elsewhere for now. Compare it directly with ZeroBounce, NeverBounce, Kickbox or Hunter, try addresses in the verification demo, and read the API reference.