Collect candidate emails
Export or stream candidate emails from the outbound source system.
All workflows
GTM workflow guide
Outbound list QA API workflow
Workflow guide for validating outbound email lists through the public Email Validation API and preserving canonical validation statuses before campaign launch.
Auth
X-API-Key header
Setup
moderate · Depends on the source system and QA rules
Workflow type
workflow
Workflow steps
- Collect candidate emails from the outbound source system
- Validate each email through the public Email Validation API
- Persist canonical validation status and quality signals
- Route leads by documented result semantics
- Reconcile reserved, consumed, and refunded credits
Why this workflow fits
- Uses the canonical public API base URL and X-API-Key authentication
- Preserves canonical validation statuses in downstream systems
- Treats unknown outcomes according to the documented uncertainty charge policy
Setup sequence
Validate through the public API
Call the public validation endpoint or the approved bulk workflow 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"}'Persist canonical status fields
Store valid, valid_role_based, risky, invalid, and unknown without collapsing them into local aliases.
Route leads and reconcile credits
Use role-based, catch-all, and B2B quality fields to drive QA rules, and use credits_reserved, credits_consumed, and credits_refunded for cost reporting.
Pre-send QA for outbound lists
Validate lists before exporting them into a sending platform so each row carries a canonical validation status.
Status-aware lead routing
Route valid personal emails differently from role-based, catch-all, invalid, risky, and unknown outcomes.
Credit reconciliation
Reconcile reserved, consumed, and refunded credits so list QA cost reporting matches actual charged outcomes.
Common questions
Does validation guarantee inbox placement?
No. Validation provides result semantics and quality signals; it should not be described as an inbox-placement guarantee.
Which statuses should an outbound QA workflow keep?
Keep valid, valid_role_based, risky, invalid, and unknown as distinct statuses so routing rules stay aligned with the public validation contract.
Should QA workflows use website-internal routes?
No. Use the public API base URL with X-API-Key authentication instead of website-internal /api routes.