ZapBounce and Clay
Clay runs enrichment as a waterfall: try provider one, fall through to provider two if it returns nothing, and so on. That produces an address from whichever provider happened to have one.
Which means the confidence behind two addresses in the same column can be completely different, and nothing downstream knows that.
A waterfall produces addresses of mixed provenance in one column
The first provider in a waterfall is usually the most reliable, which is why it is first. By the fourth fallback you are taking whatever is available, and that is often a pattern guess.
In the output column both look identical. A downstream sequence treats the confident answer and the last-resort guess the same way, and the guesses are where the bounces come from.
Clay's own credit model makes this sharper: a waterfall that runs four providers per row costs four times as much as one that stops at the first hit, so the expensive rows are also the least reliable ones.
How the data moves
Put verification at the end of the waterfall
One live check on whatever address the waterfall produced, whichever provider supplied it. That is the step that makes the column mean one thing.
Use an HTTP API column
Clay's HTTP enrichment column calls any API. Point it at the verify endpoint, map the address, and read the verdict back into a column.
Keep the source provider in its own column
Verdict plus provider tells you which provider produces addresses that fail. That is a purchasing decision worth having data for.
Filter the export on the verdict
Only confirmed addresses go to the sending tool. The rest stay in Clay for a different play.
Setting it up
- Add an HTTP API column in Clay pointing at the verify endpoint, with the key in a header.
- Map the waterfall's output address as the request body.
- Read the result and the smtp_code into their own columns.
- Keep a column recording which provider supplied the address.
- Build a view filtered on a valid verdict for export to your sending tool.
- Review the invalid rate per provider after a few thousand rows and adjust the waterfall order.
Clay: common questions
Where in the table should the verification column go?
After the last enrichment step. Verifying an intermediate result wastes a check on an address the waterfall may replace.
Can I verify inside Clay?
Yes, through an HTTP API column. That is the standard way to call any external API from a Clay table.
Does this tell me which provider to drop?
Over a few thousand rows, yes. Invalid rate per provider is exactly the number that decides a waterfall order.
Check a Clay export today
100 free checks a month, no card. Unknown results and duplicates are never billed.