Find, Verify, Send: Where Verification Goes After a Clay Email Waterfall

Put one verification column after the last email finder in your Clay waterfall, and only run it on rows that have an email. Then route on action: send goes to the sequencer, everything else gets its own handling. The column is Clay's HTTP API enrichment calling SimpleVerifier with your own key. It is not a native Clay action. The Clay integration page has the request.

The order

1. Find. Company and person columns, then the finder providers in your preferred order.
2. Stop at the first address. Each provider after the first costs something, so exit early.
3. Verify. One HTTP API column on the final address.
4. Route. Valid onward, the rest into lanes.
5. Send or export. Conditioned on the result.

The reasoning is in enrich, then verify. A result computed on one provider's guess is thrown away when a later step supplies a different address.

Step 1: add the run condition

Run the column only if the email column is not empty. Rows where every provider found nothing then make no API call. The full column build, including the rate limit, is in how to verify emails in Clay.

Step 2: route by action

action	Meaning	Next step
send	Mailbox exists	Push or export
send_with_care	Accepts all addresses, role inbox	Side campaign
retry_later	Server did not confirm	Re-run the column later
do_not_send	Mailbox not found, disposable	Try the next finder

Step 3: retry only the failures

For rows with action do_not_send, run a second finder with the run condition action is do_not_send. Then verify its answer with a second copy of the HTTP API column. Each address is checked once, and a dead address is replaced rather than sent. Our post on catch-all rows covers the send_with_care lane.

Step 4: keep the check date

Add a column holding the date the verification ran. When the table is reused weeks later, anyone can see how old the result is. SimpleVerifier returns confirmed results from the last 14 days from cache, so re-running a recently checked table is quick.

What the order cannot fix

• A confirmed mailbox is not a confirmed buyer. The finder's person match is a separate question.
• Verifying early and not again leaves a stale result by send day.
• Servers that do not answer produce retry_later, not a guess.
• A second finder can return another bad address, which is why its result is verified too.

Next step

One call per row runs on your plan's API allowance. See pricing for the included calls and the API docs for the full response.