Lookup API FAQ

Lookup भेजने से पहले किसी प्राप्तकर्ता के बारे में सवालों के जवाब देता है। इसे एक फ़ोन नंबर दें और यह बताता है कि नंबर क्या है: सर्विंग नेटवर्क, देश, क्या नेटवर्क बदला है, और लाइन का प्रकार। इसे एक ईमेल एड्रेस दें और यह बताता है कि उस एड्रेस पर भेजना सार्थक है या नहीं।

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

हर लुकअप एक रिक्वेस्ट और एक जवाब है। कुछ बनाने, पोल करने, या बाद में साफ़ करने की ज़रूरत नहीं। Go, TypeScript, Python, और PHP SDK में टाइप्ड मेथड उपलब्ध हैं, और bird lookup phone-number तथा bird lookup email CLI से यही काम करते हैं।

हाँ। डैशबोर्ड में Lookup पेज वही दोनों ऑपरेशन एक-एक करके चलाता है, जो बिल्ड करने से पहले जवाब कैसा दिखता है यह देखने का सबसे तेज़ तरीक़ा है।

lookup स्कोप वाली एक API कुंजी, और एक ऑर्गनाइज़ेशन वॉलेट जो शुल्क वहन कर सके। क़ीमत प्रति क्वेरी है, कोई सीट शुल्क नहीं, इसलिए पहले कोई प्लान चुनने की ज़रूरत नहीं।

जब आप भेजने से पहले फ़ैसला लेना चाहें: साइनअप पर गेटिंग, कार्रवाई से पहले लीड की जाँच, या लाइन टाइप के अनुसार मैसेज को अलग तरह से रूट करना। बिना कुछ भेजे आपको एक ऐसा जवाब मिलता है जिस पर कार्रवाई कर सकें।

प्रति क्वेरी। हर लुकअप का शुल्क आपके संगठन के वॉलेट से लिया जाता है। फ़ोन नंबर लुकअप में बेस लुकअप के लिए एक बार शुल्क लगता है, साथ ही हर उस प्रॉपर्टी के लिए एक अतिरिक्त शुल्क जो उत्तर के साथ आती है। ईमेल एड्रेस लुकअप में प्रति उत्तर दिए गए एड्रेस एक बार शुल्क लगता है। कोई सीट शुल्क नहीं है।

Lookup प्राइसिंग पेज पर बेस लुकअप, हर प्रॉपर्टी और ईमेल एड्रेस लुकअप की दर सूचीबद्ध है। दरें प्रॉपर्टी के अनुसार भिन्न होती हैं, क्योंकि हर एक अलग डेटा स्रोत से आती है।

नहीं। प्रॉपर्टी का शुल्क तभी लगता है जब वह डिलीवर होती है। जिसका उत्तर नहीं मिल सका वह एक स्टेटस के साथ लौटती है और आपको कुछ नहीं लगता, और बेस लुकअप फिर भी उसके साथ सर्व किया जाता है।

कुछ भी बिल नहीं होता। गलत फ़ॉर्मेट का नंबर, अस्वीकृत एड्रेस, और अनुपलब्ध डेटा स्रोत — इनमें से किसी का कोई शुल्क नहीं लगता।

हाँ। हर उत्तर दिया गया एड्रेस बिल होता है, अनडिलीवरेबल भी शामिल। यही वह उत्तर है जो आपने माँगा था, और यही वह है जो आपको बाउंस से बचाता है।

नहीं, अगर आप Idempotency-Key भेजते हैं। उसी अनुरोध की पुनरावृत्ति नया लुकअप चलाने के बजाय संग्रहित उत्तर दोबारा लौटाती है। GET फ़ॉर्म, जो नंबर या एड्रेस URL में रखते हैं, आइडेम्पोटेंसी की नहीं ले जा सकते, इसलिए ऑटोमेटेड कार्यों के लिए POST का उपयोग करें।

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

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

write लेवल पर lookup स्कोप। इसमें कोई read लेवल नहीं है: हर लुकअप endpoint को write चाहिए, यहाँ तक कि वह रिज़ल्ट लाने के लिए भी जिसके लिए आप पहले भुगतान कर चुके हैं। Owners और admins के पास यह डिफ़ॉल्ट रूप से होता है, members के पास नहीं।

चार जो मायने रखती हैं। E22000 जब नंबर अंतरराष्ट्रीय फ़ॉर्मेट में मान्य नहीं है, E22003 जब एड्रेस मान्य ईमेल एड्रेस नहीं है, E22001 जब ऑर्गनाइज़ेशन का वॉलेट लुकअप का शुल्क वहन नहीं कर सकता, और E22002 जब Lookup अस्थायी रूप से अनुपलब्ध है। इनमें से कोई भी शुल्क नहीं लेती।

