Waterfall enrichment, explained by what it costs: which provider calls first, and why the order is the whole game

A waterfall is one rule: try the cheapest provider that might have the answer, stop as soon as one answers, and only pay the expensive one for the rows nobody else could find. That is it. The entire industry around the word exists because running that rule reliably, across several APIs, per row, with a record of who found what, is genuinely tedious. Clay is the tool that made it visual, and the order you put your providers in matters more than which tool you use to run them.

Why order beats price

Take a thousand rows and two providers, one at ten cents a hit with a fifty percent hit rate, one at thirty cents with eighty percent. Cheapest first: five hundred hits for fifty dollars, then the expensive one meets five hundred rows and finds four hundred of them for a hundred and twenty. Nine hundred contacts, a hundred and seventy dollars. Expensive first: eight hundred hits for two hundred and forty dollars before the cheap one has seen anything. The same providers, the same data, forty percent more spent.

That arithmetic only holds when providers bill on results. Some bill per row queried whether or not they find anything, and those belong at the end of the chain or nowhere in it. Reading the billing model is not administrative detail, it decides the position of a provider in the order.

What Clay is actually for

Designing the chain. Each column is a provider, a model or your own API, the conditions are visible, and a row that fails one step falls to the next. You can watch which provider is earning its place and which one never fires, on real data, before committing to a contract with any of them.

Their free plan is unusually honest about this: unlimited seats and tables, waterfalls included, two hundred rows per table, a hundred data credits and five hundred actions a month. Two hundred rows is enough to see the shape of your hit rates. If a provider finds nothing on two hundred rows of your market, it will find nothing on twenty thousand.

Where it stops being the right tool

At stable volume. Once the chain stops changing, you are paying for flexibility you no longer use, on two meters, data credits and actions, that run out at different speeds. Launch at 185 dollars a month carries 2,500 data credits and 15,000 actions, Growth at 495 carries 6,000 and 40,000. A script calling the same three APIs directly does the identical work for the cost of the calls.

The honest sequence is: design in the visual tool, prove the order on real rows, then decide whether the volume justifies rebuilding the chain in code. Plenty of teams never reach that threshold and should stay where they are. The ones running hundreds of thousands of rows a month all cross it.

The two numbers to track

Cost per usable contact, not cost per credit. And hit rate per provider on your market, not on their marketing page. A provider with excellent coverage in the United States and almost none in Europe is a good tool and a terrible first step, if your market is European. Measure it on your own rows: two hundred of them is enough.

And measure on fresh rows. A provider that already answered for a contact in this session may not bill you again for it, which quietly makes your test look three times cheaper than production will be. That is a real mistake we made, and it turned a forecast of forty credits a number into a hundred and twenty.

What nobody tells you about the last step

The chain does not end with finding. It ends with verifying. At a tenth of a credit per check on some providers, verification costs less than one bounce, and a bounce damages the sending domain that every future campaign depends on. Put the verifier at the end, run it on everything, and treat it as part of the enrichment cost rather than as an optional extra.