One call per signup. Cluster bot waves, score risk, and confirm the mailbox actually receives mail — always together, in the same request.
Every /v1/emails call runs the full stack: near-duplicate clustering + a dozen structural heuristics for anomaly detection, then an authoritative mailbox-level check (deliverable / invalid / disposable / spamtrap). One response carries the risk score, cluster id, action band, reasons, and verification status. Bot waves surface as clusters minutes after they start, dead mailboxes get caught before they bounce, and spamtraps get force-declined so they can't tank your sender reputation.
Near-duplicate clustering groups look-alike addresses as they arrive, even when each one looks plausible in isolation (e.g. jane.smith42@gmail.com, jane.smith43@gmail.com, …). The cluster id rides on every record so your downstream systems can act per-wave, not per-address.
0–100 risk score with a structured `reasons` array so you can branch on specific signals (spamtrap-shaped, low engagement, high digit ratio, disposable domain, …). Score → action ladder is `allow / verify / review / decline`, configurable per workspace.
Every screening also runs the mailbox-level check that answers `does this address actually receive mail`. Four-state result: `deliverable / invalid / disposable / spamtrap` (plus `unknown` for the rare grey-zone case). Spamtrap detection is called out separately from `deliverable` so your code can hard-block the addresses that would poison your sender reputation.
Because detection + verification are one action, there's nothing to configure per request. No `verify: true|false` decisions, no partial-response ambiguity, no separate quotas to track. You send an address, you get back the full risk + deliverability picture, you spend the combined credit weight from your wallet.
Follow one member of a bot wave — jdoe83917@acme.co — through the real pipeline, from canonicalization to the disposition your systems act on.
Every address is lowercased, its +tag stripped, and Gmail dots folded — so a pile of disguised aliases collapses to a single canonical mailbox key. That key is what everything downstream dedupes on.
From just the local-part we pull a few structural signals — length, digit ratio, the letters-only skeleton, repeated-character runs. Machine-minted handles look measurably different from human ones.
Handles are bucketed by their first letters, then compared by edit distance against recent sign-ups in your list. Lookalikes join a cluster — and exact same-mailbox aliases are caught outright. The bigger the cluster, the higher the risk.
In parallel, a deliverability check runs: MX / DNS and disposable-domain matching built-in, or a paid provider for authoritative mailbox, spamtrap, role and no-reply signals. Verdicts cache per mailbox for 7 days.
Each signal adds points to a 0–100 risk score, which maps to allow, verify or review. Reasons ship as plain buckets, never the raw rules — so bot operators can't reverse-engineer the scoring.
Action and verdict combine into a disposition — accepted, pending or declined (a spamtrap always declines). It all comes back in one EmailResult, and emails.scored fires so your systems react in real time.
Every billable action draws from one credit pool — no per-feature slider to manage. The cost for this feature is fixed by the platform's credit table; mix and match against the other features however you like.
Pro plans grant 30,000–300,000 credits per month — pick a tier on the pricing page, or top up mid-month with a credit pack.
| Action | Credits |
|---|---|
Bot Anomaly Detection + Email Verification per signup screening — always coupled | 5 |
Domain Health per domain | 1 |
Blacklist check per domain | 15 |
Inbox placement test per test | 150 |
Phone verification per lookup | 3 |
A mix of structural, behavioural, and mailbox-authority signals: digit-to-letter ratio, stem density / repeated padding, near-duplicate clustering against the recent fleet, disposable-domain match, MX validity, suspected spamtrap shape, and the authoritative mailbox verification result. Each contributing signal lands in the `reasons` array so you can branch deterministically — no opaque ML scores.
No — the two layers are one product. Every /v1/emails call runs the full stack (near-duplicate clustering + structural risk scoring + authoritative mailbox check) and charges the combined credit weight from your wallet. There is no verify=false / anomaly-only mode; every response carries the mailbox-verification fields alongside the score.
Single-address screening is sub-300ms p95 on cache hits, sub-800ms p95 on cache misses (which include the mailbox check). Bulk jobs of up to 25,000 addresses stream progress via webhooks; large lists complete in seconds-per-thousand.
Each screening consumes the combined detection + verification credit weight from your monthly wallet — the exact per-action cost is shown in the per-action cost table on the pricing page (live from the platform credit table). The weight is set so a normal signup funnel sits comfortably inside an entry Pro tier; credit packs cover the overflow if traffic spikes.
30 days for the mailbox-verification result. Repeat lookups of the same address within the TTL don't re-hit the verifier — the cached result flows through. The anomaly + clustering side always runs live, since the whole point is to catch waves as they arrive.
The API degrades to detection-only with `verifierSkippedReason: 'provider_down'` on the response, and only the detection portion of the credit weight is charged — you don't pay for what didn't run. Automation resumes as soon as the verifier is healthy again.
Only if you care about the sender-side story. Detection + verification answers "is this address safe to accept". Domain Health answers "is this sender safe to trust" — SPF / DKIM / DMARC / MX posture on the sending domain. Different questions; pair them if your funnel has both sides (B2B outreach with reply tracking is the classic case).
Spin up a workspace, plug in your data, see results — no card required to start.