Your team needs to verify user emails before sending OTPs, invoices, or onboarding links—and you need it working this week. By the end of this guide, you will make a live request to the EmailLabs Verification API on Zyla API Hub with curl, parse the JSON, and plug it into your signup, CRM, or messaging workflow.
What the EmailLabs Verification API returns
The EmailLabs Verification API validates a single email address without SMTP “ping” checks. It analyzes:
- Syntax against RFC 5322 and length rules
- Domain resolvability and MX records via DNS
- Disposable-provider detection
- Free-webmail and role-account flags
- Typo suggestions
Responses include a 0–100 confidence score, an overall status (valid, risky, invalid), and structured reasons you can log or display. Typical use cases include signup form validation, bulk CRM hygiene, checkout risk checks, and suppressing disposable emails before they enter your pipeline.
Getting started on Zyla API Hub
To call this API, open the EmailLabs Verification API listing on Zyla, subscribe, and grab your key. Zyla uses a subscription + quota model, not pay-per-call. For this API, you can start with a 7-day trial or 50 requests. No Free Plan.
Start 7-day trial on EmailLabs Verification API
Zyla gives you one account, one API key, and one subscription model across thousands of APIs. You can reuse the same key across different categories when you expand your integration later.
Endpoint you will call
The EmailLabs Verification API provides one verification endpoint. It is a simple GET with an email query parameter and bearer authorization. You pass your API key using the Authorization header.
Verify a single email
- Method: GET
- URL: https://zylalabs.com/api/13031/emaillabs-verification-api/26168/verify-email
- Query parameter: email (required). Example: [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"
]
}Fields you will actually use
- status: Overall categorization (e.g., valid). Use this for quick allow/deny.
- score: 0–100 confidence. Useful for thresholds (e.g., accept ≥ 80).
- isValid: Boolean shortcut for typical allow/deny logic.
- checks.syntax.valid: Reject obviously malformed addresses early.
- checks.domain.hasMx and checks.domain.resolvable: Require MX + resolvable domain if you depend on deliverability.
- checks.disposable.isDisposable: Suppress temporary inboxes.
- checks.free.isFreeProvider: Segment B2C vs. B2B signups or apply extra friction if needed.
- checks.role.isRoleAccount: Flag role accounts like support@ or sales@.
- checks.typo.hasSuggestion: Offer a correction UX when true (e.g., gmial.com → gmail.com).
- reasons: Keep for audit logs or analytics.
First request in JavaScript (fetch)
The sample below calls the same endpoint used in the cURL example, reads core fields, and shows one way to implement a fast allow/deny decision followed by detailed flags for logging or 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) {
// For production, log res.status and res.text() or res.json() as appropriate
throw new Error(`Verification request failed with status ${res.status}`);
}
const data = await res.json();
// Minimal allow/deny logic
const allow = data.isValid === true && data.score >= 80;
// Flags for analytics / 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 || []
};
}
// Example usage
verifyEmail("[email protected]")
.then(result => {
console.log("Verification result:", result);
})
.catch(err => {
console.error(err);
});Integration patterns that ship fast
- Signup forms: Call the API server-side after basic client-side regex checks. If you need instant feedback, call on blur with a debounce and gate submission by status/score.
- Transactional send gate: Before sending password resets or receipts, verify and short-circuit sends to invalid or disposable addresses.
- CRM hygiene: Batch your existing contacts through a simple worker that fetches statuses and annotates records with score, free/disposable flags, and MX presence.
- Lead routing: Prioritize MX-positive, non-disposable business domains. Use freeProvider and role flags to branch workflows.
- Checkout risk checks: Deny disposable emails at checkout or require additional verification based on score threshold.
Operational notes
- Authentication: Always send Authorization: Bearer YOUR_API_KEY.
- Caching: For the same email, you can cache results on your side based on your risk tolerance. Domain-level DNS checks are stable; disposable lists can evolve. Re-verify on key events (first send, role changes, or after a cooldown).
- UX flow: If hasTypoSuggestion is true, guide the user to correct the domain. If freeProvider is true, you may still accept but adjust lead scoring.
- Thresholds: A simple default is allow when isValid is true and score ≥ 80, review 60–79, and block below 60. Tune this to your bounce/risk profile.
- Auditing: Persist status, score, and reasons for each decision to make support escalations faster.
Calling the API from AI agents via MCP
If you use Claude Code, Cursor, Windsurf, or any MCP-compatible client, you can call the same Zyla-hosted endpoint through Zyla’s MCP server. Configure your client with your Zyla API key and point it to the MCP server URL. This lets an AI agent verify emails as part of a coding or data-cleaning session.
Because the EmailLabs Verification API uses a single GET endpoint with a required email parameter, it fits neatly into prompt-driven tools or chain-of-thought routines where the agent proposes an address and then calls verification before taking the next step.
Testing checklist
- Happy path: Valid address with MX (e.g., common webmail domains). Confirm status is valid and score is high.
- Syntax errors: Missing @ or illegal characters. Expect checks.syntax.valid to be false and isValid to be false.
- Non-resolvable domain: Use a nonexistent TLD or domain. Look for domain.resolvable: false and domain.hasMx: false.
- Disposable detection: Try a known disposable domain to see disposable.isDisposable: true and adjust your logic accordingly.
- Role accounts: Test support@ or admin@ on a real domain to see role.isRoleAccount: true.
Security and deployment tips
- Keep YOUR_API_KEY server-side in production. If you need client-side checks, proxy through your server and apply per-IP or per-session limits on your end.
- Log request email and response status/score for diagnostics; avoid logging sensitive user context.
- Implement graceful fallbacks: if the verification service is temporarily unreachable, decide whether to allow with caution or queue verification and gate the next step (e.g., first send).
Troubleshooting
- 401 or 403: Confirm the Authorization header is present and the key is valid for your subscription.
- Unexpected empty fields: Only rely on fields documented in the example response. If a field is absent in a future evolution, handle null/undefined defensively.
- Slow responses in development: DNS checks can vary by network conditions. Consider caching domain-level results and testing from a stable network.
FAQ
Does the API perform SMTP “ping” checks?
No. It uses non-SMTP checks: syntax, length, DNS domain and MX records, disposable detection, free-webmail and role-account flags, and typo suggestions.
What is the fastest way to gate signups?
Call the verification endpoint server-side on form submission. Allow if isValid is true and score meets your threshold; otherwise, show a correction prompt or request a secondary email.
How should I handle disposable providers?
Use checks.disposable.isDisposable. Many teams block disposable emails outright on signup and allow them only for low-trust guest flows.
Can I segment B2B vs. B2C?
Yes. checks.free.isFreeProvider helps distinguish consumer webmail from custom domains. Combine with role-account flags for routing.
What are the access options?
Zyla uses a subscription + quota model. For this API, you can start with a 7-day trial or 50 requests. No Free Plan. See the listing for current options.
Ready to verify your first address and wire it into your signup or send pipeline? Open the listing and start your trial now: Start 7-day trial on EmailLabs Verification API
