Waterfall enrichment is asking several data vendors for the same field in a fixed order and stopping at the first one that answers. You want a work email for a contact; provider one is queried, and if it returns nothing the request falls through to provider two, then three, until someone returns a result or the list runs out. Clay’s own documentation for its work-email waterfall describes it as cascading across providers in sequence, “stopping as soon as one returns a valid result.” The output is a single column with a much higher fill rate than any one vendor produces alone.
It is not a data provider, and it does not make any provider’s data better. A waterfall is routing logic over vendors you are already paying for — it raises coverage, not accuracy. It is also not deduplication and not verification: the cascade decides who to ask, and it will happily hand you a syntactically fine address at a company that bounces every message. Treating a filled cell as a validated one is the single most expensive mistake in this pattern, and it is the reason a waterfall and a verification step are two different line items.
How the cascade actually runs
Three settings determine whether a waterfall saves money or burns it.
Order. Providers run in the sequence you set, so the cheapest vendor with a decent hit rate on your segment belongs first. Order copied from a template is order tuned to somebody else’s ICP.
The stop condition. The cascade halts on the first acceptable result. What counts as acceptable is configurable — Clay exposes Conservative, Balanced, Aggressive, and Advanced validation strategies for its email waterfall, and a toggle so that the waterfall “only accepts an email if the validation provider explicitly confirms it as valid.” Tighten that and you spend more credits per row; loosen it and you spend fewer credits and more sender reputation.
Entry conditions. Every enrichment platform has a gate that decides which rows even enter the cascade. In Clay it is the “Only run if” formula in run settings. Rows that fail the condition never call a provider, which is the largest single lever on the bill.
A useful diagnostic: if your waterfall keeps calling providers after a result came back, the result is failing the validation gate rather than the lookup. That is a data-quality signal about a provider, not a bug.
Two meters, not one
Enrichment platforms usually bill along two separate axes, and conflating them is how budgets get missed. Clay meters actions — steps your table runs — and data credits, which buy records from its provider marketplace. Checked 2026-08-07, the Free plan includes 500 actions and 100 data credits a month; Launch starts at $167/month for 15,000 actions a month; Growth starts at $446/month for 40,000 actions a month, with annual commitments ranging from 180,000 actions a year at $54/month up to 1.2 million a year at $261/month. Multi-provider waterfalls are available from Launch upward.
The charging rule matters more than the tier. Clay states that “if an enrichment returns no result, you’re not charged Data Credits or Actions,” and that bringing your own provider API keys skips data credits entirely. So a miss is usually free and a hit is not — which inverts the intuition most teams start with. Your bill is driven by how many rows you find data for, not how hard you looked.
What the units actually cost
Published unit prices make the trade-offs concrete. FullEnrich, a dedicated waterfall running 25+ sources, sells its Pro plan at $55/month for 1,000 credits — $0.055 per credit — and prices a work email at 1 credit, a personal email at 3, and a mobile phone number at 10.
Read that price list twice. One mobile number costs the same as ten work emails. A list build that quietly enables phone enrichment on every row is not 10% more expensive than an email-only build; at equal hit rates it is roughly an order of magnitude more expensive per contact reached.
Now put verification next to it. MillionVerifier lists 50,000 email verifications for $89 — $0.00178 each, with credits that never expire and catch-all verification included at no extra cost. Verifying an address costs about 3% of what finding it cost. The step teams skip to save money is the one that is already close to free.
Work an example with your own numbers: 5,000 rows, work email only, at $0.055 per found email. Measure your real hit rate on a 200-row sample first — that single input moves the total more than any provider choice. At a 60% hit rate the enrichment is roughly $165 and verifying the results adds about $5.
Watch-outs, each with a guard
Re-enriching rows you already have. Auto-update on a growing table re-runs the cascade on records that already carry the field. Guard: turn auto-update off while building, gate the column with an “Only run if” condition that requires the field to be empty, and use lookup columns to pull data already sitting in your CRM or another table before paying a provider for it.
Phone credits swallowing the budget. At a 10:1 credit ratio, mobile lookups dominate spend while typically serving a much smaller calling motion. Guard: split phones into a separate waterfall gated to the accounts a human will actually dial this quarter, never the full list.
A filled cell treated as a deliverable one. A found address that has never been verified is a bounce waiting to be attributed to your domain, and bounces cost sending reputation across every sequence you run. Guard: make verification a required column downstream of the waterfall, and write an explicit policy for catch-all results — send, hold, or route to a different channel — before the first campaign, not after.
No ceiling and no programmatic visibility. Clay has no public API endpoint for credit balance; usage lives in the Settings credit-usage dashboard, broken down by table, integration, and period. You cannot alert on a number you cannot query. Guard: assign one owner to check that dashboard weekly, cap the rows any single table may process, and test new configurations on 10 rows before running the column.
Is it worth the credits?
Yes when contact coverage is the binding constraint and the cost of a missing record is high — outbound into a segment where one vendor fills half your list, or an ABM motion where 300 named accounts must be complete. Under those conditions a cascade is the cheapest coverage available, because you only pay the provider that succeeds.
No when your problem is targeting rather than coverage. Enriching a poorly-defined list produces more contacts at a bad-fit account, faster, and the credits are gone either way. Fix the ICP definition first, then enrich. It is also the wrong tool when one provider already covers your segment at 80%+ — pay that vendor directly and skip the orchestration layer.
For where this sits in a wider data program, see data enrichment strategies; for what happens downstream of a bad address, see keeping cold email out of spam. Clay is the common orchestration layer, while Apollo and ZoomInfo are more often single providers inside someone else’s cascade.