EmailLabs 验证 API 在 Zyla API Hub：使用 curl 和 JSON 的第一次请求

您的团队需要在发送 OTP、发票或入职链接之前验证用户电子邮件——而您需要在本周内完成。通过本指南，您将使用 curl 向 Zyla API Hub 上的 EmailLabs 验证 API 发出实时请求，解析 JSON，并将其插入到您的注册、CRM 或消息工作流中。

EmailLabs 验证 API 返回的内容

EmailLabs 验证 API 在没有 SMTP “ping” 检查的情况下验证单个电子邮件地址。它分析：

插图：EmailLabs 验证 API 在 Zyla API Hub：使用 curl 和 JSON 的第一次请求

符合 RFC 5322 的语法和长度规则
通过 DNS 解析域名和 MX 记录
一次性提供商检测
免费网络邮件和角色账户标志
拼写建议

响应包括 0–100 的置信度分数、整体状态（有效、风险、无效）以及您可以记录或显示的结构化原因。典型用例包括注册表单验证、大规模 CRM 卫生、结账风险检查，以及在它们进入您的管道之前抑制一次性电子邮件。

在 Zyla API Hub 上开始

要调用此 API，请打开 Zyla 上的 EmailLabs 验证 API 列表，订阅并获取您的密钥。Zyla 使用订阅 + 配额模型，而不是按调用付费。对于此 API，您可以从 7 天的试用或 50 次请求开始。没有免费计划。

开始 7 天试用 EmailLabs 验证 API

Zyla 为您提供一个账户、一个 API 密钥和一个跨越数千个 API 的订阅模型。您可以在稍后扩展集成时在不同类别中重用相同的密钥。

您将调用的端点

EmailLabs 验证 API 提供一个验证端点。它是一个简单的 GET 请求，带有电子邮件查询参数和 Bearer 授权。您通过 Authorization 头传递您的 API 密钥。

验证单个电子邮件

方法：GET
URL：https://zylalabs.com/api/13031/emaillabs-verification-api/26168/verify-email
查询参数：email（必需）。示例：[email protected]
授权：Authorization: Bearer YOUR_API_KEY

cURL

curl -s -X GET "https://zylalabs.com/api/13031/emaillabs-verification-api/26168/verify-email?email=john.doe%40gmail.com"
-H "Authorization: Bearer YOUR_API_KEY"

JSON

{
"email": "[email protected]",
"normalizedEmail": "[email protected]",
"status": "valid",
"score": 100,
"isValid": true,
"checks": {
"syntax": {
"valid": true,
"localPart": "john.doe",
"domain": "gmail.com"
},
"length": {
"valid": true,
"localPartLength": 8,
"domainLength": 9,
"totalLength": 18
},
"domain": {
"resolvable": true,
"hasMx": true,
"mxRecords": [
"gmail-smtp-in.l.google.com",
"alt1.gmail-smtp-in.l.google.com",
"alt2.gmail-smtp-in.l.google.com",
"alt3.gmail-smtp-in.l.google.com",
"alt4.gmail-smtp-in.l.google.com"
],
"hasAddressRecord": false,
"nullMx": false
},
"disposable": {
"isDisposable": false
},
"free": {
"isFreeProvider": true
},
"role": {
"isRoleAccount": false
},
"typo": {
"hasSuggestion": false
}
},
"reasons": [
"域名有 MX 记录",
"免费网络邮件提供商"
]
}

您将实际使用的字段

status：整体分类（例如，有效）。用于快速允许/拒绝。
score：0–100 置信度。用于阈值（例如，接受 ≥ 80）。
isValid：典型允许/拒绝逻辑的布尔快捷方式。
checks.syntax.valid：尽早拒绝明显格式错误的地址。
checks.domain.hasMx 和 checks.domain.resolvable：如果您依赖于可交付性，则需要 MX + 可解析域名。
checks.disposable.isDisposable：抑制临时邮箱。
checks.free.isFreeProvider：区分 B2C 与 B2B 注册，或在需要时施加额外摩擦。
checks.role.isRoleAccount：标记角色账户，如 support@ 或 sales@。
checks.typo.hasSuggestion：当为真时提供更正用户体验（例如，gmial.com → gmail.com）。
reasons：保留用于审计日志或分析。

