रीयल-टाइम ईमेल सत्यापन API: डेवलपर गाइड

रीयल-टाइम ईमेल सत्यापन तब किसी पते की जाँच करता है, जब उपयोगकर्ता अभी भी आपके फ़ॉर्म पर होता है। यह “Submit” और अगली स्क्रीन के बीच के कुछ सौ मिलीसेकंड में चलता है और एक सवाल का जवाब देता है: क्या यह पता आपके डेटाबेस में जाना चाहिए? रीयल-टाइम ईमेल सत्यापन API यह निर्णय आपके लिए लेता है। यह सिंटैक्स, डोमेन और उसके MX रिकॉर्ड, डिस्पोज़ेबल और भूमिका-संबंधी संकेत, कैच-ऑल व्यवहार और, आपके अनुरोध पर, स्वयं मेलबॉक्स की जाँच करता है। फिर यह एक संरचित परिणाम लौटाता है, जिस पर आपका कोड कार्रवाई कर सकता है।

यह गाइड उन डेवलपर्स के लिए है, जो साइनअप, चेकआउट या लीड फ़ॉर्म में यह फ़िल्टर जोड़ रहे हैं। इसमें बताया गया है कि जाँचें क्या करती हैं, API को कैसे कॉल करें, प्रत्येक स्थिति को उत्पाद-निर्णय में कैसे बदलें और मेल सर्वर धीमा होने पर भी गति कैसे बनाए रखें। उदाहरणों में BillionVerify ईमेल सत्यापन API का उपयोग किया गया है, लेकिन डिज़ाइन संबंधी सलाह किसी भी प्रदाता पर लागू होती है।

रियल-टाइम ईमेल सत्यापन क्या है?

रियल-टाइम ईमेल सत्यापन वह जाँच है जो किसी पते के दर्ज किए जाते समय चलती है, न कि कई दिनों बाद जब कैंपेन शुरू होता है। उपयोगकर्ता एक पता टाइप करता है। आपका फ्रंटएंड या बैकएंड उसे ईमेल चेकर API को भेजता है। API valid, invalid या catchall जैसे स्टेटस के साथ उनके पीछे के संकेत भी देता है। फिर आपका एप्लिकेशन साइनअप की अनुमति देता है, उसे रोकता है या उपयोगकर्ता से टाइपो ठीक करने को कहता है।

मुख्य बात समय है। gmial.com जैसी टाइपो को तब ठीक करने में कुछ खर्च नहीं होता जब उपयोगकर्ता अभी भी फ़ॉर्म पर हो। स्वागत ईमेल बाउंस होने के बाद यही टाइपो ग्राहक की कीमत बन जाती है। गलत पते आपकी प्रेषक प्रतिष्ठा को भी नुकसान पहुँचाते हैं, क्योंकि हर हार्ड बाउंस मेलबॉक्स प्रदाताओं को बताता है कि आप अपुष्ट पतों पर भेजते हैं। रियल-टाइम ईमेल सत्यापन उन्हें दरवाज़े पर ही रोक देता है।

यह धोखाधड़ी से बचाव में भी मदद करता है: रियल-टाइम जाँच खाता बनने से पहले ही किसी अस्थायी इनबॉक्स को चिह्नित कर सकती है।

रियल-टाइम बनाम बल्क Email Validation

दोनों तरीकों में समान जाँचों का उपयोग होता है। अंतर यह है कि वे कब चलते हैं और उनके पास कितना समय होता है।

• रियल-टाइम सत्यापन एक बार में एक पते पर, उपयोगकर्ता के अनुरोध के दौरान चलता है। इसका समय बजट सख्त होता है, अक्सर एक सेकंड से भी कम, क्योंकि धीमा फ़ॉर्म साइनअप कम कर देता है। यह खराब डेटा को अंदर आने से रोकता है।
• बल्क सत्यापन पृष्ठभूमि में पूरी सूची पर चलता है। इसमें कुछ मिनट या घंटे लग सकते हैं और कोई स्क्रीन के सामने प्रतीक्षा नहीं कर रहा होता। यह आपके सिस्टम में पहले से मौजूद डेटा को साफ़ करता है, जैसे किसी बड़े अभियान से पहले या CRM आयात के बाद।

