TL;DR
- ZeroBounce is worth testing when the pipeline needs detailed risk categories alongside verification. Its pay-as-you-go minimum is $39 for 2,000 addresses; ZeroBounce One is listed at $99/month. It says unknown results and duplicate addresses are not charged.
- NeverBounce is a direct candidate for real-time checks and large list jobs. Its API distinguishes valid, invalid, disposable, catchall and unknown. An official price snippet reports $8 per 1,000 pay-as-you-go and a $49/month Growth tier up to 10,000, but the pricing page was blocked in our reader; confirm the current checkout.
- Kickbox offers a focused verification API with deliverable, risky, undeliverable and unknown results. Official pricing snippets disagree on the 10,000-verification amount ($70 versus $80); ask which product and checkout applies rather than silently choosing one.
- Bouncer offers self-serve pay-as-you-go pricing: its page displays $60 for 10,000 and $400 for 100,000 verifications, with non-expiring purchased credits. It says unknown results and duplicates are not charged.
- Test the APIs on a representative labeled set. The winner is the one that avoids false-safe classifications, handles catch-all and temporary uncertainty in a way the sender can operate, finishes bulk jobs reliably and yields the lowest cost per correctly classified usable address, not the highest “valid” percentage.
What verification can and cannot decide
Email verification asks whether an address appears capable of receiving mail under a provider's current checks. It does not establish that the address belongs to the intended person, that the recipient wants the message, or that a campaign has permission to send. Nor can any provider promise that a mailbox will still accept mail next month. Sending systems, catch-all domains, greylisting and mailbox changes can make a useful answer uncertain.
For a high-volume enrichment pipeline, the expensive mistake is often a false-safe: an address marked usable that belongs to the wrong person, has become invalid or is classified too optimistically. A conservative provider can also create cost by putting reachable prospects into a hold queue. The buyer should decide which error matters most for each programme. A customer onboarding email has a different tolerance from a cold outbound campaign. A list of 100,000 old CRM addresses has different risk from fresh opt-in records.
The API is one layer in a broader workflow. A contact provider finds an address; the verifier classifies risk; the CRM stores provenance and suppression; the sending system observes actual outcomes. Do not turn a verifier's valid into a claim about identity or lawful outreach. Our data enrichment comparison covers the sources upstream of this decision.
Four APIs compared
| Provider | Documented result distinction | Published or reported price reference | Evaluate it when |
|---|---|---|---|
| ZeroBounce | Valid, invalid, catch-all, unknown, do-not-mail and further sub-status | $39/2,000 pay-as-you-go minimum; One $99/month | Team needs granular hold and exclusion categories |
| NeverBounce | Valid, invalid, disposable, catchall, unknown | Official price snippet: $8/1,000 PAYG; Growth $49/month up to 10k, confirm | Team needs simple real-time and list checks |
| Kickbox | Deliverable, risky, undeliverable, unknown | Official snippets conflict: $70 vs $80 for 10k, confirm | Team wants a focused API and clear risk mapping |
| Bouncer | Verification and unknown/duplicate no-charge policy | $60/10k, $400/100k displayed pay-as-you-go | Team needs a transparent bulk budget and credits that do not expire |
The figures are not a verified identical 100,000-address quote. Billing products, volume tiers, API access and credits vary. The table deliberately labels prices whose current pages could not be read consistently. The buyer should request the same 100,000-address job and real-time volume in each proposal and record what counts as a charged result.
1. ZeroBounce
Best for: a team that will use a detailed classification policy rather than reducing every result to send or delete.
ZeroBounce's pricing page says validation uses one credit per address, whether bulk or real-time. It does not charge for unknown results or duplicate addresses in a list. Its pay-as-you-go minimum is $39 for 2,000 validations; the ZeroBounce One subscription is shown at $99/month, with additional tools and credits. The page also distinguishes Email Finder and AI Scoring costs; do not accidentally include those as free validation work.
Its status documentation goes further than a simple green/red result. invalid can have reasons such as syntax, nonexistent mailbox or missing DNS. catch-all means the domain accepts mail in a way that prevents a specific mailbox from being confirmed without a real send. The docs also describe do_not_mail categories including disposable, role-based or potentially harmful addresses. A newer accept_all sub-status may be returned as valid where ZeroBounce says it has additional historical delivery evidence; the team should still preserve the original status and sub-status instead of flattening every valid result into the same confidence.
That granularity is valuable only if the sending process acts on it. A company newsletter might exclude all role accounts; a transactional system may handle them differently. A catch-all record should be held or entered into a deliberately lower-risk queue, not silently counted as verified. Ask for sample response payloads, batch reconciliation, rate limits, privacy/retention terms and a current price at the expected volume.
Where it falls short: a team that cannot maintain a status mapping may pay for nuance it ignores. A subscription with deliverability extras may cost more than a pure verifier if those extras never change decisions.
2. NeverBounce
Best for: a team that wants a straightforward result taxonomy to apply both at point of entry and in periodic large-list cleaning.
NeverBounce's single-check API reference defines valid as verified real, invalid as not valid, disposable as temporary, catchall as a domain-wide accept-all condition, and unknown as a server that cannot be reached. Those definitions matter operationally. An unknown is not an invalid address; deleting it removes a potentially reachable person. A catchall is not an assured mailbox. Preserve the result code, flags and check time in the contact record.
For high-volume jobs, request a test of the actual bulk path: submit a file containing clean, malformed, duplicate and international addresses, then reconcile every input row to one output and one billing event. Test whether the API can report an incomplete job and resume it without charging twice. Real-time checks have a different latency requirement; a form submission cannot wait as long as a nightly 100,000-record batch.
NeverBounce's pricing search result currently reports $8 per 1,000 credits for pay-as-you-go and Growth at $49/month for up to 10,000. The page itself was blocked in our text reader, so treat those as official search-snippet figures requiring checkout confirmation, not contractual prices. The quote should explain whether a credit is spent on unknown, duplicate and failed calls, along with volume discounts and expiry.
Where it falls short: a simple status mapping does not resolve person identity or send permission. If a team needs many differentiated “do not mail” categories, it should test how much can be inferred from NeverBounce flags versus other providers' sub-statuses.
3. Kickbox
Best for: developers who want a focused verification service and a policy built around deliverable, risky, undeliverable and unknown states.
Kickbox's result terminology describes those four top-level categories. The distinction between risky and unknown is not cosmetic: one may indicate properties of the mailbox or domain, while the other can mean the check could not resolve the state. Do not collapse both into “invalid.” Ask Kickbox to provide raw response fields for catch-all, role-based, disposable and other risk clues, and test how the mapping behaves on your target domains.
Kickbox's official pricing search results currently conflict. Its pricing page snippet shows $70 for 10,000 verifications, while its API page snippet shows $80 for 10,000. The pages did not open reliably in our reader. The right procurement action is to record the checkout amount and whether API calls and bulk list verification use the same credit pool. Do not present either snippet as a settled current price.
Build two integration tests: a synchronous check on a new address and a 10,000-row list. Measure median and high-percentile response time on the first; completion, partial failure and retry cost on the second. The plan may look inexpensive per 1,000 but become operationally costly if the pipeline cannot tell a temporary API failure from a true unknown.
Where it falls short: the public price discrepancy needs clarification, and a top-level four-state classification may need more detailed response fields for teams with elaborate suppression policies. The vendor should show the exact payload and terms, not only a dashboard.
4. Bouncer
Best for: a team with intermittent large batches that wants displayed pay-as-you-go prices and credits that do not expire.
Bouncer's pricing page displays $60 for 10,000, $250 for 50,000 and $400 for 100,000 verification credits in its pay-as-you-go table. It states that purchased credits do not expire and that it does not charge for duplicates in a list or unknown results. That can suit a team that cleans its database quarterly rather than spending a fixed monthly allowance. Confirm the exact checkout and whether API and application use share those credits.
The commercial appeal should not bypass the quality test. Ask for output categories, raw reasons, catch-all treatment and whether role or disposable addresses are clearly signaled. Submit the same old corporate addresses and current opt-in records used for other candidates. Then check job duration and row-level reconciliation. A headline $400 for 100,000 is not the full cost if many results require manual review or the same records are rechecked unnecessarily.
Give the data team a cache policy. Record the last successful check, provider and result. Recheck when an address changes, a send produces a meaningful bounce, an employer changes or a risk-specific time threshold passes. Do not reverify the same unchanged record on every import merely because the batch job is easy to run.
Where it falls short: the published credit model does not by itself prove lower false-safe rates or superior throughput on your data. If the team needs continuous real-time checks, test latency and availability as carefully as the bulk cost.
The status mapping the team must own
The sending application should not ingest vendor strings as if they were universal. Create a small internal classification with the raw response preserved:
| Internal state | Typical vendor result | Default action to consider |
|---|---|---|
| Acceptable for this campaign | Valid/deliverable with no conflicting risk evidence | Continue only if identity, permission and suppression also pass |
| Reject | Invalid/undeliverable, disposable or a prohibited type | Remove from send queue; preserve reason and source |
| Hold for review | Catch-all/risky or role account where policy is unclear | Check identity, prior delivery or campaign-specific tolerance |
| Temporary unknown | Server unreachable, timeout or inconclusive result | Retry later within budget; do not mark permanently invalid |
| API failure | Authentication, quota, job or transport error | Fix/retry job; never convert to an email verdict |
ZeroBounce's accept_all treatment illustrates why raw detail matters: it says some vetted accept-all domains can be returned as valid, while a generic catch-all is not confirmable. NeverBounce explicitly labels catchall as unverifiable. Two services may use different words for similar technical observations, or make different risk calls. Store provider, status, sub-status, checked time and internal decision. If providers disagree, do not simply choose the answer that allows sending; review recency and evidence under the campaign policy.
Suppression is an independent gate. A valid email belonging to someone who opted out stays suppressed. Verification also does not authenticate that a person at a company is the intended buyer. For a profile-to-email pipeline, see our LinkedIn-to-email API comparison for the matching step before verification.
A 100,000-address test
Build a 5,000-address labeled sample from the list that the production job will resemble: current corporate mailboxes, old CRM contacts, catch-all domains, disposable and role addresses, international domains, malformed input and known hard bounces. The label set should use your own reliable delivery history where available and manual review of identity. Do not send messages just to manufacture ground truth. Keep a separate holdout set so you can see whether a status mapping is overfitted to the first sample.
Run every candidate on the same sample. Report false-safe addresses, correct rejects, unknown share, catch-all share, valid addresses wrongly held, median and 95th-percentile synchronous latency, and credits charged. If an API returns extra flags, measure whether they change the team's decision. A high deliverable percentage alone is not a winning result; it may be a lax classifier. A very conservative API can also waste viable contacts.
Then run a 100,000-row bulk job on one candidate at a time with the same controlled structure. Include duplicate addresses and deliberately malformed rows. Measure accepted submission count, completed output count, partial failures, time to result, retries and billing reconciliation. A high-volume system must account for every row; missing outputs cannot be quietly treated as invalid. Test that a resumed job does not overwrite a more recent result with an older one.
Review a small set of disagreements manually and define campaign-specific policy before scaling. For fresh opt-in addresses, the team may tolerate a temporary hold and follow up through another channel. For aged outbound lists, it may demand a stricter result before sending. Neither decision can be outsourced to a vendor label.
The real verification budget
At Bouncer's displayed pay-as-you-go price, 100,000 credits cost $400, or $0.004 per purchased credit. At ZeroBounce's minimum pay-as-you-go price, 2,000 validations cost $39, or $0.0195 at that small-volume tier; that is not its 100,000-volume unit price. NeverBounce's official snippet suggests $8 per 1,000 at one tier, and Kickbox snippets disagree on a 10,000 tier. The numbers should not be lined up as if they were same-volume quotes.
Ask each vendor for a 100,000-address purchase and a second scenario with 20,000 real-time checks monthly. Record initial payment, expiry, unknown/no-result treatment, duplicate treatment, throughput, overage and whether validation and scoring share credits. Add engineering time and manual review. If the team spends $400 on credits and 12 analyst hours at $50 to resolve 2,000 held records, direct cost is $1,000, before infrastructure or downstream sending. The benefit should be measured in fewer bad sends and more correctly retained contacts, not “100,000 verifications completed.”
Which API should a team choose?
Pilot ZeroBounce if a detailed exclusion and catch-all policy is central. Pilot NeverBounce for a straightforward real-time and list-check integration, validating its current quote. Pilot Kickbox if its focused result model suits your application and its checkout resolves the pricing discrepancy. Pilot Bouncer if intermittent bulk purchases and non-expiring credits fit your rhythm. Run the same labeled sample and bulk job before naming a winner.
Verification is a control in a larger account-data system. For high-volume prospecting, the useful outcome is a current, correctly attributed address with a defensible reason to use it. A green API result is one piece of that decision, not the decision itself.
The Clay Waterfall Enrichment Guide helps place verification after discovery and before accepted records enter a sending workflow.
FAQ
Does “valid” guarantee that an email will not bounce?
No. It is the provider's current classification, based on observable signals. Mailbox state and receiver behaviour can change, and an address can be valid but belong to the wrong person. Keep the check timestamp and monitor actual delivery outcomes.
Should catch-all addresses be sent automatically?
No universal rule applies. A catch-all domain can accept probes without proving that the particular mailbox exists. Put such results into a campaign-specific review or limited-risk state and consider stronger identity or prior delivery evidence.
Is “unknown” the same as invalid?
No. NeverBounce describes unknown as a server that cannot be reached. ZeroBounce says it does not charge unknown results. Retry later within a cost and time limit; do not delete a potentially reachable contact because a provider could not decide.
How should two verifiers' disagreements be handled?
Preserve both raw responses and timestamps. Compare underlying reasons and the team's own delivery or identity evidence. Do not automatically select the result that permits sending. If uncertainty remains, hold the record under the campaign policy.
What should a high-volume API test measure besides accuracy?
Measure synchronous latency, batch completion time, every-input-to-output reconciliation, retry behaviour, duplicate and unknown billing, rate limits, data retention and operational errors. A low unit price is not enough if jobs silently lose rows.
When should an address be checked again?
Use a defined age threshold and events such as changed employer, new address, meaningful bounce or an old temporary result. Keep a recent-result cache so recurring imports do not repeatedly charge for unchanged records. Reverification does not replace suppression or contact permission checks.