JavaScript 中的第一次请求（fetch）

下面的示例调用与 cURL 示例中使用的相同端点，读取核心字段，并展示了一种实现快速允许/拒绝决策的方法，随后是用于记录或用户界面的详细标志。

async function verifyEmail(email) {
const url = new URL("https://zylalabs.com/api/13031/emaillabs-verification-api/26168/verify-email");
url.searchParams.set("email", email);

const res = await fetch(url.toString(), {
method: "GET",
headers: {
"Authorization": "Bearer YOUR_API_KEY"
}
});

if (!res.ok) {
// 对于生产环境，记录 res.status 和 res.text() 或 res.json() 以适当处理
throw new Error(`验证请求失败，状态 ${res.status}`);
}

const data = await res.json();

// 最小允许/拒绝逻辑
const allow = data.isValid === true && data.score >= 80;

// 分析/用户界面的标志
const flags = {
syntaxValid: data?.checks?.syntax?.valid === true,
mx: data?.checks?.domain?.hasMx === true,
resolvable: data?.checks?.domain?.resolvable === true,
disposable: data?.checks?.disposable?.isDisposable === true,
freeProvider: data?.checks?.free?.isFreeProvider === true,
roleAccount: data?.checks?.role?.isRoleAccount === true,
hasTypoSuggestion: data?.checks?.typo?.hasSuggestion === true,
};

return {
input: email,
normalized: data.normalizedEmail,
status: data.status,
score: data.score,
allow,
flags,
reasons: data.reasons || []
};
}

// 示例用法
verifyEmail("[email protected]")
.then(result => {
console.log("验证结果：", result);
})
.catch(err => {
console.error(err);
});

快速交付的集成模式

注册表单：在基本客户端正则检查后，服务器端调用 API。如果您需要即时反馈，请在失去焦点时调用，使用防抖并根据状态/分数控制提交。
事务发送门：在发送密码重置或收据之前，验证并短路发送到无效或一次性地址。
CRM 卫生：通过一个简单的工作程序批量处理您现有的联系人，该程序获取状态并用分数、免费/一次性标志和 MX 存在性注释记录。
潜在客户路由：优先考虑 MX 正面、非一次性的商业域名。使用 freeProvider 和角色标志来分支工作流。
结账风险检查：在结账时拒绝一次性电子邮件，或根据分数阈值要求额外验证。

操作说明

身份验证：始终发送 Authorization: Bearer YOUR_API_KEY。
缓存：对于相同的电子邮件，您可以根据您的风险承受能力在您的端缓存结果。域级 DNS 检查是稳定的；一次性列表可能会演变。在关键事件（首次发送、角色更改或冷却后）重新验证。
用户体验流程：如果 hasTypoSuggestion 为真，引导用户更正域名。如果 freeProvider 为真，您仍然可以接受，但调整潜在客户评分。
阈值：一个简单的默认值是当 isValid 为真且分数 ≥ 80 时允许，60–79 时审核，低于 60 时阻止。根据您的反弹/风险配置进行调整。
审计：持久化每个决策的状态、分数和原因，以加快支持升级。

通过 MCP 从 AI 代理调用 API

如果您使用 Claude Code、Cursor、Windsurf 或任何兼容 MCP 的客户端，您可以通过 Zyla 的 MCP 服务器调用相同的 Zyla 托管端点。使用您的 Zyla API 密钥配置您的客户端，并将其指向 MCP 服务器 URL。这使得 AI 代理可以在编码或数据清理会话中验证电子邮件。

MCP

由于 EmailLabs 验证 API 使用一个带有必需电子邮件参数的单 GET 端点，因此它非常适合于提示驱动的工具或思维链例程，其中代理提出一个地址，然后在采取下一步之前调用验证。