अधिकांश टीमों को दोनों की आवश्यकता होती है। रियल-टाइम जाँचें नए डेटा को साफ़ रखती हैं, जबकि समय-समय पर किया गया बल्क सत्यापन उन पतों को पकड़ लेता है जो समय के साथ खराब हो गए हैं, जैसे कंपनी छोड़ चुके कर्मचारियों के पते। अधिक गहन तुलना के लिए, रियल-टाइम बनाम बल्क Email Validation देखें।

रियल-टाइम जाँच वास्तव में क्या जाँचती है

एक ईमेल सत्यापन API सस्ती से महँगी तक कई जाँचें चलाती है। हर जाँच खराब पते के एक अलग प्रकार को बाहर करती है।

सिंटैक्स

पहली जाँच फ़ॉर्मैट की होती है। क्या इसमें ठीक एक @ है? क्या लोकल भाग में अनुमत अक्षर हैं? क्या डोमेन, डोमेन जैसा दिखता है? सिंटैक्स स्पष्ट रूप से गलत पतों, जैसे john@@example या jane.example.com, को अस्वीकार करता है। यह तेज़ है और इसके लिए किसी नेटवर्क कॉल की आवश्यकता नहीं होती। लेकिन सही सिंटैक्स से यह पता नहीं चलता कि मेलबॉक्स मौजूद है या नहीं।

डोमेन और MX रिकॉर्ड

इसके बाद API DNS में डोमेन खोजती है। बिना MX रिकॉर्ड वाला डोमेन ईमेल प्राप्त नहीं कर सकता, इसलिए वहाँ का पता कितना भी साफ़ दिखे, बेकार है। इससे गलत वर्तनी वाले डोमेन और बंद हो चुके कंपनी डोमेन पकड़े जाते हैं। BillionVerify mx_records में मिले MX होस्ट लौटाता है, और जब डोमेन किसी सामान्य डोमेन की टाइपो जैसा दिखता है, तो domain_suggestion संभावित सुधार दे सकता है।

डिस्पोज़ेबल, भूमिका और मुफ़्त-प्रदाता संकेत

कुछ पते मौजूद होते हैं, लेकिन फिर भी आपके उत्पाद के लिए उपयुक्त नहीं होते:

• डिस्पोज़ेबल पते अस्थायी इनबॉक्स सेवाओं से आते हैं और आमतौर पर कुछ घंटों में काम करना बंद कर देते हैं। देखें डिस्पोज़ेबल ईमेल पहचान कैसे काम करती है।
• भूमिका वाले पते, जैसे info@ या support@, किसी व्यक्ति के बजाय टीम तक पहुँचते हैं। वे आमतौर पर डिलीवर हो जाते हैं, लेकिन उनमें सहभागिता कम होती है।
• मुफ़्त-प्रदाता वाले पते, जैसे Gmail, उपभोक्ताओं के लिए सामान्य हैं, लेकिन B2B फ़ॉर्म पर इन्हें दर्ज करना उपयोगी है।

API इन्हें फ़्लैग (is_disposable, is_role, is_free) के रूप में रिपोर्ट करती है, ताकि आप हर उत्पाद के अनुसार निर्णय ले सकें।

कैच-ऑल डोमेन

कुछ मेल सर्वर अपने डोमेन के किसी भी पते पर, चाहे वह वास्तविक हो या नहीं, मेल स्वीकार कर लेते हैं। ऐसे कैच-ऑल डोमेन के लिए, मेलबॉक्स जाँच यह सिद्ध नहीं कर सकती कि कोई विशिष्ट इनबॉक्स मौजूद है। कैच-ऑल परिणाम खराब परिणाम नहीं है। इसका अर्थ है कि निश्चितता कम है, इसलिए लेबल की तुलना में स्कोर अधिक महत्वपूर्ण है। कैच-ऑल ईमेल पहचान बताती है कि यह कैसे काम करती है और क्यों महत्वपूर्ण है।

