ईमेल पता लुकअप

एक फ़ील्ड जिस पर पते का फ़ैसला हो।

एक पता भेजें और एक निर्णय पाएँ: valid, neutral, risky, undeliverable, या typo। साथ में, 0 से 100 तक का कॉन्फ़िडेंस स्कोर, पते की प्रकृति बताने वाले फ़्लैग, और गलत स्पेलिंग वाला पता जो असल में होना चाहिए था। एक रिक्वेस्ट, कोई लिस्ट अपलोड नहीं और कोई जॉब पोल नहीं।

email.ts
200
const answer = await bird.lookup.email({
  email: "aisha.khan@exampel.com",
});

console.log(answer.result, answer.delivery_confidence);
// → "typo" 31
console.log(answer.did_you_mean);
// → "aisha.khan@example.com"
console.log(answer.valid, answer.flags);
// → true []

एक निर्णय जिस पर आप ब्रांच कर सकें।

कोई प्रतिशत नहीं जिसके लिए आपको थ्रेशोल्ड चुनना पड़े।

ईमेल पता लुकअप Bird Lookup API की दो ऑपरेशनों में से एक है। अपना लॉजिक लिखने के लिए सही फ़ील्ड result है, क्योंकि यह सिंटैक्स, डोमेन, मेलबॉक्स और रेप्युटेशन जाँचों को पहले से पाँच परिणामों में सीमित कर देती है। delivery_confidence उन मामलों के लिए है जहाँ आप रोकने के बजाय ग्रेड करना चाहते हैं, जैसे किसी जोखिमपूर्ण साइनअप को अस्वीकार करने के बजाय समीक्षा के लिए रोकना। आप जो पता भेजते हैं वही वापस आता है: लोकल पार्ट केस-सेंसिटिव है और लोअरकेस नहीं किया जाता, और डिस्प्ले-नेम फ़ॉर्म पार्स करने के बजाय अस्वीकार कर दिया जाता है।

छह फ़ील्ड, और हर एक किसके लिए है।

ये सभी एक ही रिक्वेस्ट के साथ आती हैं।

  1. 01

    result, निर्णय।

    valid भेजने के लिए सुरक्षित है। neutral डिलीवर हो सकता है, कोई विशेष बात नहीं। risky शायद मेल स्वीकार करेगा और इसमें संकोच की वजह है। undeliverable मेल प्राप्त नहीं कर सकता। typo किसी असली पते की गलत स्पेलिंग जैसा दिखता है।

  2. 02

    reason, केवल जहाँ लागू हो।

    invalid_syntax, invalid_domain, या invalid_recipient — बताता है कि पता तीन में से किस जाँच में विफल हुआ। यह केवल undeliverable निर्णय पर मौजूद होता है और किसी अन्य पर नहीं, इसलिए इसकी अनुपस्थिति भी एक जानकारी है।

  3. 03

    did_you_mean, सुधार।

    वह पता जो typo किसी असली पते की गलत स्पेलिंग जैसा दिखता है, टाइप करने वाले व्यक्ति के सामने रखने के लिए तैयार। साइनअप फ़ॉर्म जो सुधार पेश करता है, वह अकाउंट को बचा लेता है, बजाय इसके कि वह किसी अनदेखे बाउंस में खो जाए।

  4. 04

    delivery_confidence, 0 से 100।

    फ़ैसले के बजाय एक ग्रेड, और यही इसे result से अलग बनाता है। दो पतों का निर्णय एक हो सकता है लेकिन इस नंबर पर वे बहुत दूर हो सकते हैं, और उस अंतर में समीक्षा कतार आती है।

  5. 05

    flags, पते का प्रकार।

    role साझा मेलबॉक्स जैसे info या support के लिए, disposable अस्थायी प्रोवाइडर के लिए, और free_provider उपभोक्ता मेलबॉक्स के लिए। तीनों सही बनावट वाले पते हैं जो मेल स्वीकार करते हैं, इसलिए ये निर्णय नहीं बल्कि फ़्लैग हैं।

  6. 06

    valid, संकीर्ण बूलियन।

    क्या पता सही बनावट का है और उसका डोमेन मेल प्राप्त कर सकता है। यह मेलबॉक्स के बारे में कुछ नहीं कहता, इसलिए बहुत से ऐसे पतों के लिए भी true है जिनका निर्णय risky है। जब आपका मतलब निर्णय से हो, तो result पढ़ें।

