邮箱验证 API
一个端点覆盖所有验证类型。实时邮箱验证 API，含 SMTP 检查、结构化 JSON 响应，以及原生 MCP 与 Agent Skills 集成。
全部验证 API 模式，同一端点
每种验证类型都可通过同一 REST 邮箱验证 API 访问。
单邮箱验证
POST /verify — 一次实时邮箱验证 API 调用，响应低于 3 秒。在一个 JSON 对象中返回状态、可投递性、质量评分和风险标记。
批量验证
POST /verify/bulk — 每次 API 调用同步验证最多 50 个地址。全部结果在同一次 API 响应中返回，schema 与单次验证相同。
异步文件处理
POST /verify/file — 向 API 提交 CSV 或 Excel 文件做后台处理。API 任务完成后通过 webhook 回调交付结果。
官方 SDK
面向该免费邮箱验证 API 的类型安全客户端库，支持 Python、Node.js、Go 和 PHP。失败自动重试、完整错误处理，跨语言响应类型一致。
每次邮箱验证 API 调用包含什么
每一次实时邮箱验证 API 调用都会自动运行相同的多层检查。
验证 API 中的 Webhook 支持
异步接收 API 结果，并查询消息历史。
异步推送
创建 Webhook
注册 HTTP 端点，在任务或批次完成时立即接收 API 结果。该接口支持自定义 payload、失败自动重试，以及按任务或全局配置。
- 任务完成事件附带结果摘要
- 投递失败自动重试
- 按任务或账户级别配置
消息历史
查询消息
访问完整 webhook 事件日志，检索历史 API 结果、调试投递失败或重放错过的通知。API 事件保留 30 天。
- 按任务 ID 或日期范围查询事件
- 重放遗漏或失败的投递
- 30 天事件保留
AI 原生验证 API 集成
无需从零编写验证逻辑，即可将 API 接到所有主流 AI 客户端和 SDK。
响应契约
邮箱验证 API 逐字段返回什么
多数团队接入验证 API，是为了替换正则表达式。只有当 API 响应携带的信息多于它替换掉的布尔值时，这次升级才划算。
status 才是代码应分支的字段
API 返回四种状态之一：deliverable、undeliverable、risky 或 unknown。现实本身就有四种状态，所以才有这四种；任何把它们压成 true 和 false 的验证 API，都会逼调用方自己补上缺失的细微差别。
先按 status 分支。免费邮箱验证 API 响应里的其余字段是在解释该状态，而不是取代它。
score 和风险等级用于排序，不是用于设门槛
0 到 100 的质量评分和风险等级，可以用来给队列排序、优先跟进销售，或按入口调整阈值。它们是派生出的 API 字段，应视为排序提示，而不是接口裁决。
只靠评分设门槛，团队很容易误拒好客户。用 status 做门槛，用 score 做排序。
reason code 让 API 可调试
每个非 deliverable 的 API 答案都带有机器可读原因。语法无效、没有邮件路由、邮箱被拒、服务商延迟，是不同问题、不同修法；我们的免费邮箱验证 API 会分别命名，而不是返回一个笼统失败。
记录 API 的 reason code，不要记散文。它跨版本稳定，几个月后一张关于某个地址的工单才答得出来。
布尔标记描述的是地址本身，不是它的可投递性
一次性邮箱、角色账号、Catch-All 和免费个人 webmail，以彼此独立的 API 标记返回。一个地址完全可投递，同时带上其中三项，完全可能——这正是语法校验器表达不了、而 API 可以表达的情况。
这就是实时邮箱验证 API 和格式检查的实际差别：格式检查告诉你字符串形状正确，API 告诉你这个地址实际是什么。
迁移
从语法校验器迁到真正的验证 API
团队通常带着代码里已有的正则或库调用走到这一步。API 迁移本身很小，但有三个习惯必须一起改。
别再把格式当成答案
正则只能证明字符串可能是地址。这套免费邮箱验证 API 证明的是邮件服务器当前会接收它。客户端用正则做廉价提示可以，但不要再让它决定一条记录好不好。
落到代码里，就是删掉「格式有效因此保存」的分支，改成按 API 的 status 字段分支。
给 API 设超时和回退
接收方服务商慢时，网络调用也会慢。给 API 设一个表单能接受的超时，并事先决定超时后怎么办：通常是接受该地址、标为未验证，稍后用另一次 API 调用再查。
实时邮箱验证 API 绝不该成为注册失败的原因。降级到未验证，而不是拒绝。
把结果存成数据，而不是过滤器
把 API 的 status、reason code、标记和 checked-at 时间戳写到记录上。只存一个清洗后的布尔值，三个活动周期后就解释不了为何抑制，也分不清新鲜的 API 证据和过期的。
存下完整 API 响应，还可以改策略而不必重新验证：事实留着，变的只是读取它们的规则。
认真处理 unknown，而且只定一次
unknown 不是 API 错误，也不是失败。它表示接收方服务商没有给出确定答复。把重试策略定在一处——队列、延迟、最大 API 尝试次数——而不是在代码里到处散落临时重试。
多数 unknown 结果会在后续 API 调用中解消，所以我们的免费邮箱验证 API 如实上报，而不是瞎猜。
集成面
调用邮箱验证 API 的四种方式
一个端点，四种 API 形态。按工作量和延迟来选，不要凭偏好。
- 1
单个地址，同步
POST /verify 接收一个地址，并在 1 到 3 秒内返回完整 JSON。这是注册表单、结账和个人资料编辑使用的实时邮箱验证 API 路径。
因为它是单次 API 调用、没有任务生命周期，也是在做更大集成之前最容易对测的接口。
- 2
一次调用最多 50 个地址
POST /verify/bulk 同步验证最多 50 个地址，并以相同 schema 返回。适合页面或任务每次本来就只处理一小撮记录的场景。
批量上限是硬性 API 边界，不是软限制。更大的载荷会被明确的 API 错误拒绝，并指向文件端点，不会悄悄退化成一次极慢的请求。
- 3
文件，异步
POST /verify/file 接受 CSV 或 Excel，在后台处理，并在 API 任务完成时调用你的 webhook。大文件跑着的时候，不必一直占着连接。
如果工作负载更像名单而不是 API 调用， 批量邮箱验证 会用同一引擎处理上传文件，并提供去重和 CSV 导出。
- 4
从 AI 智能体和 MCP 客户端
MCP Server 用自然语言把同一套邮箱验证 API 暴露给 Claude Desktop 和 Cursor；Agent Skills 则一键装进智能体平台。两者返回的结构化 JSON 与 REST API 完全相同。
这样智能体行为才诚实：工具不能把 unknown 概括成没问题，因为它读到的就是免费邮箱验证 API 的响应。
范围
验证 API 故意留给你的部分
这个 API 故意做窄。下面每一项都是真实需求——只是它们属于你系统的其他位置，而不是验证 API。
同意与抑制
我们的免费邮箱验证 API 能告诉你某个地址收不收信。它不能告诉你对方是否同意接收你的邮件，也不会去读你的抑制名单。
把同意保存在你自己的系统记录里，并在 API 调用之前检查，而不是之后。
身份与在职
一个可投递的公司地址，并不能证明具名的人控制它，或仍在那里工作。别名、共享收件箱和过期的 enrichment，经常会打破这个假设。
身份请用第一方数据。这套免费邮箱验证 API 返回的是邮箱证据，不是关于某个人的证据。
收件箱投放
SMTP 接受是接收方一侧的事实。你的邮件能否进收件箱，取决于发件人声誉、认证、内容和投诉历史，这些 API 都观察不到。
用 API 修好地址质量；投放问题要靠发件人侧的工作和监控，API 替不了你。
时效
每次 API 响应描述的都是调用那一刻。邮箱会关闭、别名会停用、域名会迁移，所以存下来的 API 结果会过期，不管有没有人再读它。
按数据变化速度安排复验周期，并让 checked-at 时间戳自动驱动这个决定。
相关界面
邮箱验证 API 与其他工具如何配合
同一引擎出现在多个 API 界面背后。选哪一个，取决于谁在问、以及涉及多少地址。
同一端点的 verification 表述
邮箱验证 API 为按 verification 而非 validation 搜索的团队记录了同一端点，并对 SMTP 证据做了更深入的说明。
schema、积分和准确率完全相同——不同的只是文档的表述。
查看单个地址的浏览器工具
如果只需要查看单条结果、而不是做任何自动化， 邮箱验证器 会在浏览器中运行同一流水线，并展示 API 会返回的每一项标记。
这是在针对免费邮箱验证 API 写代码之前，确认引擎行为最快的办法。
不做 SMTP 的浅层校验
如果需求真的只是格式和邮件路由， 邮箱校验器 止于语法和 MX，不会消耗一次 SMTP 检查。
用它做廉价预筛，把实时邮箱验证 API 留给退信真的会有成本的那些记录。
邮件检查 API 常见问题
1. 邮箱验证 API 有多快？
缓存的 API 结果在 200ms 内返回。完整 SMTP 验证平均 1–3 秒完成，因此可以把它当作表单里的实时邮箱验证 API。该接口支持每分钟最多 6,000 次单次请求和 1,500 次批量请求。
2. 如何集成邮箱验证 API？
该验证 API 使用标准 REST 调用和 JSON 响应。官方 SDK 支持 Python、Node.js、Go 和 PHP。大多数 API 集成可在 30 分钟内完成。MCP Server 和 Agent Skills 完全无需代码——安装一次，这套免费邮箱验证 API 即可在任何受支持的 AI 客户端中使用。
3. 邮箱验证 API 如何收费？
Starter 套餐 $20 对应 20,000 积分，单价 $0.001 / 封——无月费，按用量付费。量大可降至 $0.00035 / 封（1M 积分档）。免费档每天登录送 20 免费积分，每月最多 600，无需信用卡。
4. 每次验证 API 响应包含什么？
每次 API 响应都包含验证状态（deliverable、undeliverable、risky 或 unknown）、0–100 的质量评分、风险等级和原因码。还包括一次性邮箱标记、角色账号标记、Catch-All 检测以及拼写纠正建议。
5. 验证 API 安全吗？
所有 API 请求均使用 HTTPS。每次 API 调用都需要 API 密钥认证，还可启用 IP 白名单加强安全。BillionVerify 完全符合 GDPR 和 CCPA，处理完成后自动删除数据。
6. AI 智能体和 LLM 如何使用这个验证 API？
AI 智能体可通过 MCP Server（在 Claude 和 Cursor 中用自然语言）、预置 Agent Skills（面向 Claude 和 Manus 一键安装），或从 LangChain、CrewAI 或任意 Anthropic 或 OpenAI SDK 直接发起 REST 调用。每条路径都打到同一套邮箱验证 API，并返回相同的结构化 JSON——无需转换响应。
7. 邮箱校验 API 和邮箱验证 API 有什么区别？
邮箱校验 API 和邮箱验证 API 通常指同一个端点——用来检查地址是否真实且可投递。BillionVerify 做 SMTP 级检查，确认邮箱在接收服务器上存在，而不是只做 DNS 或语法校验。单个 /verify 端点在一次 JSON 响应中返回状态、质量评分、一次性标记、角色账号标记和 Catch-All 检测。
AI 友好的邮箱验证 API
获取 API 密钥
一个端点覆盖所有验证类型。包含 MCP Server 和 Agent Skills。免费档每天登录送 20 积分，每月最多 600，无需信用卡。
无需信用卡 · 原生 MCP Server 集成 · 30 分钟内完成 API 集成
99.9%
准确率
Real-time
API 速度
$0.00014
每封邮件
600/mo
永久免费