SMTP मेलबॉक्स जाँच

सबसे गहरी जाँच प्राप्तकर्ता के मेल सर्वर से SMTP के ज़रिए पूछती है कि वह मेलबॉक्स संदेश स्वीकार करेगा या नहीं, बिना कोई संदेश भेजे। इससे वास्तविक डोमेन पर मौजूद ऐसे पते मिलते हैं जो अब अस्तित्व में नहीं हैं, जैसे किसी पूर्व कर्मचारी का इनबॉक्स। यह सबसे धीमा चरण भी है, क्योंकि यह किसी दूसरे सर्वर पर निर्भर करता है। BillionVerify में इसे check_smtp पैरामीटर नियंत्रित करता है। यदि आप इसे छोड़ देते हैं, तो API SMTP जाँच चलाती है; इसे छोड़ने के लिए check_smtp: false भेजें।

डोमेन प्रतिष्ठा

BillionVerify domain_reputation ऑब्जेक्ट भी लौटा सकता है, जिसमें डोमेन के मेल सर्वर के IP के लिए ब्लैकलिस्ट परिणाम होते हैं। यह केवल जानकारी के लिए है: इससे स्थिति, स्कोर या लागत नहीं बदलती।

रीयल-टाइम Email Validation API को कैसे कॉल करें

BillionVerify के साथ, एक रीयल-टाइम जाँच एक HTTPS अनुरोध है। Base URL https://api.billionverify.com/v1 है, और आपकी API key BV-API-KEY header में जाती है। उस key को अपने server पर रखें। इसे browser code में कभी शामिल न करें।

यहाँ API संदर्भ पर आधारित एक न्यूनतम अनुरोध है:

curl -X POST https://api.billionverify.com/v1/verify/single \
  -H "BV-API-KEY: sk_xxx" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","check_smtp":true}'

अनुरोध में तीन parameters होते हैं:

सफल response result को एक standard envelope में रखता है। deliverable address के लिए एक संक्षिप्त उदाहरण यहाँ है:

{
  "success": true,
  "code": "0",
  "message": "Success",
  "data": {
    "email": "user@example.com",
    "status": "valid",
    "score": 0.95,
    "is_deliverable": true,
    "is_disposable": false,
    "is_catchall": false,
    "is_role": false,
    "is_free": false,
    "domain": "example.com",
    "mx_records": ["mail.example.com"],
    "check_smtp": true,
    "reason": "smtp_deliverable",
    "domain_suggestion": "",
    "response_time": 250,
    "credits_used": 1
  }
}

यदि आप SDK पसंद करते हैं, तो BillionVerify Node.js, Python, TypeScript, Go, PHP और Java के लिए आधिकारिक SDK प्रकाशित करता है। Node.js में, npm install billionverify-sdk आपको verify method वाला client देता है; Python में package billionverify है।

प्रतिक्रिया पढ़ना: स्थिति, स्कोर और कारण

status फ़ील्ड पर अधिकांश कोड शाखाएँ निर्भर करती हैं। साइनअप फ़ॉर्म के लिए प्रत्येक स्थिति का अर्थ और उचित डिफ़ॉल्ट यहाँ दिया गया है:

score आपको 0 और 1 के बीच अधिक सूक्ष्म संकेत देता है। मोटे तौर पर, valid परिणामों का स्कोर 0.85 से 1.0, catchall का लगभग 0.55 से 0.75, unknown का 0.3 से 0.6, disposable का 0.1 और invalid का 0 होता है। role परिणाम में मूल जाँच का स्कोर बना रहता है। आप इस स्कोर का उपयोग सीमांत मामलों के लिए अपनी सीमा तय करने में कर सकते हैं, उदाहरण के लिए किसी उच्च-मूल्य वाले फ़ॉर्म पर केवल निश्चित स्कोर से ऊपर के catch-all पतों को स्वीकार करना।

