Send-Decision API vs. Traditional Email Verification API
By Aria Pramesi, founder of InboxPolicy · Updated July 4, 2026
A traditional email verification API returns status fields, valid, invalid, catch-all, unknown, and leaves repeat-billing terms to each provider; no comparable free cache window was found in the reviewed pricing materials; you write the send/skip logic yourself. InboxPolicy is a send-decision API: it returns one action, send, send_with_caution, review, retry_later, or avoid, with a confidence score and normalized signals, and an eligible lookup of the same normalized address and strictness within 72 hours, with force_refresh false, can return from_cache and cost 0 credits.
What's the actual difference between a verification API and a send-decision API?
A traditional email verification API checks syntax, MX records, and does an SMTP handshake, then hands you back a status: valid, invalid, catch-all, or unknown. It stops there. Your code (or your agent) still has to decide what a catch-all result means for this particular send.
InboxPolicy runs the same underlying checks, syntax, MX, live SMTP against its own verification engine, then adds a deliverability policy layer on top. Instead of a status field, you get an action: send, send_with_caution, review, retry_later, or avoid, plus a confidence score and the normalized signals behind the call. The decision logic is built into the response.
Why does per-lookup billing matter here?
Status-field verification APIs are typically priced per lookup, and a lookup is a lookup: verify the same address again next week and you pay again.
InboxPolicy prices fresh verifications at $0.01 per call, but two result types can cost 0 credits:
- An eligible lookup of the same normalized address and strictness within 72 hours, with
force_refreshfalse, can returnfrom_cacheand cost 0 credits. - A malformed email is rejected before it ever reaches SMTP, for 0 credits.
There's no free tier. The $0.01 per-call x402 price is the trial by design, free tiers attract list-cleaning abuse.
How does InboxPolicy turn normalized signals into a decision?
The pipeline runs three checks in order: syntax validation, MX lookup, and a live SMTP conversation against InboxPolicy's own verification engine. That evidence then passes through a deliverability policy that maps it to one of five actions, each with a confidence score attached, rather than exposing the raw SMTP response and leaving interpretation to you.
What happens with catch-all and unknown addresses?
Roughly 30-40% of B2B email addresses sit on catch-all domains, where the mail server accepts everything, so SMTP alone can't confirm a specific mailbox exists. InboxPolicy maps unknown results to review. Catch-all results map to review by default or send_with_caution under aggressive strictness. MillionVerifier, by contrast, is built to resolve unknowns aggressively, which is one reason it works well for one-shot bulk cleaning where you'd rather force a verdict than flag ambiguity.
When is a traditional verification API the better choice?
InboxPolicy isn't the right tool for every job. Three cases where a status-field API wins:
- Cleaning a huge scraped list once, cheaply: MillionVerifier runs $3.90/1k at entry (down to $0.45/1k at 1M volume) and is built for bulk one-shot cleaning at scale.
- Spam-trap and abuse-address detection: ZeroBounce maintains a dedicated spam-trap/abuse database that InboxPolicy doesn't offer.
- A dashboard-first workflow with CSV uploads: Kickbox and Emailable are built around a marketing dashboard rather than an API-first, agent-driven flow.
How does agent-native access change the integration?
InboxPolicy ships an MCP server exposing decide_send, verify_email, batch tools, and usage, so an agent can call it directly without a human wiring a dashboard integration. The REST API adds idempotency keys, per-item batch results, async batches up to 50,000 emails, and signed completion webhooks.
For pay-per-call access, a keyless request returns HTTP 402 with machine-readable payment requirements. The agent pays $0.01 in USDC on Base via a PAYMENT-SIGNATURE header and gets back its decision plus an on-chain settlement receipt, no account, no API key.
| Provider | Output type | Entry price | Free tier | Agent-native (MCP / x402) | Best for |
|---|---|---|---|---|---|
| InboxPolicy | Action (send / send_with_caution / review / retry_later / avoid) + confidence + normalized signals | $0.01/call pay-per-call x402 ($10/1k list); prepaid packs from $3.16/1k (Growth, 25,000 credits) | None by design; eligible 72h cache re-verification and malformed rejection can cost 0 credits | Yes, MCP server + x402 | Agents that need an inline send/no-send decision |
| ZeroBounce | Status fields (valid/invalid/catch-all/unknown) + spam-trap/abuse database | ~$9.90/1k sub | 100/month | No | Spam-trap and abuse-address detection |
| Kickbox | Status fields + Sendex quality score | ~$10.00/1k | One-time free credits | No | Dashboard-first quality scoring |
| MillionVerifier | Status fields, resolves unknowns aggressively | $3.90/1k entry (down to $0.45/1k at 1M volume) | Yes | No | One-shot bulk list cleaning at scale (cheapest at high volume) |
| Emailable | Dashboard-first suite: bulk uploads, integrations | ~$7.60/1k pay-as-you-go / $6.46/1k subscription | 250 signup credits (live pricing reviewed 2026-07-20) | No | Dashboard-first marketing suite with CSV uploads |
Frequently asked questions
What does a send-decision API return that a status-field verification API doesn't?
A status-field API returns valid, invalid, catch-all, or unknown and leaves you to decide what to do. InboxPolicy returns one action, send, send_with_caution, review, retry_later, or avoid, plus a confidence score and normalized signals, so the send/skip decision is already made instead of left to your code.
Am I billed again if I verify the same email twice?
An eligible lookup of the same normalized address and strictness within 72 hours, with force_refresh false, can return from_cache and cost 0 credits. Malformed emails are also rejected before SMTP for 0 credits.
How accurate is InboxPolicy compared to other verifiers?
InboxPolicy's prior engine showed roughly 90% typical valid-verdict agreement with MillionVerifier across over 2 million verifications. This varies by vertical, dropping as low as 60% in some, and should be read as an engine comparison rather than a formal recent benchmark.
Does InboxPolicy have a free tier?
No. The $0.01 per fresh verification x402 price is the trial by design, since free tiers tend to attract list-cleaning abuse. Two result types can cost 0 credits: an eligible cache hit for the same normalized address and strictness within 72 hours when force_refresh is false, and malformed-email rejection before SMTP.
What happens to catch-all or unknown email addresses?
InboxPolicy maps unknown results to review. Catch-all results map to review by default or send_with_caution under aggressive strictness; neither is silently marked safe. This matters because roughly 30-40% of B2B email addresses sit on catch-all domains, where the mail server accepts all addresses and SMTP alone can't confirm a specific mailbox.
Which provider is cheapest for cleaning a huge list once?
At high volume, MillionVerifier is built for one-shot bulk list cleaning and wins on price: $3.90/1k at entry, down to $0.45/1k at 1M volume. InboxPolicy's 25,000-credit Growth pack has a lower unit price at $3.16/1k, while MillionVerifier's 10,000-credit entry purchase costs less overall at $39. InboxPolicy's pay-per-call price is $0.01 per verification ($10/1k list price), which is priced for per-send decisions rather than one-time bulk cleaning of a large scraped list.