API de Verificación de EmailLabs en Zyla API Hub: Primera Solicitud con curl y JSON

Tu equipo necesita verificar los correos electrónicos de los usuarios antes de enviar OTPs, facturas o enlaces de incorporación, y necesitas que funcione esta semana. Al final de esta guía, realizarás una solicitud en vivo a la API de Verificación de EmailLabs en Zyla API Hub con curl, analizarás el JSON y lo integrarás en tu flujo de trabajo de registro, CRM o mensajería.

Lo que devuelve la API de Verificación de EmailLabs

La API de Verificación de EmailLabs valida una sola dirección de correo electrónico sin comprobaciones de "ping" SMTP. Analiza:

Ilustración: API de Verificación de EmailLabs en Zyla API Hub: Primera Solicitud con curl y JSON

Sintaxis contra las reglas de RFC 5322 y longitud
Resolubilidad de dominio y registros MX a través de DNS
Detección de proveedores desechables
Banderas de webmail gratuito y cuentas de rol
Sugerencias de errores tipográficos

Las respuestas incluyen un puntaje de confianza de 0 a 100, un estado general (válido, arriesgado, inválido) y razones estructuradas que puedes registrar o mostrar. Los casos de uso típicos incluyen la validación de formularios de registro, la higiene de CRM en masa, las comprobaciones de riesgo en el proceso de compra y la supresión de correos electrónicos desechables antes de que ingresen a tu canal.

Comenzando en Zyla API Hub

Para llamar a esta API, abre la lista de la API de Verificación de EmailLabs en Zyla, suscríbete y obtén tu clave. Zyla utiliza un modelo de suscripción + cuota, no de pago por llamada. Para esta API, puedes comenzar con una prueba de 7 días o 50 solicitudes. No hay Plan Gratuito.

Comienza la prueba de 7 días en la API de Verificación de EmailLabs

Zyla te brinda una cuenta, una clave API y un modelo de suscripción en miles de APIs. Puedes reutilizar la misma clave en diferentes categorías cuando amplíes tu integración más adelante.

Endpoint que llamarás

La API de Verificación de EmailLabs proporciona un único endpoint de verificación. Es un simple GET con un parámetro de consulta de correo electrónico y autorización de portador. Pasas tu clave API usando el encabezado de Autorización.

Verificar un solo correo electrónico

Método: GET
URL: https://zylalabs.com/api/13031/emaillabs-verification-api/26168/verify-email
Parámetro de consulta: email (requerido). Ejemplo: [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": [
"El dominio tiene registros MX",
"Proveedor de webmail gratuito"
]
}

Campos que realmente usarás

status: Categorización general (por ejemplo, válido). Usa esto para decisiones rápidas de permitir/denegar.
score: Confianza de 0 a 100. Útil para umbrales (por ejemplo, aceptar ≥ 80).
isValid: Atajo booleano para la lógica típica de permitir/denegar.
checks.syntax.valid: Rechaza direcciones evidentemente mal formadas temprano.
checks.domain.hasMx y checks.domain.resolvable: Requiere dominio MX + resoluble si dependes de la entregabilidad.
checks.disposable.isDisposable: Suprime bandejas de entrada temporales.
checks.free.isFreeProvider: Segmenta registros B2C vs. B2B o aplica fricción adicional si es necesario.
checks.role.isRoleAccount: Marca cuentas de rol como support@ o sales@.
checks.typo.hasSuggestion: Ofrece una experiencia de corrección cuando es verdadero (por ejemplo, gmial.com → gmail.com).
reasons: Mantén para registros de auditoría o análisis.

Primera solicitud en JavaScript (fetch)

El ejemplo a continuación llama al mismo endpoint utilizado en el ejemplo de cURL, lee campos clave y muestra una forma de implementar una decisión rápida de permitir/denegar seguida de banderas detalladas para registro o 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 producción, registra res.status y res.text() o res.json() según corresponda
throw new Error(`La solicitud de verificación falló con el estado ${res.status}`);
}

const data = await res.json();

// Lógica mínima de permitir/denegar
const allow = data.isValid === true && data.score >= 80;

// Banderas para análisis / 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 || []
};
}

// Ejemplo de uso
verifyEmail("[email protected]")
.then(result => {
console.log("Resultado de verificación:", result);
})
.catch(err => {
console.error(err);
});

Patrones de integración que se envían rápido

Formularios de registro: Llama a la API del lado del servidor después de las comprobaciones básicas de regex del lado del cliente. Si necesitas retroalimentación instantánea, llama al desenfoque con un debounce y controla la presentación por estado/puntuación.
Puerta de envío transaccional: Antes de enviar restablecimientos de contraseña o recibos, verifica y corta envíos a direcciones inválidas o desechables.
Higiene de CRM: Procesa tus contactos existentes a través de un simple trabajador que obtiene estados y anota registros con puntuación, banderas de gratuito/desechable y presencia de MX.
Enrutamiento de leads: Prioriza dominios comerciales no desechables y positivos en MX. Usa banderas de freeProvider y role para ramificar flujos de trabajo.
Comprobaciones de riesgo en el proceso de compra: Niega correos electrónicos desechables en el proceso de compra o requiere verificación adicional basada en el umbral de puntuación.