reason फ़ील्ड निर्णय की व्याख्या करता है। invalid परिणाम के साथ invalid_syntax, no_mx_records या mailbox_not_found आ सकता है, और इनमें से प्रत्येक उपयोगकर्ता के लिए अलग संदेश का संकेत देता है। सिंटैक्स की समस्या का अर्थ है "फ़ॉर्मैट जाँचें"। अनुपलब्ध मेलबॉक्स का अर्थ है "यह इनबॉक्स मौजूद नहीं है"। सत्यापन कारण पृष्ठ हर कारण की सूची देता है और बताता है कि किन unknown कारणों पर दोबारा प्रयास करना उचित है।

दो फ़ील्ड सीधे उपयोगकर्ता की सहायता करते हैं: domain_suggestion से "क्या आपका मतलब gmail.com है?" जैसा संकेत दिया जा सकता है, और is_disposable बताता है कि इस्तेमाल करके फेंक दिए जाने वाले पते को क्यों अस्वीकार किया गया।

विलंबता बजट के अनुसार Signup Flow डिज़ाइन करना

कठिन हिस्सा यह है कि फ़ॉर्म को धीमा किए बिना जाँच को उसमें शामिल किया जाए। बजट से शुरुआत करें। तय करें कि आप उपयोगकर्ता को कितनी देर रोकने के इच्छुक हैं, उदाहरण के लिए submit पर 300 से 500 मिलीसेकंड। बाकी सब उसी संख्या से तय होता है।

BillionVerify का product copy cached results को 200 ms से कम और full SMTP check को औसतन 1–3 सेकंड में पूरा होने का बताता है। यह अंतर आपके सामने दो अच्छे डिज़ाइन रखता है:

1. Timeout के साथ full check। SMTP चालू करके और 2–3 सेकंड का timeout रखकर API को कॉल करें। अधिकांश उत्तर समय पर आ जाते हैं और आपको स्पष्ट valid या invalid देते हैं। यदि timeout हो जाए, तो fail open करें और बाद में फिर जाँच करें।
2. अभी तेज़ जाँच, बाद में गहरी जाँच। check_smtp: false के साथ API को कॉल करें। इससे केवल स्पष्ट मामलों का निर्णय होता है: गलत syntax, बिना MX records वाला domain, disposable और role addresses। किसी कार्यशील domain का address unknown के रूप में smtp_unverifiable कारण के साथ लौटता है, जो अपेक्षित है। इसे स्वीकार करें, फिर background job से SMTP चालू करके दूसरी call चलाएँ। यदि mailbox मौजूद न हो, तो account को चिह्नित करें और उपयोगकर्ता से अपना address confirm करने को कहें।

कुछ frontend आदतें भी मदद करती हैं:

• हर keystroke पर नहीं, blur या submit पर validate करें। j, jo, joh की जाँच calls और credits बर्बाद करती है।
• पहले local syntax checks चलाएँ, ताकि स्पष्ट गलतियों पर round trip बच सके।
• API को अपने backend से call करें। आपका server API key रखता है और result दर्ज करता है; browser केवल outcome दिखाता है।

Wording, error placement और hint कब दिखाना है जैसी UX details के लिए signup के दौरान email verification देखें।

Fail Open या Fail Closed? Timeouts और Unknowns को संभालना

ज़्यादातर products के लिए काम करने वाला तरीका है: स्पष्ट errors पर fail closed, अनिश्चितता पर fail open।

• Fail closed का मतलब है कि आप signup रोक देते हैं। ऐसा तब करें जब API बताए कि address स्पष्ट रूप से खराब है: invalid के साथ invalid_syntax या no_mx_records, या ऐसे form पर disposable address जहाँ throwaway accounts नुकसान पहुँचा सकते हैं।
• Fail open का मतलब है कि आप user को आगे बढ़ने देते हैं और बाद में follow up करते हैं। ऐसा तब करें जब उत्तर अनिश्चित हो: unknown status, catch-all domain, या API के उत्तर देने से पहले आपका अपना timeout सक्रिय हो जाए।

