DeBounce Email Validation: Credits, Workflow, and Buyer Fit

DeBounce email validation offers low published pay-as-you-go prices, bulk and real-time routes, a useful result taxonomy, and credits that do not expire. The purchase makes sense when a team can map each status to a send, hold, or reject decision and test the actual cost of catch-all and enrichment options. We would not approve it from the headline accuracy or deliverability guarantee alone because the guarantee is narrow and the public pages leave security and retention questions to procurement.

DeBounce email validation: quick facts

DeBounce supports dashboard uploads, single-address API checks, bulk API jobs, a public JavaScript key, integrations, and spreadsheet or form workflows. The relevant buying question is not whether an address receives a green label. It is whether the returned result, credit charge, export, and deletion behavior fit the team's data-control process.

Upload and API routes have different controls

The bulk validation page accepts CSV or TXT files with up to 200,000 addresses. CSV uploads preserve original columns. DeBounce identifies duplicates before validation, and exact duplicate rows within that list do not consume credits.

The bulk API upload also accepts CSV or TXT under 20 MB with no more than 200,000 addresses, but it expects one email per line. The file must be hosted at a direct public HTTPS URL on the customer's server. The documentation says Google Drive, Dropbox, and OneDrive links are unsupported.

That public-file requirement changes the security review. Use a short-lived, unguessable URL, restrict the file to the needed column, remove it immediately after ingestion, and confirm access logs. Do not expose a full CRM export merely because the endpoint requires a URL.

Only one bulk API job can run at a time. Later jobs queue. The status endpoint reports progress and eventually returns a CSV result link. Test queue ordering, expiration, retries, and duplicate uploads before designing a nightly process.

The single-validation endpoint returns JSON for signup, checkout, form, or CRM use. Public JavaScript keys can be restricted to approved CORS domains and are limited to 20 validations per IP per day. A public key still needs domain restrictions and abuse monitoring.

Result codes require explicit routing

The result-code guide defines the operational categories.

The single API returns the address, numeric code, display result, reason, role and free-email flags, transactional-send guidance, a suggested correction, success state, and remaining balance. Save the raw code and reason. A marketing label can change while the numeric response remains the integration contract.

A Deliverable result does not prove identity, consent, current employment, inbox placement, or future validity. A Role result may be suitable for a requested support address and unsuitable for a named-person campaign. DeBounce should classify the technical address signal; the buyer should own the contact decision.

The API response documentation uses "Safe to Send" as a display result and "Deliverable" as a reason. Newer marketing copy also uses valid and deliverable labels. Implement against the actual raw response, not a screenshot or sales label.

Credit math is clear until optional checks begin

The pricing calculator lists these pay-as-you-go tiers:

The page advertises prices from roughly $0.00045 per check, 100 signup credits without a card, non-expiring credits, one balance for dashboard and API use, and taxes and fees included in displayed prices. A visible monthly mode showed an 8% discount, but the inspected public copy did not clearly define renewal, cancellation, or rollover for that mode. Treat the calculator state as a quote to verify at checkout.

Standard validation costs one credit for every submitted address, regardless of whether the result is deliverable, invalid, unknown, disposable, role-based, or catch-all. Only duplicates found inside the same uploaded list are clearly free.

The catch-all billing guide says deeper catch-all validation costs ten additional credits for an address already classified as catch-all. That makes the full path 11 credits. Do not run it on every catch-all by default. First decide whether its result changes the CRM action.

The enrichment pricing guide says successful enrichment costs 20 additional credits. A successfully enriched and validated row therefore costs 21 credits. A profile-photo option costs one extra credit when a photo is returned. List monitoring is priced at twice the list size per month.

Cost per check is not cost per accepted record. Include unknowns, catch-alls, repeated jobs, optional checks, enrichment, integration work, and records rejected by identity, suppression, or current-employer rules.

API capacity needs a retry plan

DeBounce documents HTTP 200 for success, 401 for a missing or invalid key, 402 for exhausted credits, 403 for a forbidden operation, and 429 for rate or concurrency limits. Regular keys support five concurrent calls. Enrichment reduces that to two.

Build retries around the documented error, not around every non-200 response. A 401 or 402 requires operator action. A 429 can be retried with backoff and an idempotency record on the buyer's side. The public pages do not establish that repeating a request is free.

Record balance before and after each controlled request. The response includes remaining balance, which lets the test reconcile expected and observed charges. Alert before the balance reaches zero so a real-time form does not silently stop validating.