Notas operativas

Autenticación: Siempre envía Authorization: Bearer YOUR_API_KEY.
Caché: Para el mismo correo electrónico, puedes almacenar resultados en tu lado según tu tolerancia al riesgo. Las comprobaciones de DNS a nivel de dominio son estables; las listas desechables pueden evolucionar. Re-verifica en eventos clave (primer envío, cambios de rol o después de un tiempo de espera).
Flujo de UX: Si hasTypoSuggestion es verdadero, guía al usuario para corregir el dominio. Si freeProvider es verdadero, aún puedes aceptar pero ajustar la puntuación del lead.
Umbrales: Un simple defecto es permitir cuando isValid es verdadero y score ≥ 80, revisar 60–79 y bloquear por debajo de 60. Ajusta esto a tu perfil de rebote/riesgo.
Auditoría: Persiste el estado, la puntuación y las razones para cada decisión para hacer que las escalaciones de soporte sean más rápidas.

Llamando a la API desde agentes de IA a través de MCP

Si usas Claude Code, Cursor, Windsurf o cualquier cliente compatible con MCP, puedes llamar al mismo endpoint alojado en Zyla a través del servidor MCP de Zyla. Configura tu cliente con tu clave API de Zyla y dirígelo a la URL del servidor MCP. Esto permite que un agente de IA verifique correos electrónicos como parte de una sesión de codificación o limpieza de datos.

MCP

Debido a que la API de Verificación de EmailLabs utiliza un único endpoint GET con un parámetro de correo electrónico requerido, se adapta perfectamente a herramientas impulsadas por prompts o rutinas de cadena de pensamiento donde el agente propone una dirección y luego llama a la verificación antes de dar el siguiente paso.

Lista de verificación de pruebas

Ruta feliz: Dirección válida con MX (por ejemplo, dominios de webmail comunes). Confirma que el estado es válido y la puntuación es alta.
Errores de sintaxis: Falta @ o caracteres ilegales. Espera que checks.syntax.valid sea falso y isValid sea falso.
Dominio no resoluble: Usa un TLD o dominio inexistente. Busca domain.resolvable: false y domain.hasMx: false.
Detección desechable: Prueba un dominio desechable conocido para ver disposable.isDisposable: true y ajusta tu lógica en consecuencia.
Cuentas de rol: Prueba support@ o admin@ en un dominio real para ver role.isRoleAccount: true.

Consejos de seguridad y despliegue

Mantén YOUR_API_KEY del lado del servidor en producción. Si necesitas comprobaciones del lado del cliente, proxy a través de tu servidor y aplica límites por IP o por sesión en tu lado.
Registra el correo electrónico de la solicitud y el estado/puntuación de la respuesta para diagnósticos; evita registrar contexto sensible del usuario.
Implementa retrocesos elegantes: si el servicio de verificación está temporalmente inalcanzable, decide si permitir con precaución o encolar la verificación y controlar el siguiente paso (por ejemplo, primer envío).

Resolución de problemas

401 o 403: Confirma que el encabezado de Autorización está presente y que la clave es válida para tu suscripción.
Campos vacíos inesperados: Solo confía en los campos documentados en la respuesta de ejemplo. Si un campo está ausente en una evolución futura, maneja null/undefined de manera defensiva.
Respuestas lentas en desarrollo: Las comprobaciones de DNS pueden variar según las condiciones de la red. Considera almacenar en caché los resultados a nivel de dominio y probar desde una red estable.

Preguntas frecuentes

¿La API realiza comprobaciones de "ping" SMTP?
No. Utiliza comprobaciones no SMTP: sintaxis, longitud, dominio DNS y registros MX, detección desechable, banderas de webmail gratuito y cuentas de rol, y sugerencias de errores tipográficos.

¿Cuál es la forma más rápida de controlar los registros?
Llama al endpoint de verificación del lado del servidor en la presentación del formulario. Permite si isValid es verdadero y la puntuación cumple con tu umbral; de lo contrario, muestra un aviso de corrección o solicita un correo electrónico secundario.

¿Cómo debo manejar a los proveedores desechables?
Usa checks.disposable.isDisposable. Muchos equipos bloquean correos electrónicos desechables de inmediato en el registro y solo los permiten para flujos de invitados de baja confianza.

¿Puedo segmentar B2B vs. B2C?
Sí. checks.free.isFreeProvider ayuda a distinguir el webmail de consumidores de dominios personalizados. Combina con banderas de cuentas de rol para el enrutamiento.

¿Cuáles son las opciones de acceso?
Zyla utiliza un modelo de suscripción + cuota. Para esta API, puedes comenzar con una prueba de 7 días o 50 solicitudes. No hay Plan Gratuito. Consulta la lista para las opciones actuales.

¿Listo para verificar tu primera dirección e integrarla en tu flujo de registro o envío? Abre la lista y comienza tu prueba ahora: Comienza la prueba de 7 días en la API de Verificación de EmailLabs