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 bills every lookup including repeats; 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 SMTP evidence, and re-verifying the same address within 72 hours costs 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 SMTP evidence 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 three cases are free by design:

• Re-verifying an address within 72 hours returns from_cache and costs 0 credits.
• A malformed email is rejected before it ever reaches SMTP, for 0 credits.
• Retrying with the same idempotency key never bills twice.

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 SMTP evidence 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 or catch-all evidence to the review action rather than guessing it as safe. 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 $0.59-2.50 per 1,000 and is built for bulk one-shot cleaning.
• 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 an X-PAYMENT header and gets back its decision plus an on-chain settlement receipt, no account, no API key.

Frequently asked questions