Create a scoped API key
Create a GTMAPIs API key with the email:validate:single scope before wiring the workflow.
All workflows
GTM workflow guide
Clay email validation workflow
Workflow guide for validating Clay-sourced emails through the public Email Validation API before campaign upload.
Auth
X-API-Key header
Setup
moderate · Depends on Clay table and HTTP action setup
Workflow type
workflow
Workflow steps
- Import or build a lead table in Clay
- Send each email to the public Email Validation endpoint
- Persist canonical validation status and quality signals
- Filter or route leads based on documented result semantics
- Use credit fields to reconcile reserved, consumed, and refunded credits
Why this workflow fits
- Uses the canonical public API base URL and X-API-Key authentication
- Preserves validation result semantics for automation
- Avoids claiming an official Clay app or marketplace listing
Setup sequence
Call the public validation endpoint
Send email addresses to POST https://api.gtmapis.com/v1/validate with X-API-Key authentication.
curl -X POST https://api.gtmapis.com/v1/validate \
-H 'Content-Type: application/json' \
-H 'X-API-Key: $GTMAPIS_API_KEY' \
-d '{"email":"person@example.com"}'Store validation fields
Store canonical status and B2B quality fields separately so downstream filters can distinguish valid, valid_role_based, risky, invalid, and unknown results.
Pre-send QA for outbound lists
Validate emails before exporting a Clay table into a sending platform.
Lead routing by validation status
Route valid personal emails differently from role-based, catch-all, invalid, risky, or unknown outcomes.
Common questions
Is this an official Clay app listing?
No. This page describes an API workflow pattern and does not claim an official marketplace listing.
Which endpoint backs this workflow?
The public Email Validation endpoint is POST https://api.gtmapis.com/v1/validate.
Which statuses should the workflow preserve?
Preserve valid, valid_role_based, risky, invalid, and unknown as canonical statuses.