पाँच परिणाम, चार काम।

undeliverable को अस्वीकार करें, typo पर सुधार पेश करें, risky पते को समीक्षा के लिए रोकें, और बाकी स्वीकार करें। यही पूरा इंटीग्रेशन है, और यह उस फ़ॉर्म के सबमिट हैंडलर में समा जाता है जो पता लेता है।

verdicts.ts
200
const answer = await bird.lookup.email({
  email: "info@example.com",
});

if (answer.result === "undeliverable") {
  // reason is present on this verdict and no other.
  reject(answer.reason);
} else if (answer.result === "typo") {
  suggest(answer.did_you_mean);
} else if (answer.result === "risky") {
  // A role or disposable address is well formed and still a poor signup.
  review(answer.flags);
} else {
  accept(answer.delivery_confidence);
}

इसकी लागत, और यह क्या नहीं है।

प्रति रिक्वेस्ट एक पता, और हर निर्णय बिल होता है, undeliverable भी, क्योंकि उस निर्णय तक पहुँचना ही काम है। कोई बैच फ़ॉर्म नहीं और कोई लिस्ट अपलोड नहीं। वही Idempotency-Key वाली फिर से प्रयास करना रिक्वेस्ट वही निर्णय दोहराती है जिसके लिए आपने पहले भुगतान किया था। Lookup सप्रेशन लिस्ट भी नहीं है: यह बताता है कि भेजने से पहले पता कैसा दिखता है, जबकि सप्रेशन रिकॉर्ड करती है कि भेजने के बाद क्या हुआ, और एक अच्छा सेंडिंग सेटअप दोनों का उपयोग करता है।

डॉक्स में और गहराई से जानें।

ईमेल पता लुक अप करें रिक्वेस्ट और रिस्पॉन्स की हर फ़ील्ड को समझाता है। Lookup ओवरव्यू दोनों ऑपरेशनों को एक पेज में कवर करता है, अनुरोध दर सीमित करना लुकअप ग्रुप का दस्तावेज़ है, और आइडेम्पोटेंसी बताती है कि दोहराए गए निर्णय की लागत क्या है।

ईमेल पते के सवाल, उत्तर सहित।

निर्णय, फ़्लैग, कॉन्फ़िडेंस स्कोर, और सप्रेशन कहाँ फ़िट होती है।

