Bouncer Email Verification: An Acceptance Test

Bouncer email verification should be approved only after a blinded acceptance test shows how its deliverable, risky, undeliverable, and unknown results map into your operating policy. Test both the production batch path and any real-time path you intend to use. Reconcile submitted rows, credits, returned records, suppressions, evidence, integrations, and exports before routing live campaign data through the tool.

Define the Bouncer acceptance decision

The official Bouncer pricing page describes email verification as a credit-based product rather than a fixed monthly verification plan. It lists a minimum purchase of 1,000 credits for $8, says on-demand verification credits do not expire, and states that duplicates within a list and unknown results are not charged.

That commercial model is useful, but this article addresses a different decision: whether Bouncer's operating behavior is acceptable for your workflow. A checkout transaction does not prove that classifications map cleanly, uncertain records are controlled, batch totals reconcile, or evidence can be exported.

Use a written acceptance record with named owners for verification policy, integration, suppression, reconciliation, and final approval. The record should define pass, conditional pass, and fail conditions before provider results are visible.

Our view: Bouncer earns production approval only when its raw outputs remain traceable through the final internal decision. A clean dashboard total is not enough if the CRM cannot explain why a record was allowed, withheld, or queued for review.

Build a blinded verification fixture

Create one frozen file that resembles the data the system will process. Replace unnecessary personal context with internal record IDs, restrict access, and preserve the exact normalized address submitted to Bouncer.

Include authorized examples of important cases: known internal mailboxes, malformed addresses, duplicates, disposable domains, accept-all domains, role accounts, and addresses that previously produced no response. Do not label a record as ground-truth deliverable or undeliverable unless independent evidence supports that conclusion.

Blind the internal reviewer to the provider name where practical, especially if Bouncer is being compared with an incumbent. This reduces brand preference from influencing exception handling.

Map Bouncer classifications into policy states

Bouncer's official terminology documentation defines four main results: deliverable, risky, undeliverable, and unknown. Risky can include accept-all, full-mailbox, or disposable conditions. Unknown means Bouncer could not receive a response from the provider.

Bouncer also reports domain-level information such as acceptAll and whether a domain is disposable. Preserve those fields instead of reducing the response to a single yes-or-no value.

Your internal map should be versioned. If policy changes later, the organization must be able to distinguish the vendor response received at the time from the decision rule applied afterward.

Never let a deliverable result override an unsubscribe, complaint, legal block, client exclusion, or previous hard-bounce suppression. Verification supplies one input, while the campaign eligibility policy remains authoritative.

Test batch and real-time paths independently

Bouncer's email verification API page states that a batch can contain up to 500,000 addresses and recommends batches of 1,000 to 10,000. That published maximum should not become the first production test size.

Bouncer's integration guidelines explain that the real-time API is intended for situations where response time is important, but may produce more unknown results when an address requires longer SMTP retries. The same guidance recommends the batch API for maximum volume.

Define separate acceptance checks:

Do not assume the two paths produce identical operational distributions. Test each against the use case it will serve, and report results separately.

Our email verification API guide explains why provider statuses should enter a controlled policy layer before campaign use.

Reconcile every row and credit

Bouncer says one new account receives 100 free credits and that auto-refill is available. It also says duplicate addresses within a list and unknown results are not charged. Those rules need to appear in the acceptance ledger, not merely in procurement notes.

For each job, reconcile:

submitted rows = charged verifications + uncharged duplicates + uncharged unknowns + any other documented non-charge rows

That formula is a test hypothesis, not a substitute for the vendor ledger. If the totals do not match, keep the job on hold until Bouncer's returned data or support explanation resolves the difference.

Also reconcile the output file to the input by internal ID. Check for missing rows, extra rows, changed addresses, duplicated outputs, and status totals that differ between the dashboard and downloaded results.

Auto-refill can prevent a job from stopping, but it can also turn a loop or accidental resubmission into unplanned spend. Test low-balance alerts, refill thresholds, permissions, and the ability to disable refill before enabling it in production.

Validate suppression precedence and failure behavior

Write the precedence order before connecting Bouncer to a CRM or campaign platform. A practical model begins with legal and consent restrictions, then complaints and unsubscribes, client exclusions, prior bounce evidence, Bouncer status, and campaign-specific eligibility.

The exact order depends on your policy, but stronger suppressions must not be cleared by a later deliverable response. Require separate fields for raw Bouncer status, Bouncer subreason, internal suppression state, decision timestamp, and policy version.

Test failure cases deliberately in a sandbox or reversible route. Simulate an unavailable API, malformed response, missing field, expired credential, duplicate callback, and downstream write failure. The safe response is to hold the record and alert an owner, not silently convert uncertainty into approval.

Our outbound lead generation services show how data controls, verification, sending infrastructure, and CRM handoff fit into one owned operating system.

Inspect the actual integration

Bouncer's official integration directory lists connections including Brevo, Constant Contact, ConvertKit, GetResponse, HubSpot, Klaviyo, Mailchimp, MailerLite, Make, Pipedrive, QuickMail, and Woodpecker.

A listed integration still needs an acceptance test. Confirm which object and field trigger verification, whether Bouncer writes back the raw status and reason, what happens to existing values, how duplicates are handled, and whether a failed write can be replayed safely.

Use least-privilege access where the connected system permits it. Record who owns the credential, how it is rotated, and how the connection is revoked at exit. If a no-code platform sits between Bouncer and the destination, include that platform's job history and error handling in the evidence chain.

Approve only the route tested. A successful HubSpot test does not establish that a separate file-transfer or campaign-platform integration behaves the same way.

Verify export and retention before production

Bouncer's batch-results API documentation says completed results can be downloaded as JSON and filtered by status, including a deliverable-only result set. Test the complete export first. A filtered file is useful only when the full job remains reconcilable.

Bouncer's privacy and GDPR page says verification results can be permanently deleted on demand and otherwise are erased after 60 days. It also says uploaded addresses are hashed except in the result-download layer and that data is stored in European Union AWS data centers.

Set an internal evidence deadline shorter than 60 days. Capture the authorized raw response, job metadata, counts, policy map, exceptions, and approval record. Then apply your own retention and deletion policy rather than treating the vendor window as a recommendation.

Run an exit exercise before approval. Download a representative completed batch as JSON, verify every field needed by the internal policy, import it into a client-controlled system, revoke a test credential, and confirm that no live workflow continues sending data.

Make the approval reversible

The final acceptance record should state which Bouncer path is approved, the allowed batch size, timeout and retry rules, classification map, suppression precedence, credit controls, evidence owner, retention deadline, and rollback steps. Any untested integration or workflow remains out of scope.

Approve conditionally when a bounded issue has a named owner and deadline. Reject or pause when records cannot be reconciled, raw reasons are lost, stronger suppressions can be overwritten, failures default to approval, or an export cannot support exit.

LeadHaste can design the blinded fixture, policy map, reconciliation record, failure tests, and client-owned handoff around your ICP and campaign rules. Book your free ICP and campaign-fit discovery call →