अनिश्चित addresses को भी block क्यों न करें? इनके पीछे वास्तविक लोग हो सकते हैं। Corporate mail servers अक्सर SMTP checks को greylist या rate-limit करते हैं, इसलिए उन्हें block करने से वास्तविक signups कम हो जाते हैं। Accept करें, record को tag करें और बाद में फिर से जाँच करें।

अपने API call पर client-side timeout लगाएँ, जो आपके latency budget के अनुरूप हो। इसके सक्रिय होने पर result को unknown मानें: accept करें, एक flag store करें और background re-check queue में डालें। unknown results को request के भीतर नहीं, बल्कि बाद में retry करें।

उदाहरण: Node.js में साइनअप पर ईमेल सत्यापित करें

नीचे दिया गया खाका साइनअप हैंडलर में तेज़ जाँच (डिज़ाइन 2) दिखाता है। इसमें दस्तावेज़ित REST endpoint और response fields, एक timeout, तथा ऊपर दिए गए fail open या closed नियमों का उपयोग किया गया है। नामों को अपने framework के अनुसार अनुकूलित करें।

const BLOCK = new Set(['invalid', 'disposable']);

async function checkEmail(email) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 400);

  try {
    const response = await fetch('https://api.billionverify.com/v1/verify/single', {
      method: 'POST',
      headers: {
        'BV-API-KEY': process.env.BV_API_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ email, check_smtp: false }),
      signal: controller.signal,
    });
    const body = await response.json();
    if (!body.success) return { allow: true, recheck: true };

    const { status, reason, domain_suggestion } = body.data;
    if (BLOCK.has(status)) {
      return { allow: false, reason, suggestion: domain_suggestion };
    }
    return { allow: true, recheck: status === 'unknown' || status === 'catchall' };
  } catch {
    // Timeout or network error: fail open and re-check in the background.
    return { allow: true, recheck: true };
  } finally {
    clearTimeout(timer);
  }
}

SMTP के बिना, अधिकांश वास्तविक addresses unknown के रूप में वापस आते हैं और उन्हें recheck flag मिलता है। account सहेजे जाने के बाद, background job recheck चिह्नित प्रत्येक record के लिए SMTP चालू करके उसी endpoint को call करता है। Node.js ट्यूटोरियल official SDK सहित, अधिक पूर्ण setup की पूरी प्रक्रिया बताता है। यही request Python या HTTP client वाली किसी भी language से काम करती है।

दर सीमाएँ, कैशिंग और लागत

एक रीयल-टाइम जाँच आपके साइनअप पथ पर होती है, इसलिए इसकी सीमाएँ आपकी सीमाएँ बन जाती हैं। इनके लिए पहले से योजना बनाएँ।

दर सीमाएँ। BillionVerify प्रति-अकाउंट सीमाओं के माध्यम से अपनी क्षमता सुरक्षित रखता है। जब आप इनमें से किसी सीमा तक पहुँचते हैं, तो API 1003 कोड और Retry-After हेडर के साथ HTTP 429 लौटाती है। कुछ समय रुककर फिर प्रयास करें, और अपना fail-open नियम लागू रखें, ताकि कोई सीमा वास्तविक उपयोगकर्ता को कभी न रोके।

कैशिंग। परिणाम कैश किए जाते हैं, इसलिए दोबारा की गई जाँचें तेज़ी से पूरी होती हैं। पिछले 24 घंटों में आपके अकाउंट द्वारा सत्यापित पते की दोबारा जाँच निःशुल्क है। force_refresh: true का उपयोग केवल तब करें जब आपको वास्तव में नया उत्तर चाहिए, क्योंकि यह कैश को छोड़ देता है और नई जाँच की तरह शुल्क लिया जाता है।