नहीं। फ़ेल होने वाली प्रॉपर्टी अपने ब्लॉक में एक status के रूप में लौटती है, और बेस लुकअप उसके साथ सर्व होता है। सिर्फ़ बेस लुकअप फ़ेल होने पर रिक्वेस्ट फ़ेल होती है, और तब यह पूरी तरह फ़ेल होती है — एक आधा-ख़ाली जवाब लौटाने की बजाय जिसे जाँचकर पता करना पड़े कि वह ख़ाली था।

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

पहले कंट्री कॉलिंग कोड, फिर राष्ट्रीय नंबर। शुरू में प्लस वैकल्पिक है और 00 भी उसकी जगह काम करता है, इसलिए +31612345678, 31612345678 और 0031612345678 सभी एक ही नंबर हैं।

किसी एक देश के भीतर डायलिंग के लिए लिखा गया नंबर, बिना कंट्री कोड के, अनुमान लगाने के बजाय E22000 लौटाता है। 0612345678 के आगे कंट्री कोड जोड़ने से कहीं और का एक असली नंबर बन जाएगा और आपसे उसे लुकअप करने का शुल्क लिया जाएगा।

mobile, fixed_line, voip, toll_free, premium_rate, satellite, pager, payphone, m2m, service, other, या unknown। unknown का मतलब है कि कैरियर प्लेटफ़ॉर्म के पास उस रेंज का कोई वर्गीकरण नहीं है, और other का मतलब है कि उसके पास एक है जिसका यहाँ कोई समतुल्य नहीं है। अधिक सटीक जानकारी के लिए आवंटित सेवा की classification प्रॉपर्टी का अनुरोध करें।

network_info वह नेटवर्क है जो वर्तमान में नंबर को सर्व कर रहा है और original_network_info वह नेटवर्क है जिसने उसकी रेंज जारी की थी। एक बार नंबर पोर्ट होने पर दोनों अलग-अलग होते हैं, और उस स्थिति में flags में ported होता है। जब आपको तारीख और पूरा रिकॉर्ड भी चाहिए तो porting प्रॉपर्टी का अनुरोध करें।

क्योंकि वह नंबर किसी एक देश से संबंधित नहीं है, जैसा कि नॉन-जियोग्राफ़िक रेंज के साथ होता है। बिना मान वाले फ़ील्ड null लौटाने के बजाय हटा दिए जाते हैं, इसलिए उत्तर में मौजूद हर फ़ील्ड रिज़ॉल्व किया गया था।

नहीं। लुकअप कभी भी नंबर से संपर्क नहीं करता। यह कैरियर और नंबर-इंटेलिजेंस डेटा पढ़ता है, और presence तथा roaming प्रॉपर्टीज़ उस नेटवर्क से पूछताछ करती हैं जिस पर नंबर रजिस्टर्ड है, इसलिए न कोई रिंग होती है और न हैंडसेट पर कुछ आता है।

छह, type में नामित। classification रेंज की सटीक आवंटित सेवा के लिए, porting नंबर आखिरी बार कब नेटवर्क बदला और रिकॉर्ड पर हर बदलाव के लिए, presence नंबर अभी नेटवर्क पर लाइव है या नहीं इसके लिए, roaming नंबर रोमिंग पर है या नहीं और किस नेटवर्क पर है इसके लिए, sim_swap SIM आखिरी बार कब बदली इसके लिए, और score 0 से 100 तक का विश्वसनीयता स्कोर।

हाँ। classification, porting और score संग्रहित डेटा पढ़ती हैं और जल्दी लौटती हैं। presence, roaming और sim_swap लाइव नेटवर्क तक पहुँचती हैं, इसलिए वे धीमी हैं और उनकी कवरेज ऑपरेटर के अनुसार भिन्न होती है। इन तीनों के लिए संग्रहित प्रॉपर्टीज़ की तुलना में unavailable या inconclusive अधिक बार मिलने की उम्मीद रखें।

ok का मतलब है कि प्रॉपर्टी का उत्तर मिला, उसका मान प्रतिक्रिया में है, और बिल किया गया। unavailable का मतलब है कि कोई उत्तर नहीं आया, और बिल नहीं किया गया। inconclusive का मतलब है कि उत्तर आया लेकिन वह प्रॉपर्टी को रिज़ॉल्व नहीं करता, जो एक वास्तविक खोज है, और इसका भी बिल नहीं किया गया।

हाँ, status एक ओपन वोकैबुलरी है। ok पर ब्रांच करें और बाकी सब को उत्तर नहीं मिला मानें, और आपका कोड सही रहेगा चाहे वोकैबुलरी कितनी भी बढ़े।

porting आपको तारीख और पूरा इतिहास देता है जबकि बेस लुकअप का ported फ़्लैग केवल यह बताता है कि कोई बदलाव कभी हुआ था या नहीं। classification एक अलग स्रोत से, व्यापक वोकैबुलरी के साथ, line_type को सटीक आवंटित सेवा में रिज़ॉल्व करता है, और अलग से रिपोर्ट किया जाता है ताकि आप दोनों को हमेशा अलग पहचान सकें।

