Clay email verification
Validate Clay leads before they reach a campaign
Use Verifly alongside Clay enrichment workflows to check email addresses before they move into outbound tools, CRMs, or spreadsheets. The API gives developers a simple way to automate validation after enrichment.
curl -X GET "https://verifly.email/api/v1/verify?email=lead@example.com" \
-H "Authorization: Bearer vf_your_api_key"Real-time SMTP mailbox checks
Single, batch, and async bulk verification
Disposable, role account, and catch-all detection
Pay-as-you-go credits with no subscription lock-in
Search fit
Built for Clay email verification searches
Use Verifly when you need a simple API, predictable pricing, and clean JSON results before emails hit your product, CRM, or campaign tool.
Where verification fits in a Clay waterfall
Clay's whole model is the enrichment waterfall: a table calls provider after provider until one returns an email for a contact. That's powerful, but it also means the email in a given cell can come from a source that pattern-matches formats rather than confirming a live mailbox. Two rows in the same Clay table can be enriched by two completely different vendors with two completely different confidence levels, and Clay doesn't reconcile that for you.
The clean way to handle this is to treat verification as its own column at the end of the waterfall. After the last enrichment step writes an email into the table, an HTTP API column calls Verifly and writes back a deliverability verdict. Now every downstream action — pushing to a sequencer, syncing to a CRM, or writing to a Google Sheet — can gate on that verdict instead of trusting whichever provider happened to win the waterfall.
Because Verifly is a single REST call that returns clean JSON, it slots into a Clay HTTP API enrichment column without any glue code, and you only spend credits on rows that actually reached the verification step.
How to add a Verifly column to a Clay table
- Build your enrichment waterfall as usual so each row ends up with an email in a column (for example, /Work Email).
- Add a new "HTTP API" enrichment column in Clay.
- Set method GET and URL https://verifly.email/api/v1/verify with a query param email mapped to your email column.
- Add an Authorization header with value Bearer vf_your_api_key.
- Reference result, disposable, role, and catch_all from the JSON response in follow-up formula columns to filter the table.
- Only export or push rows where result equals deliverable into your downstream campaign.
curl -X GET \
"https://verifly.email/api/v1/verify?email={{Work Email}}" \
-H "Authorization: Bearer vf_your_api_key"
# response
# {
# "email": "jordan@acme.io",
# "result": "deliverable",
# "disposable": false,
# "role": false,
# "catch_all": false,
# "smtp": true
# }FAQ
Frequently asked questions
Do I verify inside the Clay table or after export?
Either works, but verifying inside the table as an HTTP API column is cleaner — it lets every downstream Clay action gate on the deliverability verdict instead of exporting rows you'll only throw away later.
Does the waterfall already return verified emails?
Clay returns whatever the winning provider had; confidence varies per provider and isn't a live mailbox check. Adding Verifly as a final column gives every row one consistent, real-time SMTP verdict regardless of which vendor found the email.
How do I filter a Clay table by Verifly's result?
Reference the response fields in a formula or filter column. Keep rows where result is deliverable, and use the disposable, role, and catch_all booleans to drop throwaway or generic addresses.
Will this burn a lot of Clay credits?
No — Verifly is billed separately and pay-as-you-go ($2 down to $0.60 per 1,000). You only spend a Verifly credit on rows that actually reach the verification column, and you start with 100 free credits.
Can an AI agent inside Clay call Verifly?
Verifly exposes an MCP server at verifly.email/mcp, so an agent or Claybook AI step that speaks MCP can verify an address as a tool call rather than a raw HTTP request.
What happens with catch-all domains in my table?
Verifly marks them catch_all: true because the domain accepts all mail and no single mailbox can be proven. You choose whether to keep those rows depending on how strict the campaign needs to be.