Sua equipe precisa verificar os e-mails dos usuários antes de enviar OTPs, faturas ou links de integração—e você precisa que isso funcione esta semana. Ao final deste guia, você fará um pedido ao vivo para a API de Verificação do EmailLabs no Zyla API Hub com curl, analisará o JSON e o integrará ao seu fluxo de inscrição, CRM ou mensagens.
O que a API de Verificação do EmailLabs retorna
A API de Verificação do EmailLabs valida um único endereço de e-mail sem verificações de “ping” SMTP. Ela analisa:
- Sintaxe contra as regras RFC 5322 e de comprimento
- Resolvibilidade de domínio e registros MX via DNS
- Detecção de provedores descartáveis
- Bandeiras de webmail gratuito e contas de função
- Sugestões de erro de digitação
As respostas incluem uma pontuação de confiança de 0 a 100, um status geral (válido, arriscado, inválido) e razões estruturadas que você pode registrar ou exibir. Casos de uso típicos incluem validação de formulários de inscrição, higiene em massa de CRM, verificações de risco de checkout e supressão de e-mails descartáveis antes que eles entrem em seu pipeline.
Começando no Zyla API Hub
Para chamar esta API, abra a listagem da API de Verificação do EmailLabs no Zyla, inscreva-se e pegue sua chave. O Zyla usa um modelo de assinatura + cota, não pagamento por chamada. Para esta API, você pode começar com um teste de 7 dias ou 50 pedidos. Sem Plano Gratuito.
Comece o teste de 7 dias na API de Verificação do EmailLabs
O Zyla oferece uma conta, uma chave de API e um modelo de assinatura em milhares de APIs. Você pode reutilizar a mesma chave em diferentes categorias quando expandir sua integração mais tarde.
Endpoint que você chamará
A API de Verificação do EmailLabs fornece um único endpoint de verificação. É um simples GET com um parâmetro de consulta de e-mail e autorização bearer. Você passa sua chave de API usando o cabeçalho Authorization.
Verificar um único e-mail
- Método: GET
- URL: https://zylalabs.com/api/13031/emaillabs-verification-api/26168/verify-email
- Parâmetro de consulta: email (obrigatório). Exemplo: [email protected]
- Auth: 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": [
"Domain has MX records",
"Free webmail provider"
]
}Campos que você realmente usará
- status: Categorização geral (por exemplo, válido). Use isso para permitir/rejeitar rapidamente.
- score: 0–100 de confiança. Útil para limites (por exemplo, aceitar ≥ 80).
- isValid: Atalho booleano para lógica típica de permitir/rejeitar.
- checks.syntax.valid: Rejeitar endereços obviamente malformados cedo.
- checks.domain.hasMx e checks.domain.resolvable: Exigir domínio MX + resolvível se você depender da entregabilidade.
- checks.disposable.isDisposable: Suprimir caixas de entrada temporárias.
- checks.free.isFreeProvider: Segmentar inscrições B2C vs. B2B ou aplicar fricção extra, se necessário.
- checks.role.isRoleAccount: Marcar contas de função como support@ ou sales@.
- checks.typo.hasSuggestion: Oferecer uma correção UX quando verdadeiro (por exemplo, gmial.com → gmail.com).
- reasons: Manter para logs de auditoria ou análises.
Primeiro pedido em JavaScript (fetch)
O exemplo abaixo chama o mesmo endpoint usado no exemplo cURL, lê campos principais e mostra uma maneira de implementar uma decisão rápida de permitir/rejeitar seguida de bandeiras detalhadas para registro ou UI.
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) {
// Para produção, registre res.status e res.text() ou res.json() conforme apropriado
throw new Error(`Verification request failed with status ${res.status}`);
}
const data = await res.json();
// Lógica mínima de permitir/rejeitar
const allow = data.isValid === true && data.score >= 80;
// Bandeiras para análises / UI
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 || []
};
}
// Exemplo de uso
verifyEmail("[email protected]")
.then(result => {
console.log("Verification result:", result);
})
.catch(err => {
console.error(err);
});Padrões de integração que são rápidos
- Formulários de inscrição: Chame a API no lado do servidor após verificações básicas de regex no lado do cliente. Se você precisar de feedback instantâneo, chame no blur com um debounce e controle a submissão pelo status/pontuação.
- Portão de envio transacional: Antes de enviar redefinições de senha ou recibos, verifique e interrompa envios para endereços inválidos ou descartáveis.
- Higiene de CRM: Lote seus contatos existentes através de um trabalhador simples que busca status e anota registros com pontuação, bandeiras de gratuito/descarte e presença de MX.
- Roteamento de leads: Priorize domínios de negócios não descartáveis e positivos em MX. Use bandeiras de freeProvider e role para ramificar fluxos de trabalho.
- Verificações de risco de checkout: Negue e-mails descartáveis no checkout ou exija verificação adicional com base no limite de pontuação.
Notas operacionais
- Autenticação: Sempre envie Authorization: Bearer YOUR_API_KEY.
- Cache: Para o mesmo e-mail, você pode armazenar resultados do seu lado com base na sua tolerância ao risco. Verificações de DNS em nível de domínio são estáveis; listas descartáveis podem evoluir. Re-verifique em eventos-chave (primeiro envio, mudanças de função ou após um cooldown).
- Fluxo UX: Se hasTypoSuggestion for true, guie o usuário para corrigir o domínio. Se freeProvider for true, você ainda pode aceitar, mas ajustar a pontuação do lead.
- Limiares: Um padrão simples é permitir quando isValid for true e score ≥ 80, revisar 60–79 e bloquear abaixo de 60. Ajuste isso ao seu perfil de bounce/risco.
- Auditoria: Persista status, pontuação e razões para cada decisão para tornar as escaladas de suporte mais rápidas.
Chamando a API de agentes de IA via MCP
Se você usar Claude Code, Cursor, Windsurf ou qualquer cliente compatível com MCP, pode chamar o mesmo endpoint hospedado no Zyla através do servidor MCP do Zyla. Configure seu cliente com sua chave de API do Zyla e aponte para a URL do servidor MCP. Isso permite que um agente de IA verifique e-mails como parte de uma sessão de codificação ou limpeza de dados.
Como a API de Verificação do EmailLabs usa um único endpoint GET com um parâmetro de e-mail obrigatório, ela se encaixa perfeitamente em ferramentas orientadas por prompt ou rotinas de cadeia de pensamento onde o agente propõe um endereço e, em seguida, chama a verificação antes de dar o próximo passo.
Lista de verificação de testes
- Caminho feliz: Endereço válido com MX (por exemplo, domínios de webmail comuns). Confirme que o status é válido e a pontuação é alta.
- Erros de sintaxe: @ ausente ou caracteres ilegais. Espere que checks.syntax.valid seja false e isValid seja false.
- Domínio não resolvível: Use um TLD ou domínio inexistente. Procure domain.resolvable: false e domain.hasMx: false.
- Detecção descartável: Tente um domínio descartável conhecido para ver disposable.isDisposable: true e ajuste sua lógica de acordo.
- Contas de função: Teste support@ ou admin@ em um domínio real para ver role.isRoleAccount: true.
Dicas de segurança e implantação
- Mantenha YOUR_API_KEY no lado do servidor em produção. Se você precisar de verificações no lado do cliente, faça proxy através do seu servidor e aplique limites por IP ou por sessão do seu lado.
- Registre o e-mail da solicitação e o status/pontuação da resposta para diagnósticos; evite registrar contexto sensível do usuário.
- Implemente alternativas graciosas: se o serviço de verificação estiver temporariamente inacessível, decida se deve permitir com cautela ou enfileirar a verificação e controlar o próximo passo (por exemplo, primeiro envio).
Solução de problemas
- 401 ou 403: Confirme que o cabeçalho Authorization está presente e a chave é válida para sua assinatura.
- Campos vazios inesperados: Confie apenas nos campos documentados na resposta de exemplo. Se um campo estiver ausente em uma evolução futura, trate null/undefined defensivamente.
- Respostas lentas em desenvolvimento: As verificações de DNS podem variar de acordo com as condições da rede. Considere armazenar em cache os resultados em nível de domínio e testar a partir de uma rede estável.
FAQ
A API realiza verificações de “ping” SMTP?
Não. Ela usa verificações não-SMTP: sintaxe, comprimento, domínio DNS e registros MX, detecção de descartáveis, bandeiras de webmail gratuito e contas de função, e sugestões de erro de digitação.
Qual é a maneira mais rápida de controlar inscrições?
Chame o endpoint de verificação no lado do servidor na submissão do formulário. Permita se isValid for true e a pontuação atender ao seu limite; caso contrário, mostre um prompt de correção ou solicite um e-mail secundário.
Como devo lidar com provedores descartáveis?
Use checks.disposable.isDisposable. Muitas equipes bloqueiam e-mails descartáveis diretamente na inscrição e os permitem apenas para fluxos de convidados de baixa confiança.
Posso segmentar B2B vs. B2C?
Sim. checks.free.isFreeProvider ajuda a distinguir webmail de consumidores de domínios personalizados. Combine com bandeiras de contas de função para roteamento.
Quais são as opções de acesso?
O Zyla usa um modelo de assinatura + cota. Para esta API, você pode começar com um teste de 7 dias ou 50 pedidos. Sem Plano Gratuito. Veja a listagem para opções atuais.
Pronto para verificar seu primeiro endereço e integrá-lo ao seu fluxo de inscrição ou envio? Abra a listagem e comece seu teste agora: Comece o teste de 7 dias na API de Verificação do EmailLabs
