Waterfall Enrichment: How to Get More Usable Contact Data

Last updated: 13 October 2026.

A waterfall needs a stopping rule

Suppose you know a prospect's name, current employer and company domain but lack a work email. Provider A returns nothing. Provider B returns an address. A validator checks it, and your workflow confirms that the address belongs to the intended person at the intended company. The record can now leave the search stage.

The critical phrase is “meets the acceptance rule.” Stopping at the first nonempty string is different from stopping at a validated, correctly matched work email. A deliverable address for the wrong employee does not solve your problem.

A useful waterfall distinguishes these states: not attempted, pending, no result, candidate returned, accepted, rejected and held for review. A timeout belongs in an operational error state. It should not silently become “no email exists.”

Apply that design to each data type separately. Finding a company domain, a work email and a mobile number involves different identity checks, costs and permitted uses. Do not spend on phone enrichment when the workflow only needs an email.

Open full diagram

Clean the input before buying more data

First remove duplicates, suppressed records and contacts outside the intended audience. Then reuse existing information that is sufficiently current and trustworthy. Enrichment should repair a defined gap, not repurchase the database each time a campaign runs.

Resolve the company before searching for the person. A brand name, parent company and local subsidiary may use different domains. A person who has changed jobs can still have a valid address at a former employer. Treat identity matching and mailbox validation as separate checks.

Keep the input evidence: the contact identifier, employer, domain, role and the date or source supporting that relationship. When matching is uncertain, improve the input or hold the record. Calling five providers with the same incorrect domain is unlikely to make the result more useful.

If your CRM has conflicting records and no dependable company relationships, fix those first. The CRM data hygiene guide explains how to protect authoritative fields and resolve duplication before adding more enrichment.

Order providers by marginal value on your audience

A provider's overall database size does not tell you how well it covers your target segment. Measure accepted results on a representative sample, including the countries, company sizes and roles that matter to the actual workflow.

Record requests, returned candidates, accepted unique contacts, rejection reasons, elapsed time and total cost. Keep validation and platform charges alongside provider charges. A cheap lookup with few acceptable results can cost more per usable contact than a higher-priced source.

The second provider should be evaluated on the records the first provider leaves unresolved. Its standalone success rate on the original list is not its marginal contribution to the waterfall. Providers can share underlying data, so buying more sources does not create independent evidence automatically.

To compare provider order, use matched or randomized representative samples with the same acceptance policy. A source tested only on the hardest remaining records should not be declared worse than one tested on everyone. Do not describe ten configuration test rows as a reliable market benchmark.

An initially useful rule is to place a low-cost, high-acceptance source early, then add sources that contribute distinct coverage. Revisit the order when the audience, vendor quality or commercial terms change. There is no universal sequence that is best for every geography and role. If you are choosing the initial data subscription, the Apollo versus ZoomInfo comparison provides a common coverage test and separates data access from sales execution.

Calculate the cost of additional accepted records

The following is an original hypothetical example, not pricing or performance from any vendor. Start with 1,000 eligible contacts that all need a work email. Assume providers charge for each returned candidate, validation costs $0.01 per candidate, and other platform costs are excluded.

Provider A receives 1,000 requests. It returns 600 candidates at $0.06 each; 540 pass the acceptance policy. Data costs $36 and validation costs $6, for $42 total. Cost per accepted contact is about $0.08.

Provider B receives the 460 unresolved contacts. It returns 230 candidates at $0.15 each; 184 are accepted. Data costs $34.50 and validation costs $2.30, for $36.80 total. Its marginal cost per accepted contact is $0.20.

Provider C receives the remaining 276 contacts. It returns 90 candidates at $0.30 each; 45 are accepted. Data costs $27 and validation costs $0.90, for $27.90 total. Its marginal cost per accepted contact is $0.62.

The waterfall produces 769 accepted contacts, or 76.9% coverage, at $106.70 in modeled variable cost. The average is about $0.14 per accepted contact. Provider C's contribution costs much more than that average, which is why the marginal number matters when deciding whether to keep it.