ईमेल एड्रेस लुकअप क्या बताता है?
क्या वह एड्रेस मेल स्वीकार करेगा। एक कॉल result में फ़ैसला, एक delivery_confidence स्कोर, एड्रेस के प्रकार बताने वाले फ़्लैग, और अगर एड्रेस गलत लिखा लगे तो एक सुधार लौटाता है।
पाँच फ़ैसले (verdicts) कौन-कौन से हैं?
valid का मतलब है एड्रेस मौजूद है और मेल स्वीकार करता है, तो भेजें। neutral का मतलब है किसी भी तरफ़ पुष्टि नहीं हो सकी, आमतौर पर इसलिए क्योंकि प्राप्तकर्ता डोमेन हर recipient को एक ही तरह जवाब देता है। risky का मतलब है शायद मेल स्वीकार करता है लेकिन बाउंस या शिकायत की संभावना औसत से ज़्यादा है। undeliverable का मतलब है मेल स्वीकार नहीं करता। typo का मतलब है एड्रेस गलत लिखा लगता है।
कोई एड्रेस undeliverable क्यों होता है?
reason बताता है कि तीन में से क्या गड़बड़ है: invalid_syntax जब एड्रेस का फ़ॉर्मेट ग़लत हो, invalid_domain जब डोमेन मेल ही स्वीकार नहीं करता, और invalid_recipient जब डोमेन मेल स्वीकार करता है लेकिन यह मेलबॉक्स मौजूद नहीं है।
typo verdict मिलने पर मुझे क्या करना चाहिए?
जिसने मूल एड्रेस टाइप किया उसे did_you_mean दिखाएँ, बिना पूछे उस पर भेजने की जगह। सुधार एक अनुमान है, और जो एड्रेस उनका मतलब था वह दोनों में से कोई भी नहीं हो सकता।
delivery_confidence, result से कैसे अलग है?
यह 0 (निश्चित रूप से डिलीवर नहीं होगा) से 100 (निश्चित रूप से डिलीवर होगा) तक चलता है। एक ही स्कोर अलग-अलग कारणों से अलग-अलग verdicts के अंतर्गत आ सकता है, इसलिए इसे result की जगह नहीं बल्कि उसके साथ पढ़ें। जब आपको हर verdict पर एक ही threshold चाहिए — भविष्य में जोड़े गए verdicts सहित — तो यही वह फ़ील्ड है जिस पर भरोसा करें।
एक valid फ़ील्ड भी है। क्या वह valid verdict ही है?
नहीं, और यह अंतर मायने रखता है। valid फ़ील्ड संकीर्ण है: यह सिर्फ़ बताता है कि एड्रेस सही फ़ॉर्मेट में है और उसका डोमेन मेल प्राप्त करने के लिए सेट अप है। यह मेलबॉक्स के बारे में कुछ नहीं कहता, इसलिए एक एड्रेस जिसका डोमेन काम कर रहा हो लेकिन ऐसा मेलबॉक्स न हो, वहाँ true होगा लेकिन result में undeliverable।
फ़्लैग्स का क्या मतलब है?
role का मतलब है एड्रेस किसी व्यक्ति के बजाय किसी फ़ंक्शन के नाम पर है, जैसे support@ या info@, इसलिए रिप्लाई और सहमति अस्पष्ट हैं और शिकायत की संभावना ज़्यादा है। disposable का मतलब है अस्थायी-एड्रेस प्रदाता, इसलिए एड्रेस आमतौर पर जल्द ही बंद हो जाएगा। free_provider का मतलब है उपभोक्ता मेलबॉक्स प्रदाता जैसे Gmail या Outlook.com, जो सिर्फ़ तब संकेत है जब आपको व्यावसायिक एड्रेस की उम्मीद थी।
एड्रेस कैसे लिखना चाहिए?
सादा एड्रेस भेजें, ठीक वैसे ही जैसे आपके पास है। डिस्प्ले-नेम फ़ॉर्म — जिसमें नाम आगे हो और एड्रेस एंगल ब्रैकेट में — रिजेक्ट किया जाता है, अनरैप नहीं, क्योंकि अनरैप करने पर वह एड्रेस लुकअप होगा जो आपने भेजा नहीं। @ से पहले का हिस्सा जैसा लिखा है वैसा ही पास होता है, और उसका केस बदलने से आपको मिलने वाला delivery_confidence बदल सकता है।
क्या पहले से बाउंस हो चुके एड्रेस पर भेजना रोकने के लिए मुझे Lookup चाहिए?
नहीं। Suppressions यह काम अपने आप और मुफ़्त में करता है, उन एड्रेस के लिए जो पहले बाउंस या शिकायत कर चुके हैं। Lookup का उपयोग उस एड्रेस के लिए करें जिस पर आपने अभी तक कुछ नहीं भेजा — साइनअप पर या किसी लीड पर कार्रवाई करने से पहले।

व्यवहार में लाएँ।

इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।

इम्प्लीमेंटेशन ब्रीफ़ पाएँ

किसी पते को अपनी सूची में आने से पहले जाँचें।

आपके साइनअप हैंडलर में एक कॉल बाउंस, डिस्पोज़ेबल अकाउंट और गलत स्पेलिंग को डेटाबेस से बाहर रखती है।

एक चैनल से शुरुआत करें।
तैयार होने पर बाकी जोड़ें।

एक test API key तुरंत आपकी है। जब आप payment method जोड़ते हैं और sender verify करते हैं, तब production अनलॉक हो जाता है।

Claude Code, Cursor या Codex इस्तेमाल कर रहे हैं? एक setup prompt कॉपी करें और आपका agent आपके लिए Bird CLI और skills इंस्टॉल कर देगा। अपना चुनें:

Cursor