Sign inGet Started

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

एक ही कॉल से पता चलता है कि कोई पता मेल स्वीकार करेगा या नहीं। इसे साइनअप के समय या किसी लीड पर कार्रवाई से पहले इस्तेमाल करें, ताकि बाउंस होने वाले पते शुरू से ही आपकी भेजी जाने वाली सूची में न आएँ। यहाँ की हर चीज़ के लिए lookup स्कोप वाली API कुंजी चाहिए।

एक पता लुकअप करें

const answer = await bird.lookup.email({ email: "aisha.khan@example.com" });
// result is an open vocabulary; delivery_confidence is always comparable.
console.log(answer.result, answer.delivery_confidence);

एक बैच लुकअप करें

एक ही अनुरोध में 1,000 तक पतों का आकलन करने के लिए POST /v1/lookup/email/batch का उपयोग करें:

कोड उदाहरण
curl -X POST "https://us1.platform.bird.com/v1/lookup/email/batch" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"emails":["aisha.khan@example.com","not-an-email"]}'

प्रतिक्रिया की data ऐरे में हर इनपुट के लिए एक आकलन होता है, उसी क्रम में जिसमें आपने उन्हें भेजा था। गलत फ़ॉर्मेट वाले पतों को भी अलग-अलग आकलन मिलते हैं। दोहराए गए पते अलग प्रविष्टियाँ बने रहते हैं, और उत्तर दी गई हर प्रविष्टि का शुल्क लगता है। आगे-पीछे की खाली जगह हटा दी जाती है और अक्षरों का केस वैसा ही रहता है।

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

पता कैसे लिखें

सिर्फ़ पता भेजें, ठीक वैसा ही जैसा आपके पास है। एकल-पता लुकअप Aisha <aisha@example.com> जैसे डिस्प्ले-नाम वाले रूपों को खोलकर पढ़ने के बजाय अस्वीकार कर देता है। बैच लुकअप भेजी गई हर स्ट्रिंग के लिए एक आकलन लौटाते हैं।

@ से पहले वाला भाग लोअरकेस किए बिना, जैसा लिखा है वैसा ही आगे भेजा जाता है, और email फ़ील्ड वही केस बनाए रखता है। बैच प्रतिक्रियाएँ आगे-पीछे की खाली जगह हटा देती हैं; इसलिए हर परिणाम को उसी स्थान वाले इनपुट से मिलाएँ। पते को पहले नॉर्मलाइज़ किए बिना उसी केस में भेजें जिसमें वह आपके पास है: result आम तौर पर दोनों तरह एक जैसा होता है, लेकिन delivery_confidence हमेशा एक जैसा नहीं होता, इसलिए केस बदलने से आपको मिलने वाला उत्तर बदल सकता है।

पाँच निर्णय

result वह फ़ील्ड है जिसके आधार पर आपको निर्णय लेना है।

valid: पता मौजूद है और मेल स्वीकार करता है। भेजें।

neutral: इसकी पुष्टि किसी भी तरह नहीं हो सकी, आमतौर पर इसलिए कि प्राप्त करने वाला डोमेन हर प्राप्तकर्ता को एक ही तरह से जवाब देता है। भेजना उचित है; न्यूट्रल पता खराब पता नहीं है, बस उसके बारे में जवाब नहीं मिल सकता।

risky: यह संभवतः मेल स्वीकार करता है, लेकिन इसके बाउंस होने या शिकायत आने की संभावना ज़्यादातर पतों से अधिक है। रोल पते, डिस्पोज़ेबल पते और कम प्रतिष्ठा वाले पते इसी श्रेणी में आते हैं। भेजना है या नहीं, यह इस पर निर्भर करता है कि आप शिकायतें कितनी सह सकते हैं, और flags बताता है कि जोखिम किस प्रकार का है।

undeliverable: यह मेल स्वीकार नहीं करता। न भेजें। reason कारण बताता है: गलत फ़ॉर्मैट वाले पते के लिए invalid_syntax, जब डोमेन बिल्कुल भी मेल स्वीकार नहीं करता तब invalid_domain, और जब डोमेन मेल स्वीकार करता है लेकिन यह मेलबॉक्स मौजूद नहीं है तब invalid_recipient।

