Clay waterfall enrichment is usually explained fairly simply as “chain your providers together so you catch more records,” and the advice that follows is almost always to put the highest hit-rate provider first. That advice is backwards. Clay’s own guide says the opposite, for a reason most explanations skip: the first position in a waterfall runs against every single record, and every later position only sees whatever the earlier ones missed, so what belongs first is not the best hit rate, it is the cheapest provider that still clears a trustworthiness bar.
Clay Waterfall Enrichment: The Actual Ordering Rule
Clay’s own guide to waterfall enrichment states the ordering principle directly: “Put the cheapest provider that returns trustworthy data first, since the early levels run on every record and the late levels run on almost none.” That single sentence contradicts the common advice to lead with whichever provider has the highest hit rate, and it does so for a reason worth sitting with: hit rate determines how many records a provider catches, but position in the sequence determines how many records a provider is even asked to look at in the first place.
A provider sitting first sees one hundred percent of the batch, whatever its own hit rate turns out to be. A provider sitting fourth or fifth only sees whatever survived every earlier step’s misses, which is typically a small fraction of the original volume. The practical consequence is that the price of whichever provider occupies the first slot gets multiplied across the largest pool of records in the entire sequence, since that position sees every record and bills on whatever share of them it returns data for. Hit rate is the right criterion for choosing what goes later in the waterfall, where volume is already small and coverage matters more than unit cost. It is the wrong criterion for choosing what goes first.
Why the Billing Mechanic Makes This True
The reason this matters at all is how Clay actually bills a waterfall. The same guide states it plainly: “a contact found by the first provider never touches the second, so you never pay the second’s credit on it.” Clay’s own waterfall enrichment page describes the same mechanic from the user’s side: the sequence “lets you search sequentially across multiple tools until you find a valid match,” with the search simply stopping there. Worth being precise about one exception: per Clay’s own billing FAQ, a step avoids a charge only if it returns nothing at all or the underlying API call errors out; a step that returns a value which then fails validation has already consumed a charge for the return and a separate charge for the validation, and the record still falls through to the next provider regardless. A record can therefore bill more than one provider when an earlier step returns a bad result rather than no result.
There is a second meter alongside Data Credits, and per Clay’s own documentation the two carry different weight: “each Action costs a few tenths of a penny” against “each Data Credit costs a few pennies,” which is why Data Credits are the one worth watching. An Action is consumed once per enrichment or validation event, whichever provider runs it. Data Credits are priced per provider and per data type instead: Clay’s own guide gives an example where “an Infer Email step runs first for free, constructing a likely address from a name and domain before any paid provider is touched,” while an actual provider lookup further down the same chain is priced according to the data type it returns. Validation is a separate metered event that runs after each returned result rather than once at the end of the chain, per Clay’s own billing FAQ; each validation still consumes an Action, though Clay’s current pricing makes select validator providers free of Data Credits. A step run through your own API key with that provider is a further option, spending the Action but no Data Credit.
Put those two facts together and the ordering rule follows directly. Since the chain stops billing once a step returns a valid match, and the first position runs against every record in the batch, minimising total spend starts with the per-record cost of whatever sits first, since that is the slot with the most volume behind it. A provider with a slightly lower hit rate but a meaningfully lower price, placed first, will usually cost less overall than a higher hit-rate provider in the same slot, because the price difference gets multiplied across a much bigger volume than the hit-rate difference saves further down the sequence. The second slot still runs on whatever the first one missed, which can be a third or more of the batch in practice, so it matters too, just less than the first.
The Gap a Waterfall Does Not Close on Its Own
This cost logic comes with an explicit warning attached in Clay’s own guide, and it is the part naive cost-first advice tends to drop: “a cheap source that ships garbage just passes bad records downstream.” A waterfall’s stop-at-first-validated-match structure protects against overspending, since nothing after that match ever runs, but it does not protect against bad data the same way. If the first provider is cheap, high hit rate, and inaccurate, it will confidently catch the majority of records and hand back wrong answers for a meaningful share of them. Validation catches a value that is unusable, not one that is deliverable but simply belongs to the wrong person, so a confidently wrong answer that still looks valid passes straight through: no later provider in the sequence re-checks an answer an earlier one already claimed.
That is why the actual rule is not simply “cheapest first,” it is “cheapest provider that clears a trustworthiness bar, first.” The bar has to be set deliberately, based on what the workflow can tolerate downstream, before cost is allowed to decide between the providers that clear it. Skipping that step and optimising for price alone treats the waterfall’s cost protection as if it were also a quality protection, which it is not.
Setting that bar in practice means picking a specific, checkable threshold before comparing prices, not a vague sense that a provider “seems reliable.” A reasonable approach is to pull a small sample of records the candidate first-position provider has already matched, verify a meaningful share of them by hand or against a second source, and only compare pricing between candidates that clear the same accuracy threshold on that sample. Providers that fail the check get moved further down the sequence, where their lower cost still has value on the smaller remainder of records nothing cheaper caught, rather than being placed where their errors would touch the largest share of the batch.
How Many Providers a Waterfall Should Actually Include
Because a provider only bills when it actually returns something, adding more providers further down a waterfall costs very little on any record that never reaches them. A provider placed fifth runs against only the small remainder that reached it; the large majority of records were already caught by providers one through four and never touch it. That turns “how many providers is too many” from a cost question into a coverage question.
The real limit on adding another provider is whether it meaningfully improves coverage on the shrinking pool of records nothing earlier caught, not whether it adds meaningful cost to the batch as a whole, since that small remainder is exactly where cost stops being the binding constraint and coverage takes over.
Clay’s own worked example illustrates the payoff of getting the ordering right rather than just adding more steps: reordering the same five providers from a premium-first sequence to a cheapest-confident-first sequence, across the same 100 records, held coverage at 94% while dropping the total shown for that arrangement to $39. Coverage is set by which providers are in the chain, not by their order, since every record still falls through to every level it needs. Only the bill moved, because the same providers were arranged so the expensive ones only ever ran against the small remainder nothing cheaper could catch. Those are Clay’s own figures for one five-provider email chain, not a benchmark that transfers to a different field or a different set of providers; what transfers is the direction of the effect, not the specific numbers.
Where Waterfall Sequences Usually Go Wrong
The most common mistake is leaving the confidence threshold, the setting that decides what counts as a found result at each step, at whatever level it defaulted to and never revisiting it per use case. Clay’s own guide is direct that this single setting governs coverage, cost, and quality together: set it strict and more records fall through to the next level, raising both the cost of coverage and final quality, while coverage itself dips a little; set it loose and the chain stops early on shakier data. For cold outreach specifically, the guide recommends setting it strict, since a wrong email is worse than a missing one, but that same strict setting can be needlessly cautious for an internal report where a small error rate is acceptable and coverage matters more. A cheap provider placed first with a threshold left too loose is exactly how a low-quality result ends up passed downstream as if it had been confirmed.
The second common mistake is ordering purely by price without setting a trustworthiness floor first, which is the exact failure Clay’s own guide warns against. A team that reorders for cost savings without checking accuracy on the newly-promoted cheap provider can hit a lower bill and a quietly worse dataset in the same change.
The third common mistake is watching the wrong meter. Data Credits are the scarcer, more expensive resource, priced by provider and data type, while an Action is a fixed cost per event regardless of which provider runs it, so Data Credit consumption is usually where the real budget pressure sits, not the Actions allowance. Provider choice is one lever on that spend, which is what the rest of this article is about, but it is not the only one: the confidence threshold discussed earlier changes it too, since a stricter threshold pushes more records further down the chain, and each additional step that returns a result which fails the threshold is another Data Credit charge, since only a step that returns something bills at all. Routing a specific step through a provider’s own API key is a further lever, spending an Action on that step but no Data Credit.
The fourth common mistake is setting a sequence once and treating it as finished. Provider pricing, coverage, and accuracy all change over time as vendors update their own data sources and pricing tiers, and a sequence optimised correctly six months ago can quietly drift out of the right order without anyone changing the workflow itself. Revisiting the ordering periodically, with a fresh look at which provider currently offers the cheapest trustworthy coverage for the first position, catches that drift before it accumulates into a meaningfully worse cost or accuracy outcome than the sequence was originally built to deliver.
Related Reading
For the strategy layer this kind of enrichment design sits inside, see RevOps Consultancy. For the CRM foundation enriched records ultimately feed into, see HubSpot Consultancy. On the broader discipline of keeping enriched data trustworthy once it lands, Automated Pipeline Hygiene covers the wider practice.
Go deeper: RevOps Automation Maturity Model · n8n vs Zapier for RevOps Automation
Frequently Asked Questions
Does Clay charge credits for every provider in a waterfall, or only the one that finds a match?
Only for lookups that actually return something. A provider that comes back empty costs nothing, and a contact found by the first provider “never touches the second,” so providers below the match never bill. The exception is a step that returns a value which then fails validation, since it has already returned data and is billed, and the record still falls through to the next provider.
Should the highest hit-rate provider always go first in a Clay waterfall?
No. Clay’s own guide recommends the cheapest provider that still meets a trustworthiness bar for the first position, since that position runs against every record in the batch. A high hit-rate provider often costs more, and that extra cost applies to the largest pool of records in the entire sequence.
What’s the risk of putting a cheap provider first in a waterfall sequence?
If the cheap provider is also inaccurate, it will confidently catch most records and pass wrong answers downstream, since validation catches an unusable value but not a deliverable one that simply belongs to the wrong person, and no later provider re-checks a record an earlier one already claimed. Cost should only decide between providers that already clear an accuracy floor.
How many providers should a Clay waterfall actually include?
As many as meaningfully improve coverage on the shrinking pool of records nothing earlier caught, since adding a provider costs almost nothing on records it never has to process. The bigger gain usually comes from correctly ordering the providers already in use, not from adding more of them.