Waterfall enrichment, explained by what it costs: which provider calls first, and why the order is the whole game
Every enrichment tool now says waterfall. The word describes an order of operations, and getting that order wrong is the most expensive mistake in prospecting data.
AiAffiliate link. I may earn a commission if you subscribe, at no extra cost to you. Disclosure.
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. A visual orchestration tool makes that rule easy to design, and the order you put your providers in matters more than which tool you use to run it.
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 an orchestration tool is actually for
Designing the chain, not running it forever. 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 watch which provider earns its place and which one never fires, on real data, before committing to a contract with any of them.
Most of them have a free tier that goes far enough for this, usually a couple of hundred rows per table. 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, usually on two separate meters, one for provider calls and one for the steps around them, which run out at different speeds. At a couple of hundred dollars a month, a script calling the same three APIs directly does the identical work for the cost of the calls. We build our own chain for exactly that reason.
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.
The chain ends with verification, not with finding
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.
Where these numbers come from
- Airscale pricing page, credit rates behind a managed waterfall read 18 Sept 2026
- Internal enrichment doctrine and per-provider cost measurements dated 6 Sept 2026
What people still ask
What is waterfall enrichment?
Waterfall enrichment 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. The 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. The order you put your providers in matters more than which tool you use to run the chain.
What order should providers go in a waterfall?
Cheapest first, as long as each provider bills on results. On a thousand rows with one provider at ten cents a hit and another at thirty cents, cheapest first yields nine hundred contacts for a hundred and seventy dollars, while expensive first costs two hundred and forty dollars for eight hundred hits — forty percent more spent for less data. Providers that bill per row queried whether or not they find anything break that arithmetic, so they belong at the end of the chain or nowhere in it.
How many rows do you need to test an enrichment provider?
Two hundred rows is enough to see the shape of your hit rates, and most orchestration tools have a free tier that goes about that far, usually a couple of hundred rows per table. If a provider finds nothing on two hundred rows of your market, it will find nothing on twenty thousand. Run the test on fresh rows, though: a provider that already answered for a contact in the session may not bill you again, which quietly makes the test look three times cheaper than production will be. That is a real mistake, and it once turned a forecast of forty credits a number into a hundred and twenty.
When should you replace an enrichment orchestration tool with a script?
When the chain stops changing and your volume is stable. At a couple of hundred dollars a month, a script calling the same three APIs directly does the identical work for the cost of the calls, while the visual tool keeps billing two separate meters — one for provider calls and one for the steps around them — which run out at different speeds. Teams running hundreds of thousands of rows a month all cross that threshold; plenty of others never do and should stay where they are.
Should email verification be part of the waterfall?
Yes. The chain ends with verifying, not with finding, and at a tenth of a credit per check on some providers, verification costs less than one bounce. 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.