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

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

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

पाँच निर्णय

result वह फ़ील्ड है जिस पर निर्णय लेना है।
valid: पता मौजूद है और मेल स्वीकार करता है। भेजें।
neutral: किसी भी तरफ़ पुष्टि नहीं हो सकी, आमतौर पर इसलिए कि प्राप्तकर्ता डोमेन हर रेसिपिएंट के लिए एक ही तरह से जवाब देता है। भेजना उचित है; 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 key नहीं ले सकता। किसी भी ऑटोमेटेड काम के लिए POST फ़ॉर्म का उपयोग करें।

त्रुटियाँ

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

अगले कदम

संबंधित संसाधन

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