क्योंकि नेटवर्क ने सटीक आँकड़ा जारी नहीं किया। sim_swap जब केवल एक रीसेंसी बैंड ज्ञात हो तब last_swapped_at के बजाय min_days और max_days लौटाता है। porting भी कुछ ऐसा ही करता है: जब रजिस्ट्री बदलाव की अवधि दर्ज करती है लेकिन दिन नहीं, तो यह last_ported_at_is_approximate सेट करता है।

नहीं। इसका मतलब है कि रजिस्ट्री से पूछा गया और उसमें इस नंबर के लिए कोई बदलाव दर्ज नहीं है, जो नंबर के बारे में एक खोज है न कि उत्तर में कोई कमी। ब्लॉक पर मौजूद status बताता है कि जाँच चली भी थी या नहीं।

कई संकेतों में से एक के रूप में। यह कम विश्वसनीयता के लिए 0 से लेकर उच्च विश्वसनीयता के लिए 100 तक होता है, यह एक समग्र स्कोर है, और आप इसे अन्य प्रॉपर्टीज़ से निकाल नहीं सकते। केवल इसी पर निर्भर रहने के बजाय इसे बाकी उत्तर के साथ मिलाकर तौलें।

क्या वह एड्रेस मेल स्वीकार करेगा। एक कॉल result में फ़ैसला, एक delivery_confidence स्कोर, एड्रेस के प्रकार बताने वाले फ़्लैग, और अगर एड्रेस गलत लिखा लगे तो एक सुधार लौटाता है।

valid का मतलब है एड्रेस मौजूद है और मेल स्वीकार करता है, तो भेजें। neutral का मतलब है किसी भी तरफ़ पुष्टि नहीं हो सकी, आमतौर पर इसलिए क्योंकि प्राप्तकर्ता डोमेन हर recipient को एक ही तरह जवाब देता है। risky का मतलब है शायद मेल स्वीकार करता है लेकिन बाउंस या शिकायत की संभावना औसत से ज़्यादा है। undeliverable का मतलब है मेल स्वीकार नहीं करता। typo का मतलब है एड्रेस गलत लिखा लगता है।

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

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

यह 0 (निश्चित रूप से डिलीवर नहीं होगा) से 100 (निश्चित रूप से डिलीवर होगा) तक चलता है। एक ही स्कोर अलग-अलग कारणों से अलग-अलग verdicts के अंतर्गत आ सकता है, इसलिए इसे result की जगह नहीं बल्कि उसके साथ पढ़ें। जब आपको हर verdict पर एक ही threshold चाहिए — भविष्य में जोड़े गए verdicts सहित — तो यही वह फ़ील्ड है जिस पर भरोसा करें।

नहीं, और यह अंतर मायने रखता है। valid फ़ील्ड संकीर्ण है: यह सिर्फ़ बताता है कि एड्रेस सही फ़ॉर्मेट में है और उसका डोमेन मेल प्राप्त करने के लिए सेट अप है। यह मेलबॉक्स के बारे में कुछ नहीं कहता, इसलिए एक एड्रेस जिसका डोमेन काम कर रहा हो लेकिन ऐसा मेलबॉक्स न हो, वहाँ true होगा लेकिन result में undeliverable।

role का मतलब है एड्रेस किसी व्यक्ति के बजाय किसी फ़ंक्शन के नाम पर है, जैसे support@ या info@, इसलिए रिप्लाई और सहमति अस्पष्ट हैं और शिकायत की संभावना ज़्यादा है। disposable का मतलब है अस्थायी-एड्रेस प्रदाता, इसलिए एड्रेस आमतौर पर जल्द ही बंद हो जाएगा। free_provider का मतलब है उपभोक्ता मेलबॉक्स प्रदाता जैसे Gmail या Outlook.com, जो सिर्फ़ तब संकेत है जब आपको व्यावसायिक एड्रेस की उम्मीद थी।

सादा एड्रेस भेजें, ठीक वैसे ही जैसे आपके पास है। डिस्प्ले-नेम फ़ॉर्म — जिसमें नाम आगे हो और एड्रेस एंगल ब्रैकेट में — रिजेक्ट किया जाता है, अनरैप नहीं, क्योंकि अनरैप करने पर वह एड्रेस लुकअप होगा जो आपने भेजा नहीं। @ से पहले का हिस्सा जैसा लिखा है वैसा ही पास होता है, और उसका केस बदलने से आपको मिलने वाला delivery_confidence बदल सकता है।

नहीं। Suppressions यह काम अपने आप और मुफ़्त में करता है, उन एड्रेस के लिए जो पहले बाउंस या शिकायत कर चुके हैं। Lookup का उपयोग उस एड्रेस के लिए करें जिस पर आपने अभी तक कुछ नहीं भेजा — साइनअप पर या किसी लीड पर कार्रवाई करने से पहले।