\n\tstatus<\/strong><\/span><\/td>The primary decision input. Branch on this first.<\/span><\/td>\n<\/tr>\n\n\treason<\/strong><\/span><\/td>Use to differentiate between Risky and Unknown (catch_all vs role vs disposable, etc.).<\/span><\/td>\n<\/tr>\n\n\tscore<\/strong><\/span><\/td>Numeric confidence, useful when you want a threshold rather than a categorical decision.<\/span><\/td>\n<\/tr>\n\n\tsignals<\/strong><\/span><\/td>Detailed flags. Useful for storing alongside the contact record.<\/span><\/td>\n<\/tr>\n\n\tprovider<\/strong><\/span><\/td>Hosting platform of the recipient (Google, Microsoft, etc.). Useful for later analytics.<\/span><\/td>\n<\/tr>\n\n\tchecked_at<\/strong><\/span><\/td>| Timestamp. Useful for cache invalidation.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n Different vendors will use slightly different field names, but the shape is the same. The four-status pattern (Valid, Risky, Unknown, Invalid) is the de facto industry standard.<\/p>\n <\/span>When to Call Email Verification API in a Signup Flow<\/span><\/h2>\nThere are three reasonable places to fire the verification call in a signup flow, and they’re all valid. The right choice depends on whether you want instant feedback, friction-free submission, or both.<\/p>\n Option A: On-Field Blur<\/h3>\nFire the API call when the email input loses focus (the user clicks away from it). This is the right default for most flows and the core principle behind any real-time email checker<\/a>. The user has finished typing, the request goes off in the background, and by the time they click submit, the result is usually back. The submit-button experience feels instant.<\/p>\nOption B: On Form Submit<\/h3>\nFire the API call when the user clicks submit. Simpler to implement, but the user feels the latency directly. With a fast API and a sensible timeout, this is fine for low-volume forms; for anything user-facing in a competitive market, blur is better.<\/p>\n Option C: While Typing (Debounced)<\/h3>\nFire the API call after a short delay following each keystroke, canceling previous calls. Useful when you want to surface typo suggestions in real time (“Did you mean …@gmail.com?”). Adds complexity and cost, since you can fire several requests per signup, but the UX is the smoothest. Always combine with debouncing (covered in the next section) so you don’t burn API credits on every keystroke.<\/p>\n\n \n\n\n\tTrigger<\/strong><\/span><\/th>Best For<\/strong><\/span><\/th>Trade-off<\/strong><\/span><\/th>\n<\/tr>\n<\/thead>\n\n\n\tOn field blur (default)<\/strong><\/span><\/td>| Most signup forms. Submit feels instant.<\/span><\/td> | Slightly more complex than on-submit.<\/span><\/td>\n<\/tr>\n\n\tOn form submit<\/strong><\/span><\/td>| Low-volume forms; back-office tools.<\/span><\/td> | User feels the latency directly.<\/span><\/td>\n<\/tr>\n\n\tOn typing (debounced)<\/strong><\/span><\/td>| High-conversion flows where typo suggestions matter.<\/span><\/td> | More API calls per signup; higher cost.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n Expert Tip<\/div>\n If you\u2019re unsure which trigger to use, start with on-blur. It hits the sweet spot of cost, complexity, and UX for almost every form. You can layer on typo suggestions later if conversion data shows users would benefit from real-time correction.<\/p>\n<\/div>\n <\/span>How to Use Debouncing for Email Verification<\/span><\/h2>\nIf you verify emails during typing, debouncing is mandatory. Without it, every keystroke fires a new API request, you burn through credits, and you end up rate-limited within the first few signups. Debouncing waits a short delay after the last keystroke before firing and cancels any prior pending call.<\/p>\n An ideal debounce window is 400 to 800 milliseconds. Long enough that users finish typing the local part before the call fires; short enough that the user doesn’t notice the delay.<\/p>\n \n JavaScript debounce, vanilla:<\/div>\n \n function debounce(fn, delay) {<\/div>\n let timer;<\/div>\n return (…args) => {<\/div>\n clearTimeout(timer);<\/div>\n timer = setTimeout(() => fn(…args), delay);<\/div>\n };<\/div>\n }<\/div>\n <\/div>\n const verifyEmail = async (email) => {<\/div>\n const res = await fetch(‘\/api\/verify-email’, {<\/div>\n method: ‘POST’,<\/div>\n headers: { ‘Content-Type’: ‘application\/json’ },<\/div>\n body: JSON.stringify({ email })<\/div>\n });<\/div>\n return res.json();<\/div>\n };<\/div>\n <\/div>\n const debouncedVerify = debounce(verifyEmail, 600);<\/div>\n <\/div>\n emailInput.addEventListener(‘input’, (e) => {<\/div>\n debouncedVerify(e.target.value);<\/div>\n });<\/div>\n<\/div>\n<\/div>\n \n Common Mistake<\/div>\n Calling the verification API on every keystroke without debouncing. We\u2019ve seen forms make 30+ API calls per signup because the developer wired the call to onChange without a delay. The cost runs up quickly, the API rate-limits, and the user gets a flicker of changing statuses for partial addresses that haven\u2019t finished typing.<\/p>\n<\/div>\n <\/span>Should You Verify Emails Server-Side or Client-Side?<\/span><\/h2>\nThis is the most common architectural question. The answer is server-side, and the reason is your API key.<\/p>\n If you call the verification API directly from client-side JavaScript, your API key is in the page source where any browser can see it. A determined visitor extracts it, and now they have your credentials. They can verify their own addresses on your bill, share the key, or use it for purposes you didn’t authorize. The cost (and the abuse) is yours.<\/p>\n The right pattern is to expose your own API endpoint (something like \/api\/verify-email) on your application server, which forwards the call to the verification API with your secret key, then returns the result to the client. The client never sees the key, and you can add your own rate limiting, logging, and abuse handling around the call.<\/p>\n \n Architecture Diagram:<\/div>\n \n Browser Your Server Verifier API<\/div>\n ——- ———– ————<\/div>\n POST \/api\/verify-email<\/div>\n (no API key) –><\/div>\n POST https:\/\/api.verifier.com\/verify<\/div>\n Authorization: Bearer SECRET_KEY –><\/div>\n <\/div>\n <– { status, reason, … }<\/div>\n <– { status, reason, … }<\/div>\n<\/div>\n<\/div>\n \n Key Insight<\/div>\n There\u2019s exactly one valid scenario for client-side verification calls: a publishable \/ restricted-domain key designed for that use, where the vendor enforces origin restrictions on their side. EmailVerify.io and most verifiers don\u2019t offer this; if yours does, the docs will be explicit about it. Default to server-side unless the vendor specifically says otherwise.<\/p>\n<\/div>\n <\/span>Code: Python (Flask)<\/span><\/h2>\nHere’s a complete Flask endpoint that wraps the EmailVerify.io API. It accepts an email from the client, calls the verification API server-side, handles errors and timeouts, and returns the result to the client.<\/p>\n \n Python (Flask) \u2014 server endpoint:<\/div>\n \n import os<\/div>\n import requests<\/div>\n from flask import Flask, request, jsonify<\/div>\n <\/div>\n app = Flask(__name__)<\/div>\n API_KEY = os.environ[‘EMAILVERIFY_API_KEY’]<\/div>\n API_URL = ‘https:\/\/api.emailverify.io\/v1\/verify’<\/div>\n <\/div>\n @app.route(‘\/api\/verify-email’, methods=[‘POST’])<\/div>\n def verify_email():<\/div>\n data = request.get_json() or {}<\/div>\n email = (data.get(’email’) or ”).strip().lower()<\/div>\n <\/div>\n if not email or ‘@’ not in email:<\/div>\n return jsonify({<\/div>\n ‘status’: ‘invalid’,<\/div>\n ‘reason’: ‘invalid_syntax’,<\/div>\n }), 200<\/div>\n <\/div>\n try:<\/div>\n resp = requests.post(<\/div>\n API_URL,<\/div>\n headers={‘Authorization’: f’Bearer {API_KEY}’},<\/div>\n json={’email’: email},<\/div>\n timeout=2.0,<\/div>\n )<\/div>\n resp.raise_for_status()<\/div>\n result = resp.json()<\/div>\n return jsonify({<\/div>\n ‘status’: result[‘status’],<\/div>\n ‘reason’: result.get(‘reason’),<\/div>\n ‘score’: result.get(‘score’),<\/div>\n }), 200<\/div>\n <\/div>\n except requests.Timeout:<\/div>\n return jsonify({<\/div>\n | | | | | | | | | | | | | | | | | | | | |