邮箱验证 API
通过 HTTP 进行完整 SMTP 邮箱检查的实时邮箱验证 API——面向送达率的准确验证，而非仅格式校验。
全部验证 API 模式，同一端点
每种验证类型都可通过同一 REST 邮箱验证 API 访问。
单封邮箱验证
POST /verify — 一次实时邮箱验证 API 调用，响应时间小于 3 秒。在一个 JSON 对象中返回状态、送达率、质量评分与风险标志。
批量验证
POST /verify/bulk — 每次 API 调用同步验证最多 50 个地址。所有结果在同一 API 响应中返回，模式与实时邮箱验证 API 的单地址调用相同。
异步文件处理
POST /verify/file — 向 API 提交 CSV 或 Excel 文件进行后台处理。API 任务完成后通过 webhook 回调交付结果。
官方 SDK
面向验证 API 的类型安全客户端库，支持 Python、Node.js、Go 与 PHP。失败自动重试、完整错误处理，以及跨语言一致的响应类型。
每次邮箱验证 API 调用包含什么
每次实时邮箱验证 API 调用都会自动运行相同的多层检查。
验证 API 中的 Webhook 支持
异步接收 API 结果并查询消息历史。
异步投递
创建 Webhook
注册 HTTP 端点，在任务或批次完成时立即接收 API 结果。该 API 支持自定义载荷、失败自动重试，以及按任务或全局配置。
- 含结果摘要的任务完成事件
- 投递失败自动重试
- 按任务或账户级配置
消息历史
查询消息
访问完整 webhook 事件日志，以检索历史 API 结果、调试投递失败或重放错过的通知。API 事件保留 30 天。
- 按任务 ID 或日期范围查询事件
- 重放错过或失败的投递
- 30 天事件保留
AI 原生的验证 API 集成
无需从零编写验证逻辑，即可把该 API 接到所有主流 AI 客户端与 SDK。
端点内部
邮箱验证 API 每次调用证明什么
邮箱验证 API 的价值取决于响应字段背后的证据。这个 API 返回的是邮箱级事实，而不是包装成结论的语法判断。
语法与路由只是低成本的基础层，不是最终答案
每次调用邮箱验证 API 都会规范化地址、检查结构，并解析域名的 MX 记录。这两层检查速度快，也不会触达收件人，因此会先执行，在进入 SMTP 阶段前排除明显无效的地址。
只检查语法的 API 到此为止，并将结果判为有效。这正是校验端点与继续检查邮箱本身的免费邮箱验证 API 之间的差别。
SMTP 才是验证 API 名副其实之处
该 API 会与接收服务器建立真实的 SMTP 会话，并测试收件路径。不会发送邮件正文，不会点击确认链接，也不会有任何内容进入对方的收件箱。我们的免费邮箱验证 API 会读取足够的服务器响应信息，以区分收件人被接受还是遭到永久拒绝。
这才使它成为实时邮箱验证 API，而不是附上营销文案的 DNS 查询。证据来自真正会接受或拒绝你邮件的那套系统。
风险标志与状态在同一响应中返回
API 返回的一个 JSON 对象携带送达状态、质量评分、风险等级、原因代码，以及一次性、角色账号、Catch-All 与免费网页邮箱标志。你的应用不需要第二次 API 调用就能知道结果为何如此。
让标志与状态一起返回是有意的设计。能够收信的角色地址和个人邮箱都属于 deliverable，只有你的产品知道哪一种适合当前工作流。
无法确定的结果仍标为不确定
灰名单、服务商延迟响应与速率限制在 API 规模下很常见。免费邮箱验证 API 对这些情况返回 unknown，而不是将其误判为 deliverable 或 invalid。
重试逻辑应写在你的代码里，而不是隐藏在端点内部。静默猜测结果的 API 会抹去你判断应当重试还是转交人工审核所需的关键信号。
响应字段
将每种验证 API 状态映射为应用决策
API 响应可直接用于条件分支。每种状态对应一个操作，API 原因代码则用于解释临界情况。
deliverable — 放行
调用时收件路径接受了探测。可以接受注册、写入联系人，或把邮件入队——仍须遵守你产品自己的同意规则。
免费邮箱验证 API 在免费套餐和付费批量套餐中返回相同的状态字段，因此用免费积分测试的行为与正式上线后的行为一致。
undeliverable — 拒绝或要求重新输入
API 返回永久失败，意味着该地址会产生硬退信。在注册表单中，应结合 API 原因代码提示用户重新输入；在后台任务中，应排除该记录，而不是删除原始值。
永远不要自动纠正域名。验证 API 能告诉你某个地址失败；它不能告诉你对方本意是哪个地址。
risky — 按你的策略处理
risky 表示邮箱可能能够收信，但同时带有你的产品可能关注的风险标志。请查看原因代码：付费注册使用一次性邮箱，与支持表单使用角色地址，是两类完全不同的问题。
只需在调用我们免费邮箱验证 API 的位置定义一次策略，即可让产品中的所有界面以同一方式处理相同的 API 标志。
unknown — 重试，不要丢弃
接收服务商给出的响应无法证明地址状态。应将该地址加入队列，稍后再次调用 API，而不是阻止用户或把假阴性写入数据库。
注册流程中的实时邮箱验证 API 此时应平稳降级：先允许用户继续，再异步验证一次，并根据第二次 API 结果采取相应操作。
集成模式
在真实系统中应在哪里调用邮箱验证 API
多数 API 集成使用同样三个触点。把 API 调用放对位置，比选哪个 SDK 更重要。
- 1
采集地址时
在地址提交时调用 API——无论是注册、结账、线索表单还是个人资料更新。用户仍停留在页面时验证，是让输入者本人纠正错误的唯一时机，这也是进行内联 API 调用的最大价值。
设置较短的超时时间，超时后不要继续阻塞流程。免费邮箱验证 API 通常会在 1–3 秒内响应，但表单不应因接收服务商响应缓慢而失败。
- 2
在现有数据流水线中
CRM 同步任务、数据增强 worker 和 ETL 步骤，都是这套免费邮箱验证 API 的自然接入点。应在记录已有的流转路径中加入 API 调用，并将状态、标志和检查时间戳保存为字段。
处理文件而非单条记录时，POST /verify/file API 接受 CSV 或 Excel 文件，并在任务完成时调用你的 webhook，因此批量 API 任务无需保持长连接。
- 3
在 AI 智能体与工具内部
MCP Server 让 Claude Desktop 和 Cursor 能以自然语言调用我们的免费邮箱验证 API，Agent Skills 则可将其一键安装到智能体平台。两种方式都返回与 REST API 相同的结构化 JSON。
这对智能体可靠性很重要：模型无需解析自然语言文本，而且当底层 API 返回 unknown 时，工具不能声称地址有效。
- 4
围绕实际发送环节
时效性比数量更重要。高价值收件人应在临近发送时验证，而不是依赖几个月前记录的状态；长期未使用的记录在进入营销活动前也应重新验证。
对于整份名单， 批量邮箱验证 在文件上运行同一引擎，这样你就不必在实时端点之上重写批处理逻辑。
如实说明的限制
邮箱验证 API 不会声称的四件事
API 响应可信，是因为它的范围很窄。下面每一项都属于别的工具或别的团队，而不属于验证 API。
它不证明身份，也不证明用户同意被联系
邮箱能够收信，并不能说明谁在控制它、对方在哪里工作，或是否同意被联系。共享别名、转发地址和过期的数据增强结果，都可能让错误的人关联上 deliverable API 结果。
请使用第一方数据确认身份，并在自己的记录系统中管理联系同意。任何验证 API 都无法提供这两项信息。
它不保证进入收件箱
SMTP 接受仅说明 API 调用当时的收件路径可用。营销活动邮件能否进入收件箱，取决于发件人声誉、身份认证、内容和投诉历史——这些都是 API 无法观察的发件方因素。
验证排除的是地址层面的失败。邮件本身的投递能力属于另一项工作，需要使用不同的指标衡量。
Catch-All 域名仍然不确定
Catch-All 域名会接受邮箱地址 @ 之前的任意部分，因此任何免费邮箱验证 API 都无法证明某个推测的地址确实存在。API 返回此标志，正是为了避免你的代码自行推断。
应将 Catch-All 结果转交审核，而不是直接归入 deliverable；对于按姓名模式生成的 B2B 名单尤其如此。
结果是一条带时间戳的观察记录
每天都有邮箱被关闭、别名被停用、域名被迁移。API 报告的是调用期间为真的事实，而该事实从 API 响应的那一秒就开始变旧。
将检查时间与状态一并保存，让下游系统能够判断证据是否已过时，不再适合作为决策依据。
相关入口
验证 API 与平台其余部分的关系
同一引擎通过多个 API 入口提供服务。选择哪一个通常取决于使用者，而不是准确率。
手动检查一个地址
需要人工查看单条结果，而非自动处理数千个地址时， 邮箱验证器 在浏览器中运行同一条 SMTP 流水线，并展示 API 会返回的每一项标志。
这是在编写邮箱验证 API 集成代码前，快速确认地址结果是否符合预期的最佳方式。
一次处理整份文件
当处理对象是名单而非数据流时， 邮箱列表清洗 对每一行应用同一套规则，并在导出中保留原因。
文件和 API 调用共用同一个引擎，因此批量清洗中的记录与通过验证 API 检查的相同地址不会出现结果冲突。
以校验为先的表述
邮箱校验 API 页面面向搜索「校验」而非「验证」的团队介绍同一端点，并从校验视角说明集成细节。
端点、schema 和 SMTP 证据完全相同；只有文档的表述角度不同。
常见问题
1. 邮箱验证 API 有多快？
缓存的 API 结果在 200ms 内返回。完整 SMTP 验证平均 1–3 秒完成，因此可以在表单里当作实时邮箱验证 API 使用。该 API 支持每分钟最多 6,000 次单封验证请求与 1,500 次批量请求。
2. 如何集成邮箱验证 API？
验证 API 使用标准 REST 调用与 JSON 响应。提供 Python、Node.js、Go 与 PHP 官方 SDK。多数 API 集成可在 30 分钟内完成。MCP Server 与 Agent Skills 完全无需代码——安装一次，实时邮箱验证 API 即可在任何支持的 AI 客户端中使用。
3. 邮箱验证 API 如何收费？
Starter 套餐 $20 可购买 20,000 积分，每个邮箱 $0.001——无月费，只按实际用量付费。购买 1M 积分时，批量价格可降至每个邮箱 $0.00035。免费邮箱验证 API 套餐每天登录提供 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 检测。
邮箱验证 API
获取你的 API 密钥
一个端点覆盖全部验证类型。包含 MCP Server 与 Agent Skills。免费邮箱验证 API 档位每天登录提供 20 个积分，每月最多 600 个，无需信用卡。
每月 600 个免费积分 · 原生 MCP Server 集成 · 无需信用卡
99.9%
准确率
Real-time
API 速度
$0.00014
每封邮件
600/mo
永久免费