For bulk jobs, store the DeBounce job ID, source file checksum, submission time, row count, status, output link, and final charge. Do not submit the same file again merely because polling failed.

Integrations still need field-level testing

The integration directory names routes for HubSpot, Google Sheets, Mailchimp, ActiveCampaign, Klaviyo, Brevo, Mailgun, SendGrid, Apollo, lemlist, WordPress, WooCommerce, Zapier, and form plugins. Several directory entries are Zapier workflows rather than native, two-way sync.

Dashboard exports can be split into deliverable, undeliverable, unknown, disposable, duplicate, and catch-all groups. Original CSV columns are preserved. The bulk API status route returns a CSV result link for API jobs, while dashboard uploads do not expose status through that endpoint.

Test the exact route with an immutable record ID. Confirm original fields survive, the result maps to the intended CRM field, trusted data is not overwritten, duplicate records stay suppressed, and rollback is possible.

The guarantee is narrower than the headline

DeBounce publishes a deliverability guarantee, but its public percentages are not fully consistent. The homepage references 97%. The detailed page leads with 97.5%, then specifies 95% or better for Microsoft accounts and 98% or better elsewhere. A refund example again uses 97%.

The guarantee requires at least 1,000 addresses, sending within 48 hours, using only the Deliverable or Safe to Send segment, an opt-in list, qualifying nonexistent-address bounces, and a claim within 30 days. It excludes Yahoo and AOL deactivation, sender reputation, content, blocklists, throttling, technical failure, and spam-trap detection.

That is a contractual refund process, not an independently audited accuracy study. The inspected public evidence did not provide a test-set denominator, sampling method, false-positive rate, or provider-level methodology. Measure classification agreement on the buyer's own fixture.

Do not send a full blind test merely to trigger the guarantee. If bounce confirmation is necessary, use a small, approved, opt-in subset under the guarantee's conditions.

Retention and legal terms need review

DeBounce's data-retention policy says the dashboard retains the latest 200 single checks, real-time API email addresses are not stored, and uploaded lists plus results are deleted seven days after upload or validation, whichever is later. It says personal data is stored in Germany and the EU.

The GDPR page says application servers are in the EU while validation servers operate internationally. A validation region can reportedly be selected on request.

The dedicated seven-day policy conflicts with the terms, which still say lists are removed one month after upload or validation. Obtain written confirmation of the applicable period, backups, support copies, logs, and regional validation before production upload.

The terms prohibit unsolicited commercial communications, data mining, and email harvesting. A cold-outreach buyer must reconcile its intended use with those restrictions. Technical validation does not create permission to contact.

The inspected public inventory did not provide a DPA, subprocessor list, SOC report, penetration-test scope, encryption specification, or detailed breach-notification commitment. Request these rather than inferring enterprise controls from general security language.

Run a blind 100-row acceptance test

Build a controlled fixture with current deliverable mailboxes, invalid and malformed addresses, disposable and role accounts, catch-all domains, temporary unknown cases, duplicates inside one file, and addresses repeated in a later job.

Run the fixture through dashboard bulk and API routes. For each immutable ID, record raw code, result, reason, flags, timestamps, balance before and after, optional-check charges, original-column survival, export mapping, latency, retries, and final accept, hold, or reject status.

Pass only if:

1. Dashboard and API classifications agree within the buyer's preset tolerance.
2. Exact duplicates inside the file do not consume credits.
3. Repeated-job charging matches the written quote.
4. Original columns and immutable IDs survive every export.
5. Unknown and catch-all handling follows the buyer's routing policy.
6. Balance changes match baseline, catch-all, enrichment, and photo rules.
7. Rate-limit retries do not create duplicate charges or records.
8. The buyer verifies file deletion on the agreed schedule.

Report false positives and false negatives separately. Also report credits per submitted address, returned result, and accepted CRM record. A low unit price is useful only when the final acceptance denominator remains strong.

Who should shortlist DeBounce?

Shortlist DeBounce when the team wants non-expiring pay-as-you-go credits, needs both dashboard and API routes, and can own a status-routing policy. Its published entry price and raw result fields make a controlled test inexpensive.

Hold when the buyer requires a public DPA, assurance report, subprocessor inventory, or one unambiguous retention term before uploading contact data. Pass when the intended use conflicts with the vendor's communications restrictions or when nobody can separate technical deliverability from consent and identity.

Want to validate contacts without polluting the CRM?

We can build the blind fixture, define status rules, and stage DeBounce results before only accepted records enter a client-owned outbound system.

Book your free discovery call →