लागत। एकल जाँच में सामान्यतः 1 क्रेडिट लगता है, जिसे credits_used में दिखाया जाता है। हर unknown परिणाम निःशुल्क है, और सिंटैक्स विफलताएँ भी निःशुल्क हैं। हर कीस्ट्रोक पर जाँच करने के बजाय सबमिट करते समय सत्यापित करें, और हाल ही में सत्यापित पते की दोबारा जाँच न करें। BillionVerify आपको हर दिन लॉग इन करने पर 20 निःशुल्क क्रेडिट देता है, जो महीने में अधिकतम 600 तक होते हैं—यह किसी integration को बनाने और परीक्षण करने के लिए पर्याप्त है। सशुल्क क्रेडिट पैक मूल्य निर्धारण पृष्ठ पर सूचीबद्ध हैं।

फ़ॉर्म से आगे: बैच, फ़ाइलें और वेबहुक्स

रीयल-टाइम सत्यापन नए पतों को एक-एक करके कवर करता है। बाकी सभी ज़रूरतों के लिए, उसी API में अन्य प्रवेश बिंदु भी हैं:

• छोटे बैच। POST /verify/bulk एक अनुरोध में अधिकतम 50 पतों की जाँच करता है, जो CRM सिंक या इम्पोर्ट स्क्रीन के लिए उपयुक्त है।
• बड़ी सूचियाँ। POST /verify/file CSV, TXT या XLSX फ़ाइल स्वीकार करता है और उसे बैकग्राउंड में प्रोसेस करता है।
• वेबहुक्स। किसी फ़ाइल जॉब को बार-बार जाँचने के बजाय, file.completed और file.failed इवेंट के लिए एक वेबहुक रजिस्टर करें। सिग्नेचर जाँच और रीट्राई के लिए ईमेल सत्यापन वेबहुक्स की गाइड देखें।
• केवल डिस्पोज़ेबल जाँच। POST /verify/disposable केवल डिस्पोज़ेबल होने के प्रश्न का उत्तर देता है और क्रेडिट का उपयोग नहीं करता।

एक सामान्य सेटअप: हर फ़ॉर्म पर रीयल-टाइम जाँच, recheck के रूप में चिह्नित रिकॉर्ड के लिए रात में बैच, और बड़े अभियानों से पहले फ़ाइल जॉब।

रियल-टाइम Email Validation चेकलिस्ट

शिप करने से पहले, इस सूची की जाँच करें:

• API key server पर रहती है, कभी भी browser में नहीं।
• API call से पहले syntax की स्थानीय रूप से जाँच की जाती है।
• request path में check_smtp: false और आपकी latency budget के अनुरूप timeout का उपयोग होता है।
• invalid और disposable के लिए स्पष्ट, विशिष्ट error messages हैं।
• unknown, catchall और timeouts fail open होते हैं और दोबारा जाँच के लिए queue में भेजे जाते हैं।
• domain_suggestion typo hint को सक्रिय करता है।
• 429 responses बिना users को block किए back off करते हैं।
• Results को user record के साथ store किया जाता है, ताकि बाद में bounce rates मापी जा सकें।

सामान्य प्रश्न

रीयल-टाइम ईमेल सत्यापन API क्या है?

रीयल-टाइम ईमेल सत्यापन API तब किसी एक ईमेल पते की जाँच करता है, जब उपयोगकर्ता कोई फ़ॉर्म सबमिट करता है, और एक सेकंड के अंश में परिणाम देता है। यह सिंटैक्स, डोमेन, MX, डिस्पोज़ेबल, भूमिका और catch-all जाँच करता है, साथ ही वैकल्पिक SMTP मेलबॉक्स जाँच भी कर सकता है, ताकि आपका ऐप उस पते को आपके डेटाबेस तक पहुँचने से पहले स्वीकार, ब्लॉक या फ़्लैग कर सके।

