Verification under enterprise procurement
Enterprise buyers rarely lose a verification deal on price. They lose it on the questionnaire: where the data goes, how long it stays, who can delete it, and what happens when a regulator asks.
Being new cuts both ways here. There is no long incident history to explain, and there is also no long track record to point at. Both facts belong on the table before procurement finds them.
The questions that stall an approval
Retention is usually first. We do not state a fixed window on this page, so get the terms in writing during the review. What you control directly is deletion: DELETE /v1/jobs/{id} removes a job and every address in it once you have downloaded the results.
Erasure is next. Deleting a job with DELETE /v1/jobs/{id} removes the job and every address in it, which covers a request about a list you submitted. Record the job id and the date in your privacy log, because keeping a plaintext list of people who asked to be forgotten would be a strange way to honor the request.
Then the question nobody writes down but everybody wants answered: how are the hard addresses reported. Catch-all domains cannot be resolved by anyone, so they come back labeled catch-all. Pristine spam traps cannot be detected by anyone, so we never claim to remove them. Servers that refuse to answer come back unknown and are never billed. A vendor whose answer to all three is a single accuracy number is telling you how it will answer the next question too.
How the work gets done
The order that matters for enterprise, rather than a generic checklist.
Start with a paid sample, not a trial pool
Run twenty thousand addresses from a real list. The thing to compare across vendors is not the valid count, it is how many came back unresolved, because that is the number each vendor has an incentive to hide.
Agree retention before the pilot, not after
Get the retention terms in writing before the pilot starts, and delete the pilot jobs with DELETE /v1/jobs/{id} when it ends.
Separate keys per environment
Create one API key per environment and give each only the scopes it needs: verification.run, jobs.view, jobs.manage or credits.view. A CI key that cannot manage jobs cannot delete production data.
Wire deletion into the existing DSAR process
Delete the job with DELETE /v1/jobs/{id} and write the job id and date into the privacy log you already keep rather than creating a second one.
The hard cases in enterprise, and how they come back
What it costs
Volume pricing runs to $949 for a million addresses, at $0.00095 each. Credits never expire, which removes the year-end problem of a budgeted balance being written off unused.
Every tier works the same way. Unknown results and duplicates are never billed, and credits do not expire.
Questions we get asked
Do you sign a data processing agreement?
Yes. You are the controller for addresses you upload and we process them on your instruction, which is what the agreement sets out.
Can we run with zero retention?
Yes. Delete the job with DELETE /v1/jobs/{id} as soon as you have downloaded the results. Nothing is re-downloadable afterwards, which is the trade.
Can addresses end up in a URL or an access log?
No. Verification is POST only, so an address travels in the request body and never in a query string. Query strings end up in access logs, proxies and browser history.
How do you compare on accuracy?
Compare coverage and accuracy together, never one alone. Hunter's November 2025 benchmark of 15 verifiers on 3,000 business addresses put the category at 31.2% to 70.0%, while vendors publish 99%. Both are computed honestly and they measure different things. ZapBounce puts coverage on every report, so you see the share of your own list with a definite verdict.
Try it on your own list first
100 free checks a month, no card. Run a sample and read the unresolved count before you decide anything.