The remaining 231 contacts stay unresolved. Do not manufacture addresses to claim complete coverage. Also do not call the 920 returned candidates 920 unique usable contacts: rejected candidates can recur across stages for the same person.

Now add your real platform capacity, failed-request charges where applicable, subscription commitments and operating effort. If you already pay for unused provider capacity, the immediate cash decision may differ from the long-term replacement cost. Show both rather than pretending every credit has the same economic meaning.

The business test comes later. Additional accepted records are valuable only if they belong to relevant people and support useful commercial conversations. Measure downstream outcomes on comparable cohorts, while keeping acquisition quality separate from message quality and sales execution.

How to configure a waterfall in Clay

Clay's waterfall documentation describes prebuilt sequences that can be reordered, extended or disabled. You map the required inputs and can retain the successful provider in the output. Run settings control automatic updates and conditional execution.

Begin with a small segment and explicit run conditions: the required field is missing or stale, identity inputs are sufficient, and the record remains eligible. Inspect intermediate outputs during setup. A clean final column can conceal repeated failures or a provider returning the wrong person.

Clay's Work Email waterfall includes validation settings that define what counts as an acceptable result. “Require validation success” changes whether inconclusive checks can stop the search. Its strategies differ in catch-all tolerance, and a duplicate-result threshold can stop repeated attempts on the same failing address. The optional Infer Email step constructs a candidate before paid providers; that candidate still needs validation.

Choose these settings deliberately. A broader acceptance policy may increase reported coverage because it accepts more uncertainty. That is a policy change, not necessarily an improvement in underlying data.

Budget against Clay's current Actions and Data Credits model. Actions measure platform activity; Data Credits cover marketplace data or AI purchases. Bringing your own provider API key removes the relevant Clay Data Credit charge, but platform Actions and the external provider's bill remain. The billing documentation also notes that some validators are free under current pricing, so do not assume one universal validation rate across plans and integrations.

Clay's credit-conservation guide recommends disabling Auto-run during construction, testing a small batch and looking up existing data before buying it again. Use the first few rows to catch mapping errors, then a larger representative sample to estimate coverage and cost. Enable broader execution only after those checks explain the observed results.

How Apollo's waterfall differs

Apollo's configuration guide keeps Apollo as the first source. Admins configure the additional provider order and optional validation. Native integrations use Apollo credits; API-key connections use the external provider's commercial arrangement. The stopping condition can prioritize a verified result rather than simply any returned value.

Review the team's global configuration before a bulk run. A user accessing contact data may invoke the configured waterfall as part of an ordinary workflow. Document which activities should use additional providers and which should use Apollo alone.

Apollo's waterfall overview explains that several sources can return chargeable data for one contact, and validation can charge repeatedly. It also describes avoiding another call to the same third-party source for the same contact and data type when usable data was returned within 30 days. That is a reuse rule, not a guarantee that the person's employment or mailbox is still current.

For API implementations, check the People Enrichment reference as well. It warns that some waterfall providers can charge per lookup even without finding data. That is more qualified than the Help Center's general description of charging on returned data. Budget from the actual providers and execution path; “all misses are free” is not a safe blanket assumption.

The API also separates an immediate response from completed waterfall results, delivered asynchronously through its supported webhook or polling flow. Treat pending as pending. An initial response without the final email does not establish failure, and retrying the whole enrichment can create unnecessary work.

Verification is evidence, not a sending guarantee

Hunter's verification FAQ distinguishes valid, invalid, accept-all, disposable and unknown results. Accept-all domains do not establish that the particular mailbox exists; unknown can mean the server did not permit a conclusive check. Even a valid result can later bounce because mailbox or sending conditions change.

Keep the provider's raw status alongside your normalized policy result. Do not map every vendor's “verified” label into a single unquestioned truth. Decide which outcomes allow automated progression, which require review and which are rejected.

