GTM use case · Editorial decision guide
Waterfall email enrichment: stop rules, verification and billing
Use waterfall email enrichment when one provider leaves meaningful gaps in an already qualified contact list. Our recommendation is to define an acceptable result before adding providers: correct person, current employer, permitted use, and a verification state your sending policy accepts. A waterfall should stop on a usable result, not merely a non-empty email cell. This documentation-backed guide explains workflow design and Clay's documented controls; it does not claim tested coverage, costs, or deliverability outcomes.
Reviewed . Based on linked public documentation, not hands-on benchmarking. Recommendations and workflow designs are Cheetah assessments. Features and commercial terms can change.
Decision comparison
On narrow screens, scroll the table horizontally.
| Strategy | Appropriate purpose | Stop and cost considerations |
|---|---|---|
| Single provider | Simple lookup for a well-matched segment | Stop after one response; unresolved contacts remain unresolved[3] |
| Sequential waterfall | Seek additional coverage after accepted-result gaps | Clay cascades sequentially and stops when a valid result is found[1] |
| Infer email first | Test a name-and-domain pattern before paid finders | Inference is free in Clay; validation still costs credits[1] |
| Require validation success | Do not stop on inconclusive verification | Clay requires explicit validator confirmation when enabled[1] |
| Duplicate-result threshold | Providers repeat the same rejected candidate | Clay can terminate repeated failed candidates early[1] |
| Separate catch-all review | Contact identity remains uncertain | Catch-all status does not establish a real monitored mailbox[2] |
Spend lookup effort only on eligible identities
Prepare a contact list with a stable person key, company key, full name, current employer domain, role evidence, and suppression status. Remove known duplicates and contacts who do not belong in the campaign before enrichment. A technically valid email for the wrong employer is not a useful discovery. Do not let a provider result silently redefine the contact's employer because it returned an address at another domain.
Hunter's Clay integration documents a name-and-company-domain input for finding work email. Use that as an input contract, not a guarantee of identity. Names with transliterations, recent employer changes, and companies with multiple domains deserve explicit review. Keep personal addresses out of a work-email workflow unless a separate approved policy allows them. Email discovery answers where a person might be reachable; qualification and lawful use are separate decisions.
[3][2]Model the waterfall as states rather than blank-cell formulas
Our recommended states are eligible, lookup pending, candidate returned, validation pending, accepted, rejected, unresolved, and operational error. A lookup with no match is not the same as an authentication error or timeout. The latter says nothing about whether the next provider has better data. Record a stop reason alongside the output so an operator can distinguish success, exhaustion, policy rejection, and an interrupted run.
Clay's Work Email waterfall cascades providers in sequence and stops when a valid result is found. Its Require validation success control changes whether inconclusive validation can be accepted. That means 'email exists' is an inadequate continuation condition. Define acceptance with both identity and verification criteria, then use the product's available controls to approximate that policy. Keep any mismatch between the business policy and supported stop settings visible rather than burying it in a formula.
[1]Preserve the raw verification result and the policy decision
Clay distinguishes valid, invalid, catch-all, unknown, and role-based addresses. Its documentation explains that catch-all domains accept addresses that may not have a real monitored inbox, while unknown results could not be verified. Keep those categories separate. Do not map everything other than invalid into 'verified'. Also retain validator, checked_at, and the raw response so a future policy change does not require guessing what happened.
In the current waterfall documentation, Clay offers Conservative, Balanced, Aggressive, and Advanced strategies; Balanced explicitly includes catch-alls, and Advanced supports finer configuration. Inspect the actual accepted statuses rather than relying on a reassuring strategy name. Our recommended cold-outbound default is to isolate uncertain and role-based addresses for review, not automatically sequence them. Verification describes a technical observation at a time; it does not establish recipient permission or promise inbox placement.
[2][1]Separate finding, inference and verification in the cost ledger
Clay's Work Email waterfall documentation says you pay credits for the provider that finds a match. The same page says Infer Email is free but its validation step costs credits. Do not compress those statements into 'only accepted emails cost money'. Finding a candidate, verifying it, and accepting it for your campaign are different events. Track provider lookup charges, validation charges, reruns, and any connected-provider usage independently.
Hunter's integration documentation distinguishes a Clay-managed account from connecting your own Hunter API key. Its published integration page includes plan and credit details that should be reconfirmed in the current account before budgeting; this guide does not rely on those quoted prices. Using your own key changes which account supplies the service, not whether usage is automatically free. For every step, record credential source and the meter you expect to pay, then reconcile actual usage after a controlled sample.
[1][3]Order providers by marginal usefulness on your segment
Evaluate each provider on contacts left unresolved by earlier steps. Total coverage on a broad benchmark is less useful than additional acceptable results on your specific employer domains, geography, and role segment. Begin with a small qualified sample and preserve the order used. Our editorial objective is the lowest acceptable total effort per eligible resolved contact, including validation and review, not the largest number of populated cells.
Hypothetical example: provider A accepts 60 of 100 eligible contacts, and provider B accepts 10 of the 40 remaining contacts. B's marginal contribution is 10 accepted results, not a separate percentage to add to A's headline coverage. If validation rejects repeated identical candidates, later searches may add expense without new evidence. These numbers explain accounting logic only; they are not vendor coverage estimates or expected campaign outcomes.
[1][2]Treat repeated candidates and exhausted lookups as terminal outcomes
A longer provider chain is not always a better chain. Clay documents a Threshold for duplicate results setting, disabled at zero, which can stop when the same email repeatedly fails validation. It recommends considering a threshold of two or higher for that pattern. Preserve both the repeated address and rejection reason so the team can distinguish duplicated source data from independent new candidates.
Our recommended stop conditions also include a per-contact spending ceiling, incomplete identity inputs, and unresolved employer conflicts. Those are workflow policies, not claims that every product offers native controls for them. At exhaustion, retain unresolved rather than inventing a likely email or broadening to personal contact data. Unknown verification may justify a later bounded recheck; invalid identity should return to research. Neither deserves an endless scheduled rerun that hides the original failure.
[1][2]Publish a contact package, not an email-only export
The downstream export should carry contact and account identifiers, accepted work email, employer domain, successful provider, validator, raw status, verification time, and acceptance policy version. Clay can output the successful provider name and expose intermediate provider columns. Use those controls when reviewing a sample and preserve enough information to explain why the chain stopped. A clean-looking table is not worth losing the evidence needed to resolve a bad address.
Keep suppression screening at the sending boundary even if it happened earlier. A person can opt out between research and export. Reverify according to elapsed time and address volatility instead of treating a past result as permanent. Maintain separate denominators for eligible contacts, accepted emails, and authorized campaign enrollments. The waterfall is complete when the receiving workflow can make its own safe decision without interpreting an unlabeled address as permission to send.
[1][2]Frequently asked questions
Does a waterfall always stop after the first email is found?
Not necessarily after any non-empty result. Clay's waterfall stops on a result it considers valid, and its validation settings govern acceptance. Enabling Require validation success prevents an inconclusive validator result from being treated as sufficient. Inspect the configured strategy and preserved stop reason.[1]
Is Clay's inferred email completely free?
The inference step itself is documented as free. The same documentation says validation costs Clay credits. If an inferred address passes validation, paid finder steps are not called, but that does not make the entire discovery-and-verification process costless.[1]
Should catch-all addresses enter the same campaign?
Our recommendation is to keep them in a separate review state until identity and risk policy are clear. Clay explains that catch-all acceptance does not guarantee a real mailbox exists. Treating that state as equivalent to a specifically valid address conceals uncertainty from the campaign owner.[2]
How many providers should I add?
Add another only when it resolves enough qualified gaps to justify its actual lookup, validation and review cost. Compare marginal results on the remaining segment, not vendor-wide coverage claims. Stop when your budget or identity policy is exhausted, even if more providers are available.[1][3]
Relevant Systems Lab skills
Inspect permissions, external actions and provider costs before installing. A catalogue link is not an endorsement or proof of compatibility.
- Workflow credit optimization skill
Review provider ordering and the distinction between lookup and validation spend.
- Email verification skill
Design explicit technical acceptance states before exporting contacts.
Sources and research limits
Source notes state the scope of the evidence. No deliverability, revenue or model-quality outcome is established by a vendor documentation page.
- [1] Clay: Work Email waterfallChecked
Retrieved provider sequencing, stop behavior, validation strategies, successful-provider output, duplicate threshold, free inference and paid validation. Vendor testing figures are intentionally not used.
- [2] Clay: Email verification statusesChecked
Retrieved valid, invalid, catch-all, unknown and role-based definitions and time-dependent verification caveat.
- [3] Clay: Hunter integrationChecked
Retrieved name/domain inputs, finder and validator actions, and managed-account versus own-key options. Page contains plan and price language not adopted as a current budget claim.