Waterfall enrichment: stop buying the same uncertain email twice

Waterfall enrichment means trying another data provider when the current result does not meet an acceptance rule. It does not mean asking every provider for every person, or accepting the first address-shaped string that comes back.

For work email, the hard part is the stop rule. A found address, an identity match and a mailbox verification are related but different pieces of evidence. If the pipeline collapses them into one boolean, adding providers can increase cost without improving the list.

Define the state before choosing the vendor order

Use explicit states such as not_found, found_unchecked, accepted, ambiguous, suppressed and provider_error. Keep a provider's original response alongside your normalized decision.

provider_error must not become not_found. A timeout tells you nothing about coverage. A processing restriction or opt-out is not a reason to try another supplier for the same person.

These are application decisions. They are not a translation table in which every provider's similarly named status means the same thing.

Use a real finder and a real verification contract

Hunter's API exposes Email Finder and Email Verifier separately. Finder can include verification information, so inspect its freshness and semantics before paying for a second check. The verifier may return an in-progress response; a bounded poll is different from repeatedly creating a new lookup.

Findymail's documentation provides another integration candidate. Confirm the operation, required identity fields, billing unit and account access before adding it to the waterfall. Provider order should come from coverage on your permitted sample, not a universal "cheapest first" assumption.

If you add ZeroBounce, preserve its detailed result and sub-status rather than reducing every non-invalid response to a pass. The email validation study explains the test categories and observed outcomes in our separate validation work.

Cache the question, not only the answer

A cache key should include the normalized professional identity, employer/domain context, provider and operation. The same name at a different employer is a different question.

Store when the lookup ran and when the evidence was last observed, where available. Those dates are not interchangeable. Avoid reusing a result indefinitely just because it was accepted once. Retention must also fit the provider agreement and your processing policy.

Do not place names, addresses or API keys in public artifact filenames or analytics events. Detailed traces belong in access-controlled storage with a retention policy.

Build the stopping behavior first

for each permitted professional identity:
    if suppressed: stop
    for each approved finder:
        if budget exhausted: return unresolved
        read cached evidence if still usable
        otherwise request the finder and record usage
        if a processing restriction appears: stop
        if identity conflicts: return review
        if no result: continue
        inspect existing verification; verify if needed and permitted
        if acceptance rule passes: return accepted
        if ambiguous: return review
    return unresolved

This deliberately stops on ambiguity. A business can choose a different policy for an accept-all domain, but that policy should be explicit and reviewed. Calling more tools is not a way to manufacture consent or certainty.

Price accepted records, not HTTP success

For an illustrative budget, suppose a finder costs one unit per found address and a verifier costs half a unit per check. Those are example units, not a quoted plan. Count repeat lookups, unsuccessful paid requests and verification work before dividing spend by accepted records.

The useful measurements are incremental accepted contacts from each additional provider, cost per accepted contact and the number of records still unresolved. A second finder that repeats the first result adds little coverage even if its endpoint always returns HTTP 200.

Also audit mistakes: wrong employers, stale roles and confident results for the wrong person. A pipeline can have a high find rate and still be bad at the job.

A prompt for the first implementation

Implement the approved two-provider email enrichment waterfall.
Use server-side credentials, a hard attempt budget and bounded timeouts.
Preserve original provider verdicts and timestamps.
Stop on suppression, processing restrictions or identity conflicts.
Do not classify accept-all or unknown as accepted automatically.
Do not send email. Export accepted, review and unresolved records separately.
Include per-provider usage and incremental accepted coverage.

For the surrounding company and person checks, use the outreach pipeline guide. The waterfall is a fallback mechanism inside that system, not proof that the final contact should receive a message.