Use case
ContactCTL for email verification
One command answers “can I send to this?” — sub-second, 0.02 credits per address, single or batch, with a status and confidence score your agent can act on.
01 — The problem
Bounce rate is the loudest signal you send
Mailbox providers do not read your copy. They read your bounce rate, and they read it fast. A few percent of dead addresses in one campaign is enough to push the rest of your mail toward spam — including the transactional mail you actually care about.
Lists decay continuously, so verification has to happen at send time, not at import time. That only works if checking is cheap and scriptable. ContactCTL runs free local syntax and MX checks first, then full deliverability verification — and it is built to sit inside a script, a cron job, or an agent loop.
At 0.02 credits per verification, checking a 5,000-row list costs 100 credits. Skipping the check costs a sending domain.
02 — The workflow
How it runs
Single check, then the whole list
Verify one address and read the verdict, or pass a CSV and get every row back annotated — verify batch defaults to stdout, so it pipes.
In a script
With --json the verdict is machine-readable, so a guard clause is one line. Single-mode verify also exits on its verdict — 0 deliverable, 2 undeliverable, 3 risky — so a bare ctc verify "$EMAIL" && queue_send "$EMAIL" chain works without jq.
if ctc verify "$EMAIL" --json | jq -e '.status == "deliverable"' >/dev/null; then queue_send "$EMAIL" fi
03 — Commands and credits
What this workflow uses
Every command reports its credit cost in the output. Preview any spend with --estimate at zero cost.
| Command | Purpose | Credits |
|---|---|---|
| ctc verify <email> | Single deliverability check | 0.02 credits per verification |
| ctc verify <file.csv> [out.csv] | Batch verify, stdout by default | 0.02 credits per row |
Full datasheet: credit costs in the docs · plan pricing on /pricing
Next