रीयल-टाइम ईमेल सत्यापन, बल्क सत्यापन से कैसे अलग है?

रीयल-टाइम ईमेल सत्यापन उपयोगकर्ता के अनुरोध के दौरान एक बार में एक पते की जाँच करता है और इसे तेज़ी से परिणाम देना होता है। बल्क सत्यापन पूरी सूची की पृष्ठभूमि में जाँच करता है और इसमें अधिक समय लग सकता है। नए डेटा को साफ़ रखने के लिए रीयल-टाइम जाँच और आपके मौजूदा डेटा को साफ़ करने के लिए बल्क जाँच का उपयोग करें।

क्या मुझे हर साइनअप पर SMTP जाँच चलानी चाहिए?

यह आपके latency बजट पर निर्भर करता है। SMTP जाँच ही मेलबॉक्स की पुष्टि करती है, इसलिए इसके बिना अधिकांश वास्तविक पते unknown के रूप में लौटते हैं। यदि आप 2–3 सेकंड प्रतीक्षा कर सकते हैं, तो सबमिट करते समय इसे timeout के साथ चलाएँ। यदि ऐसा संभव नहीं है, तो check_smtp: false के साथ तेज़ जाँच चलाएँ और SMTP जाँच पृष्ठभूमि जॉब में करें।

catch-all और unknown परिणामों के साथ मुझे क्या करना चाहिए?

उन्हें स्वीकार करें और बाद में फिर से जाँच करें। catch-all डोमेन हर पते को स्वीकार करता है, इसलिए मेलबॉक्स जाँच यह सिद्ध नहीं कर सकती कि इनबॉक्स मौजूद है, और unknown परिणाम का अर्थ है कि जाँच पूरी नहीं हो सकी। इन उपयोगकर्ताओं को ब्लॉक करने से वास्तविक साइनअप खो सकते हैं; उन्हें टैग करके दोबारा जाँचने से रूपांतरण को नुकसान पहुँचाए बिना आपका डेटा साफ़ रहता है।

क्या मैं ब्राउज़र से ईमेल चेकर API कॉल कर सकता हूँ?

नहीं। इससे आपकी API key उजागर हो जाएगी। API को अपने बैकएंड से कॉल करें और केवल निर्णय लौटाएँ।

रीयल-टाइम ईमेल सत्यापन कितना तेज़ है?

BillionVerify में कैश किए गए परिणाम 200 ms से कम समय में लौटते हैं और पूरी SMTP जाँच में औसतन 1–3 सेकंड लगते हैं। इसलिए SMTP के बिना तेज़ जाँच अनुरोध पथ में और SMTP जाँच पृष्ठभूमि में होनी चाहिए।

ईमेल सत्यापन API की लागत कितनी है?

BillionVerify में, एकल जाँच में सामान्यतः 1 क्रेडिट लगता है और हर unknown परिणाम निःशुल्क होता है। आपको हर दिन लॉग इन करने पर 20 निःशुल्क क्रेडिट मिलते हैं, जो महीने में अधिकतम 600 तक हो सकते हैं, और सशुल्क क्रेडिट पैक pricing पेज पर उपलब्ध हैं। force_refresh कैश को छोड़ देता है और नई जाँच की तरह बिल किया जाता है।

रीयल-टाइम में ईमेल सत्यापित करना शुरू करें

रीयल-टाइम ईमेल सत्यापन का अर्थ है कम बाउंस, कम नकली खाते और टाइपो के कारण खोए हुए कम उपयोगकर्ता। अनुरोध पथ में तेज़ जाँच रखें, धीमी जाँच को बैकग्राउंड में भेजें, और स्पष्ट विफलताओं को रोकने दें, जबकि अनिश्चित परिणाम आगे बढ़ें। एक निःशुल्क BillionVerify खाता बनाएँ, API कुंजी प्राप्त करें और ऊपर दिए गए दस्तावेज़ों से अपना पहला ईमेल सत्यापन API कॉल करें।