A practical work-email policy might accept a currently validated result only after person and employer matching passes. It might hold accept-all and unknown results, reject disposable or invalid results, and require a new check after a relevant age limit or job change. Those are operating choices to define for your audience, not universal vendor defaults.

Validation also does not establish consent, relevance or permission to contact someone. Apply your organization's outreach requirements and suppression rules separately. A newly found address must not quietly reintroduce a person who has opted out.

Before sending, check the candidate against current suppression and account state again. Conditions may have changed while enrichment was running. The bulk sender requirements guide covers the separate sending infrastructure and subscription controls; a high enrichment match rate cannot replace them.

Preserve provenance instead of overwriting certainty

Store who returned a value, when you retrieved it, when it was validated and what evidence supports its relationship to the contact. Keep an unknown source-observation date unknown. Fetching an old provider record today does not prove the underlying information was observed today.

This original record illustrates a candidate held for review. It is a proposed internal schema, not a vendor response:

{
  "contact_id": "contact_042",
  "enrichment_run_id": "run_2026_10_13_01",
  "company_domain": "example.com",
  "candidate_email": "mira@example.com",
  "provider": "provider_b",
  "provider_observed_at": null,
  "retrieved_at": "2026-10-13T08:00:00Z",
  "validation_status": "accept_all",
  "validated_at": "2026-10-13T08:01:00Z",
  "acceptance_status": "held",
  "reason": "mailbox_unconfirmed",
  "policy_version": "work_email_v1"
}

Separate the candidate from the authoritative CRM field until the acceptance policy passes. Define which fields may be filled when blank and which require review before replacement. A recently confirmed customer value should not lose to an unqualified enrichment result merely because the API call happened later.

Native CRM features have their own behavior. For example, HubSpot's enrichment documentation distinguishes automatic filling of empty properties from manual enrichment that can overwrite existing values. Do not assume an external integration inherits those protections. Inspect and test the actual writeback mapping.

Use a stable contact identifier for writeback, record the old and new values where appropriate, and make repeated delivery safe. A retried completion message should not create another contact or repeatedly enroll the same person in a campaign.

Prevent the expensive operational failures

Set a maximum search scope: approved providers, a per-record or batch budget, and a stopping point for repeated unusable candidates. If a platform does not offer the exact budget control you need, enforce it in the orchestration or run smaller bounded batches. An email alert after spending is different from a hard limit.

Handle rate limits, timeouts and provider outages as recoverable operational failures with bounded retries. Do not automatically purchase another provider's data because one request is temporarily unavailable. Decide when an alternative source is useful and when waiting is cheaper.

Give each run a stable identifier and keep its attempt history. If a completion arrives after a contact changes company or becomes suppressed, reevaluate the result against current state before writing it. The original request's eligibility is not a permanent authorization for every downstream action.

Monitor cost per accepted record by segment and provider stage, not just total credits. Also monitor wrong-person matches, stale employers, repeated candidates, inconclusive validation and CRM write failures. Those are actionable reasons to improve the workflow.

Refresh data according to its use and likelihood of change. A contact about to enter a relevant outreach workflow may deserve a recent check. A dormant record with no planned use may not justify recurring enrichment. Deletion and suppression processes need to cover downstream copies as well as the CRM.

Decide whether the next provider is worth adding

Add a provider when it contributes enough distinct, accepted records from the audience you actually need, at a marginal cost the business can justify. Keep it out when it mostly repeats existing results, produces uncertain identity matches or increases operating complexity without useful coverage.

For high-value unresolved accounts, a limited manual review may beat another broad enrichment pass. The review can discover that the company is wrong, the role has changed or the account no longer belongs in the target segment. Those findings can be more valuable than an email address.

Before scaling:

If you need this connected to CRM ownership, qualification and outreach workflows, our GTM engineering work can help build the operating rules and integrations. The goal is a trustworthy path from missing information to a useful action, with its cost and failure states visible.