typo: पते की वर्तनी गलत लगती है, और did_you_mean में सुधार दिया होता है। बिना पूछे सुधरे हुए पते पर भेजने के बजाय, मूल पता टाइप करने वाले व्यक्ति को यह सुधार सुझाएँ: यह एक अनुमान है, और हो सकता है कि उनका इच्छित पता इन दोनों में से कोई भी न हो।

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

कॉन्फ़िडेंस को निर्णय के साथ पढ़ें, उसकी जगह नहीं

delivery_confidence का मान 0 (निश्चित रूप से डिलीवर नहीं होगा) से 100 (निश्चित रूप से डिलीवर होगा) तक होता है। एक ही स्कोर अलग-अलग कारणों से neutral या risky के साथ आ सकता है, इसलिए यह result का विकल्प नहीं, बल्कि एक दूसरी राय है। जब आप हर निर्णय पर, बाद में जोड़े गए निर्णयों सहित, एक ही सीमा लागू करना चाहें, तब इसी फ़ील्ड पर भरोसा करें।

valid में प्रदाता का वैधता आकलन होता है। किसी अमान्य प्राप्तकर्ता के लिए valid: false हो सकता है, भले ही उसका डोमेन मेल स्वीकार करता हो। भेजने का निर्णय लेते समय result और delivery_confidence दोनों को साथ देखें; valid: true डिलीवरी की गारंटी नहीं देता।

फ़्लैग बताते हैं कि पता किस प्रकार का है

जब कोई उल्लेखनीय बात लागू नहीं होती, तो flags खाली रहता है। इसके तीन मान परिभाषित हैं, और यह एक खुली सूची है।

role का मतलब है कि पता किसी व्यक्ति के बजाय किसी काम या भूमिका का है, जैसे support@ या info@। ऐसे पते पर जवाब कौन देगा और सहमति किसकी है, यह स्पष्ट नहीं होता, और शिकायतों की संभावना अधिक होती है।

disposable का मतलब है कि पता अस्थायी पते देने वाले प्रदाता का है, इसलिए यह आम तौर पर कुछ समय बाद मौजूद नहीं रहेगा।

free_provider का मतलब है कि पता Gmail या Outlook.com जैसे उपभोक्ता मेलबॉक्स प्रदाता का है। उपभोक्ता मेल के लिए यह सामान्य है, और यह तभी संकेत है जब आप किसी व्यावसायिक पते की अपेक्षा कर रहे थे।

दो बार भुगतान किए बिना फिर से प्रयास करें

हर उत्तर दिए गए पते का बिल बनता है, undeliverable भी शामिल है, क्योंकि आपने उसी उत्तर के लिए भुगतान किया है और उसी से आप बाउंस से बचे। Idempotency-Key भेजें, ताकि फिर से प्रयास करने पर दूसरा निर्णय खरीदने के बजाय सहेजा गया निर्णय दोबारा लौटाया जाए। Idempotency देखें।

GET रूप पते को URL में रखता है, इसलिए इसमें idempotency कुंजी नहीं भेजी जा सकती। किसी भी स्वचालित काम के लिए POST रूप का उपयोग करें।

त्रुटियाँ

कोडक्या हुआ
E22003एकल-पता lookup को अमान्य ईमेल पता मिला। कोई शुल्क नहीं लिया गया। बैच lookup गलत स्वरूप वाली स्ट्रिंग का अलग-अलग आकलन करते हैं और उन आकलनों का बिल बनाते हैं।
E22001संगठन के वॉलेट में लुकअप के लिए पर्याप्त राशि नहीं है। वॉलेट में राशि जोड़ें और फिर से प्रयास करें। कोई शुल्क नहीं लिया गया।
E22002लुकअप अस्थायी रूप से उपलब्ध नहीं है। बैकऑफ़ के साथ फिर से प्रयास करें। कोई शुल्क नहीं लिया गया।

अगले कदम

इस विषय के लिए दस्तावेज़, गाइड और उदाहरणों के साथ आगे बढ़ें।