उत्पाद अपडेट: बेहतर बल्क सत्यापन यूएक्स, अधिक ईमानदार एसिंक प्रगति, और एक आधुनिक एमसीपी कनेक्शन मॉडल

पिछले रिलीज़ चक्र में, हमने परिवर्तनों का एक सेट किया है जो सभी एक ही दिशा में इशारा करते हैं: BillionVerify को विश्वास करना आसान बनाएं, निगरानी करना आसान बनाएं, और एकीकृत करना आसान बनाएं।

उनमें से कुछ परिवर्तन तुरंत उत्पाद में दृश्यमान हैं। Bulk Verify अनुभव फ़ाइल सबमिशन के बाद स्वच्छ है। सत्यापन इतिहास पृष्ठ अधिक उपयोगी है जबकि कोई नौकरी अभी भी चल रही है। प्रगति संकेतक अब उन चीजों को प्रतिबिंबित करते हैं जिनकी उपयोगकर्ताओं को वास्तव में परवाह है आंतरिक कतार यांत्रिकी को उजागर करने के बजाय।

कुछ परिवर्तन गहरे हैं। UI के पीछे सत्यापन स्थिति अनुबंध समृद्ध और अधिक स्पष्ट है। डेटा मॉडल अब ईमेल-स्तर की प्रगति और बैकएंड निष्पादन प्रगति के बीच अंतर करता है, जो क्लाइंट को ईमानदार रीयलटाइम स्थिति प्रस्तुत करने के लिए एक बहुत बेहतर आधार देता है।

और कुछ परिवर्तन सीधे डेवलपर्स को प्रभावित करते हैं। BillionVerify MCP अब पूरी तरह से पुरानी ?api_key= सेटअप आकृति से दूर चला गया है और OAuth, संरक्षित-संसाधन खोज, और आधुनिक क्लाइंट संगतता के चारों ओर निर्मित एक होस्ट किए गए रिमोट MCP मॉडल में चला गया है। हमने उत्पाद, दस्तावेज़, विपणन पृष्ठ, और प्रमाणीकरण सतहों को उस वास्तविकता से मेल खाने के लिए अपडेट किया है।

यह पोस्ट उन अपडेटों को एक ही आख्यान में एक साथ लाती है ताकि ग्राहक, डेवलपर्स, और आंतरिक टीमें देख सकें कि वे कैसे फिट होते हैं।

यदि आप छोटे संस्करण को चाहते हैं, तो यह है:

• Bulk सत्यापन में अब अपलोड के बाद एक स्वच्छ प्रवाह है।
• Async नौकरी निगरानी अधिक जानकारीपूर्ण और अधिक ईमानदार है।
• बैकएंड स्थिति इंटरफ़ेस वितरित कार्य के लिए बेहतर संरचित है।
• BillionVerify MCP के पास अब एक स्पष्ट दीर्घकालिक आकार है: URL-एम्बेडेड API कुंजियों के बजाय रिमोट एंडपॉइंट प्लस OAuth।

यदि आप पूरी कहानी चाहते हैं, तो आगे पढ़ें।

त्वरित लिंक

• बल्क ईमेल सत्यापन
• ईमेल सत्यापन क्या है?
• MCP अवलोकन
• MCP डेवलपर गाइड
• Claude Code गाइड
• API संदर्भ

इन अपडेट्स को एक साथ क्यों रखा जाता है

पहली नज़र में, यह रिलीज़ कई अलग-अलग धागे की तरह दिखता है:

• बल्क वेरिफिकेशन पेज पर फ्रंटएंड क्लीनअप
• एक समृद्ध हिस्ट्री डिटेल स्क्रीन
• बैकएंड स्टेटस कॉन्ट्रैक्ट अपग्रेड
• MCP ऑथेंटिकेशन और डॉक्यूमेंटेशन क्लीनअप

लेकिन अंतर्निहित विषय सभी में समान है: अस्पष्टता को हटाना।

अस्पष्टता सॉफ्टवेयर प्रोडक्ट्स में विभिन्न तरीकों से दिखाई देती है।

कभी-कभी यह फाइल अपलोड के बाद डुप्लिकेट UI की तरह दिखता है। यूज़र्स निश्चित नहीं होते कि कौन सा बटन महत्वपूर्ण है, अगला सर्वोत्तम कदम कहां है, या सिस्टम अभी भी पृष्ठभूमि में काम कर रहा है या नहीं।

कभी-कभी यह एक प्रोग्रेस बार की तरह दिखता है जो "29% पूर्ण" कहता है जबकि आसपास की संख्याएं यह समझाती नहीं हैं कि वह प्रतिशत क्या दर्शाता है। क्या यह प्रोसेस किए गए ईमेल्स का 29% है? पूर्ण वर्कर टास्क्स का 29%? मर्ज किए गए रिज़ल्ट्स का 29%? अधिकांश यूज़र्स एक जॉब को मॉनिटर करने के लिए केवल कतार आर्किटेक्चर को डिकोड नहीं करना चाहते।

कभी-कभी अस्पष्टता डेवलपर ऑनबोर्डिंग में होती है। एक प्रोडक्ट पहले से ही प्रोडक्शन में एक आर्किटेक्चर को सपोर्ट कर सकता है जबकि इसके सार्वजनिक डॉक्स के कुछ हिस्से अभी भी एक पुराने कनेक्शन मॉडल का सुझाव देते हैं। यह सेटअप विफलताओं, भ्रम और अनावश्यक अविश्वास पैदा करता है।

यह रिलीज़ उन समस्याओं का हमारा उत्तर है।

हमने प्रोडक्ट UX को इस बात के चारों ओर सख्त किया कि यूज़र्स को वास्तव में क्या जानने की आवश्यकता है। हमने बैकएंड इंटरफेस को इस बात के चारों ओर सख्त किया कि क्लाइंट्स को वास्तव में क्या रेंडर करने की आवश्यकता है। और हमने डेवलपर-फेसिंग MCP स्टोरी को इस बात के चारों ओर सख्त किया कि प्लेटफॉर्म आज वास्तव में कैसे काम करता है।

मुझे आपकी Markdown को हिंदी में अनुवाद करने में मदद करने दें।

1. Bulk Verify के पास अब अधिक स्वच्छ पोस्ट-अपलोड अनुभव है

इस रिलीज़ का पहला भाग फ़ाइल जमा करने के तुरंत बाद के पल पर केंद्रित था।

वह पल जितना दिखता है उससे अधिक महत्वपूर्ण है।

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

• क्या मेरी फ़ाइल सफलतापूर्वक जमा हुई?
• क्या प्रसंस्करण पहले से चल रहा है?
• मैं इस विशिष्ट कार्य की निगरानी करने के लिए कहाँ जाऊँ?
• क्या मैं विश्वास कर सकता हूँ कि सिस्टम मुझे सूचित करेगा जब यह समाप्त हो?

पिछला प्रवाह उन सवालों का जवाब देता था, लेकिन वह बहुत अधिक दोहराव के साथ ऐसा करता था। सफलता कार्ड, आसपास की स्थिति पाठ, और उपलब्ध बटन सभी ने ध्यान को थोड़े अलग-अलग दिशाओं में खींचा।

हमने इसे साफ कर दिया।

पृष्ठ पर क्या बदला

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

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

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

हमने उन तत्वों को भी हटा दिया जो तकनीकी रूप से कार्यात्मक थे लेकिन सार्थक रूप से उपयोगी नहीं थे:

• अपलोड क्षेत्र में डुप्लिकेट स्थिति पाठ
• सफलता कार्ड में एक अतिरिक्त "दूसरी फ़ाइल अपलोड करें" बटन

उपयोगकर्ता अभी भी मुख्य अपलोड सतह से दूसरी फ़ाइल अपलोड कर सकते हैं। अंतर यह है कि इंटरफेस अब अपने आप से प्रतिस्पर्धा नहीं करता है।

व्यावहारिक रूप से यह क्यों महत्वपूर्ण है

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

पोस्ट-अपलोड स्थिति को साफ करना तीन तरीकों से मदद करता है:

1. यह जमा करने के तुरंत बाद आवश्यक स्क्रीन पार्सिंग की मात्रा को कम करता है।
2. यह अगले कदम को स्पष्ट करता है।
3. यह UI को उपयोगकर्ता के मानसिक मॉडल के साथ संरेखित रखता है: "मेरी फ़ाइल अंदर है। अब मैं इस कार्य को अनुसरण करना चाहता हूँ।"

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

उदाहरण: नया पोस्ट-जमा करने वाला पथ

यहाँ अभी का इरादा उपयोगकर्ता यात्रा है:

1. Bulk सत्यापन प्रवाह में एक CSV अपलोड करें।
2. फ़ाइल नाम, पंक्ति गणना और ETA के साथ तत्काल सफलता स्थिति देखें।
3. इसे मैन्युअल रूप से प्रकट किए बिना लाइव प्रगति देखें।
4. उस कार्य के लिए सटीक इतिहास विवरण पृष्ठ खोलने के लिए एक प्राथमिक बटन पर क्लिक करें।
5. परिणाम और निर्यातों की समीक्षा करने के लिए ईमेल या इतिहास के माध्यम से बाद में लौटें।

यह निम्नलिखित से एक सरल पथ है:

1. फ़ाइल अपलोड करें।
2. डुप्लिकेट स्थिति क्षेत्र को पार्स करें।
3. सामान्य इतिहास में क्लिक करें।
4. सही पंक्ति खोजें।
5. लक्ष्य कार्य को फिर से खोलें।

प्रयास में कमी एक एकल सत्र में छोटी है और बार-बार उपयोग पर महत्वपूर्ण है।

2. सत्यापन इतिहास अब एक वास्तविक निगरानी सतह की तरह व्यवहार करता है

दूसरा प्रमुख सुधार async सत्यापन इतिहास पृष्ठ पर था।

यह पृष्ठ कार्यात्मक हुआ करता था, लेकिन सीमित था। यह दिखा सकता था कि एक job मौजूद है और यह प्रगति में है, लेकिन यह अभी तक सक्रिय निगरानी के लिए डिज़ाइन की गई सतह जैसा महसूस नहीं करता था।

यह एक लंबे समय तक चलने वाले सत्यापन job के लिए एक बेमेल है।

जब कोई ग्राहक एक फ़ाइल अभी भी प्रसंस्करण में है, तो इतिहास विवरण पृष्ठ खोलता है, वे केवल एक प्रतिशत संख्या की तलाश नहीं कर रहे हैं। वे समझने की कोशिश कर रहे हैं:

• यह job किस फ़ाइल को संदर्भित करता है
• workload कितना बड़ा है
• कितना काम पहले ही पूरा हो चुका है
• शुरुआती परिणाम मिश्रण कैसा दिखता है
• job को पूरा होने में कितना समय लगेगा

हमने इस वास्तविकता के चारों ओर पृष्ठ को फिर से डिज़ाइन किया।

स्थिर metadata अब पहले दिखाई देता है

अपडेट किए गए इतिहास पृष्ठ अब एक स्थिर सारांश कार्ड से शुरू होता है। वह कार्ड सबसे महत्वपूर्ण job metadata को एक साथ लाता है:

• मूल फ़ाइल नाम
• कुल पंक्तियाँ
• अद्वितीय ईमेल count
• अनुमानित प्रसंस्करण समय
• शुरुआत का समय

यह जानकारी realtime polling loop पर निर्भर नहीं करती है। यह महत्वपूर्ण है क्योंकि स्थिर संदर्भ जल्द से जल्द दिखाई देना चाहिए, भले ही dynamic status payload अभी भी settle या update हो रहा हो।

जब users पृष्ठ पर पहुंचते हैं, तो वे तुरंत अपने आप को orient कर सकते हैं, बजाय इसके कि live status response के लिए सभी काम करने का इंतजार करें।

live progress area बहुत अधिक समृद्ध है

सारांश के नीचे, running-state अनुभव अब materially बेहतर है।

सीमित context के साथ एक bare progress bar के बजाय, पृष्ठ अब निम्नलिखित को surface करता है:

• processed volume
• शेष volume
• statuses में परिणाम वितरण
• language और ETA semantics जो मुख्य bulk verification flow से मेल खाते हैं

उतना ही महत्वपूर्ण यह है कि यह internal metrics को हटा देता है जो आंतरिक रहने चाहिए। हमने जानबूझकर user-facing surface में worker-task और chunk counts को expose करना बंद कर दिया। ये values operationally उपयोगी हो सकती हैं, लेकिन ये वह नहीं हैं जो customers measure करने की कोशिश कर रहे हैं जब वे पूछते हैं, "मेरा job कितना आगे है?"

सही सवाल almost always email-centric होता है, queue-centric नहीं।

Completed-state tools intact रहते हैं

इस काम के लिए design constraints में से एक यह था कि हम completed job page की analytical depth को lose नहीं करना चाहते थे।

इसलिए हमने मौजूदा result breakdown chart और export tools को बनाए रखा। अपडेट completed-state experience को replace करने के बारे में नहीं था। यह running-state experience को strengthen करने और पृष्ठ के शीर्ष को बेहतर बनाने के बारे में था।

इसका मतलब है कि पृष्ठ अब दोनों jobs को बेहतर तरीके से करता है:

• processing के दौरान, यह एक monitoring surface के रूप में काम करता है
• completion के बाद, यह अभी भी एक analysis और export surface के रूप में काम करता है

उदाहरण: users अब एक नज़र में क्या समझ सकते हैं

एक running job page अब इन सभी को जल्दी से जवाब देता है:

• "यह 19,293-पंक्ति वाली फ़ाइल है जिसे मैंने पहले upload किया था।"
• "इसमें 19,010 अद्वितीय emails हैं।"
• "सिस्टम लगभग 33 मिनट का अनुमान लगाता है।"
• "499 emails को पहले से verify किया जा चुका है।"
• "पूर्ण set में ज्यादातर valid है, एक छोटे से invalid और unknown share के साथ।"

यह एक unclear semantics के साथ एक single प्रतिशत संख्या की तुलना में बहुत अधिक उपयोगी mental model है।

3. प्रगति शब्दार्थ अब अधिक ईमानदार हैं

एसिंक उत्पादों का सबसे बड़ा सबक यह है कि "प्रगति" एक एकल अवधारणा नहीं है।

एक वितरित प्रणाली में, कई चीजें स्वतंत्र रूप से आगे बढ़ सकती हैं:

• worker कार्य पूरे हो सकते हैं
• चंक्स मर्ज हो सकते हैं
• ईमेल-स्तर के परिणाम जमा हो सकते हैं
• अंतिम फाइलें डाउनलोड करने योग्य बन सकती हैं

यदि एक क्लाइंट को केवल एक सामान्य progress फील्ड मिलता है, तो उसे यह अनुमान लगाना पड़ता है कि संख्या इन अर्थों में से किसे लेकर चल रही है। यह है कि आप उन UI स्थितियों में कैसे समाप्त होते हैं जो तकनीकी रूप से सुसंगत हैं लेकिन अनुभव में भ्रामक हैं।

हम इसे अनुबंध स्तर पर ठीक करना चाहते थे।

मुख्य बदलाव

अद्यतन इंटरफेस निम्नलिखित के बीच अंतर करना संभव बनाता है:

• email_progress
• chunk_progress
• progress_source

यह अंतर क्लाइंट्स को प्रगति को इस तरीके से प्रदान करने के लिए एक बहुत मजबूत आधार देता है जो उपयोगकर्ता के इरादे से मेल खाता है।

उदाहरण के लिए:

• बड़ा उपयोगकर्ता-सामना प्रगति बार अब email_progress को प्राथमिकता दे सकता है
• परिचालन या नैदानिक दृश्य अभी भी chunk_progress का उपयोग कर सकते हैं
• यदि एक फॉलबैक आवश्यक है, तो progress_source इसे स्पष्ट बना सकता है

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

उदाहरण पेलोड

यहाँ इस तरह का आकार है जो यह संभव बनाता है:

{
  "task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
  "status": "processing",
  "total_emails": 19010,
  "processed_emails": 499,
  "valid_emails": 496,
  "invalid_emails": 2,
  "unknown_emails": 1,
  "catchall_emails": 0,
  "risky_emails": 0,
  "role_emails": 0,
  "disposable_emails": 0,
  "email_progress": 3,
  "chunk_progress": 7,
  "progress_source": "email_progress"
}

अंतर्निहित कतार प्रणाली के बारे में कुछ भी जाने बिना, एक क्लाइंट इस प्रतिक्रिया से अच्छे निर्णय ले सकता है।

यह महत्वपूर्ण है क्योंकि API केवल डेटा लौटाते नहीं हैं। वे अर्थ को परिभाषित करते हैं।

यह ग्राहकों के लिए बेहतर क्यों है

ग्राहकों को परवाह नहीं है कि क्या एक worker ने 96 आंतरिक कार्यों में से 7 को पूरा किया है यदि केवल 19,010 ईमेल में से 499 ही वास्तव में संसाधित हुए हैं। गलत प्रगति अमूर्तता को उजागर करने से भ्रम पैदा होता है, आश्वासन नहीं।

प्राथमिक UI को email_progress की ओर स्थानांतरित करके, उत्पाद अब उपयोगकर्ताओं द्वारा वास्तव में चिंतित कार्य की इकाई को प्रतिबिंबित करता है।

यह फ्रंटएंड टीमों के लिए बेहतर क्यों है

UI को अब एक एकल अस्पष्ट प्रतिशत फील्ड से बहुत अधिक अनुमान लगाने की आवश्यकता नहीं है।

यह पूरी कक्षा के उत्पाद बग को कम करता है:

• प्रगति बार जो बहुत आगे दिखाई देते हैं
• सारांश ब्लॉक जो मुख्य प्रतिशत से पीछे रहते हैं
• अजीब स्थिति की प्रतिलिपि जो अंत उपयोगकर्ताओं को backend कार्यान्वयन विवरण समझाने का प्रयास करती है

यह फ्रंटएंड टीमों को स्थिर कार्य मेटाडेटा को बदलते हुए निष्पादन डेटा से अलग करने का एक स्वच्छ तरीका भी देता है, जो रिलीज के अगले भाग में सीधे जाता है।

4. बैकएंड स्टेटस कॉन्ट्रैक्ट अब डिस्ट्रिब्यूटेड वर्क के लिए बेहतर संरचित है

फ्रंटएंड परिवर्तन बैकएंड कॉन्ट्रैक्ट सुधार के बिना अच्छी तरह से एक साथ नहीं रहेंगे।

हमने यहां दो महत्वपूर्ण संरचनात्मक निर्णय लिए।

पहला, हमने स्थिर मेटाडेटा को लाइव स्टेटस से अलग किया

कुछ फ़ील्ड जॉब बनाने के बाद बमुश्किल बदलते हैं, या बिल्कुल नहीं:

• फाइल का नाम
• बनाने का समय
• कुल पंक्तियां
• अद्वितीय ईमेल गिनती
• अनुमानित प्रसंस्करण समय

अन्य फ़ील्ड स्वाभाविक रूप से गतिशील हैं:

• वर्तमान स्टेटस
• प्रसंस्कृत ईमेल गिनती
• लाइव परिणाम मिश्रण
• प्रगति प्रतिशत

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

नया मॉडल स्पष्ट है:

• स्थिर जॉब मेटाडेटा को मेटाडेटा के रूप में माना जाता है
• लाइव जॉब स्टेटस को स्टेटस के रूप में माना जाता है

यह स्पष्ट रूप से लिखा जाने पर स्पष्ट लगता है, लेकिन इसका कार्यान्वयन गुणवत्ता पर सार्थक प्रभाव पड़ता है।

हिस्ट्री विस्तार पृष्ठ अब स्थिर सारांश जानकारी को जल्दी प्रस्तुत कर सकता है, केवल वह पोल कर सकता है जो बदलने की आवश्यकता है, और जॉब चलने के दौरान UI को शांत रख सकता है।

दूसरा, हमने स्टेटस पेलोड को ही व्यापक बनाया

रीयलटाइम स्टेटस इंटरफेस अब डिस्ट्रिब्यूटेड एसिंक प्रोसेसिंग के लिए बेहतर अनुकूल है क्योंकि यह अब तक क्या हुआ इसकी एक समृद्ध तस्वीर प्रदान करता है।

इसमें ये काउंटर शामिल हैं:

• प्रसंस्कृत
• वैध
• अमान्य
• अज्ञात
• जोखिम भरा
• कैच-ऑल
• भूमिका
• डिस्पोजेबल
• उपयोग किए गए क्रेडिट

ये मान इंटरफेस को न केवल मानव-सामने प्रगति सतहों के लिए बल्कि स्वचालन और डाउनस्ट्रीम वर्कफ़्लो के लिए भी अधिक उपयोगी बनाते हैं। एक क्लाइंट जो वर्तमान परिणाम मिश्रण को समझता है वह चेतावनियों, सूचनाओं, निर्यात और पोस्ट-प्रोसेसिंग के बारे में बेहतर निर्णय ले सकता है।

उदाहरण: यह UI से परे क्यों महत्वपूर्ण है

एक ग्राहक-सामने वाला ऐप की कल्पना करें जो BillionVerify के शीर्ष पर बना हो जो चाहता हो:

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

जब बैकएंड स्टेटस कॉन्ट्रैक्ट स्पष्ट और पर्याप्त समृद्ध हो तो ये सभी उपयोग मामले आसान हो जाते हैं।

यह इसलिए है कि बैकएंड इंटरफेस वर्क महत्वपूर्ण है यहां तक कि जब पहला दृश्यमान परिवर्तन "प्रगति बार बेहतर दिखता है।" एक बेहतर प्रगति बार अक्सर एक बेहतर कॉन्ट्रैक्ट का लक्षण है।

5. MCP अब पूरी तरह से अपने रिमोट OAuth युग में चला गया है

इस अपडेट का आखिरी प्रमुख हिस्सा डेवलपर-सामना वाला है, लेकिन यह रिलीज़ में सबसे महत्वपूर्ण दीर्घकालिक उत्पाद सुधारों में से एक है।

BillionVerify MCP को अब इस तरह प्रस्तुत और प्रलेखित किया जा रहा है जैसा आधुनिक रिमोट क्लाइंट्स के लिए होना चाहिए:

• एक होस्ट किया गया रिमोट एंडपॉइंट
• OAuth-आधारित प्राधिकरण
• सुरक्षित-संसाधन खोज
• मानक Bearer टोकन एक्सेस

एंडपॉइंट है:

https://mcp.billionverify.com/mcp

यह महत्वपूर्ण है क्योंकि पुरानी सेटअप पैटर्न सार्वजनिक सामग्रियों में लंबे समय तक रह सकती हैं, भले ही एक प्लेटफॉर्म आंतरिक रूप से पहले ही आगे बढ़ गया हो। हमारे मामले में, कुछ दस्तावेज़ और मार्केटिंग सतहें अभी भी इस बात का संकेत देती थीं कि MCP को URL-एम्बेडेड API कुंजियों और curl --stdio रैपर्स के माध्यम से जोड़ा जा सकता है।

यह अब BillionVerify MCP के लिए सही आकार नहीं है।

पुरानी मानसिक मॉडल

पुरानी पैटर्न कुछ इस तरह दिखती थी:

curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"

वह मॉडल कई चिंताओं को एक अजीब सेटअप चरण में समेट देता है:

• परिवहन
• प्रमाणीकरण
• रहस्य हैंडलिंग
• स्थानीय रैपर व्यवहार

यह आधुनिक क्लाइंट्स द्वारा होस्ट किए गए रिमोट MCP सर्वर के उपभोग के तरीके के बारे में गलत संकेत भी देता है।

नई मानसिक मॉडल

वर्तमान मॉडल अधिक स्वच्छ है।

Claude Code के लिए, अनुशंसित सेटअप है:

claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp

फिर Claude Code के अंदर:

/mcp

वहाँ से, क्लाइंट ब्राउज़र में OAuth प्रवाह को पूरा करता है।

ChatGPT और अन्य संगत रिमोट MCP क्लाइंट्स के लिए, सही शुरुआती बिंदु केवल एंडपॉइंट ही है:

https://mcp.billionverify.com/mcp

क्लाइंट संरक्षित संसाधन मेटाडेटा की खोज करता है, प्राधिकरण प्रवाह का पालन करता है, और फिर प्रमाणित कॉल के लिए Bearer एक्सेस टोकन का उपयोग करता है।

सबसे महत्वपूर्ण अंतर: MCP auth REST auth नहीं है

पुरानी दस्तावेज़ों को सफाई की आवश्यकता के कारणों में से एक यह है कि API कुंजियां अभी भी BillionVerify में महत्वपूर्ण हैं। लेकिन वे अब MCP बूटस्ट्रैप कहानी से संबंधित नहीं हैं।

स्वच्छ विभाजन है:

• REST API API कुंजियों का उपयोग करता है
• रिमोट MCP OAuth का उपयोग करता है

यह भेद अब पूरी उत्पाद सतह पर बहुत स्पष्ट है।

यदि कोई डेवलपर उपयोग कर रहा है:

• ChatGPT
• Claude Code
• एक अन्य OAuth-सक्षम रिमोट MCP क्लाइंट

उन्हें रिमोट MCP पथ का उपयोग करना चाहिए।

यदि वे निर्माण कर रहे हैं:

• बैकएंड-टू-बैकएंड ऑटोमेशन
• API-कुंजी-संचालित स्क्रिप्ट
• क्लाइंट्स जो केवल स्थानीय stdio प्लस API कुंजियों को समर्थन करते हैं

उन्हें API संदर्भ और REST प्रवाह का उपयोग करना चाहिए।

यह एक सौंदर्य संबंधी अंतर नहीं है। यह एक उत्पाद सीमा है, और दस्तावेज़ों को इसे स्पष्ट करना चाहिए।

6. सार्वजनिक दस्तावेज़ और मार्केटिंग अब उत्पाद से मेल खाते हैं

एक आर्किटेक्चर अपग्रेड समस्या का केवल एक हिस्सा हल करता है यदि सार्वजनिक सामग्री अभी भी एक अलग कहानी कहती है।

इसलिए हमने MCP दस्तावेज़ीकरण और मार्केटिंग सफाई को एक ही रिलीज़ का हिस्सा माना।

हमने अपडेट किया:

• सार्वजनिक MCP पृष्ठ
• MCP गाइड
• Claude Code गाइड
• AI गाइड प्रवेश बिंदु
• बहुभाषी दस्तावेज़ प्रकार
• स्थानीयकृत मार्केटिंग FAQ प्रतिलिपि

लक्ष्य सरल था: "मैं BillionVerify MCP को कैसे कनेक्ट करूँ?" सवाल का एक स्पष्ट उत्तर होना चाहिए।

अब है।

डेवलपर्स के लिए यह क्यों महत्वपूर्ण है

जब सार्वजनिक दस्तावेज़ कार्यान्वयन वास्तविकता से पिछड़ जाते हैं, तो डेवलपर्स को तीन तरीकों से कीमत चुकानी पड़ती है:

1. विफल सेटअप प्रयास
2. प्लेटफॉर्म में खोया हुआ विश्वास
3. स्पष्ट होना चाहिए था इसे स्पष्ट करने के लिए अतिरिक्त सहायता बोझ

सार्वजनिक सतह को वास्तविक दूरस्थ OAuth मॉडल के साथ संरेखित करके, हम अनावश्यक घर्षण को कम करते हैं इससे पहले कि यह सहायता समस्या बन जाए।

प्लेटफॉर्म पोजिशनिंग के लिए यह क्यों महत्वपूर्ण है

MCP इकोसिस्टम तेजी से आगे बढ़ रहा है। जैसे-जैसे अधिक टीमें ChatGPT, Claude Code और अन्य AI क्लाइंट के माध्यम से उपकरणों का मूल्यांकन करती हैं, पहले एकीकरण अनुभव की गुणवत्ता अधिक महत्वपूर्ण होती है।

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

इसलिए हमने साइन-इन और सहमति सतहों को स्पष्ट शर्तें, गोपनीयता और समर्थन संपर्क दृश्यता के साथ भी मजबूत किया। समीक्षक, डेवलपर्स और उद्यम मूल्यांकनकर्ता सभी को लाभ मिलता है जब विश्वास संकेत स्पष्ट होते हैं।

7. इस रिलीज़ का एक व्यावहारिक पहले-और-बाद का दृश्य

इस रिलीज़ को समझने का एक उपयोगी तरीका पहले और बाद के उपयोगकर्ता और डेवलपर अनुभव की तुलना करना है।

पहले

• एक बल्क सत्यापन फ़ाइल को सफलतापूर्वक जमा किया जा सकता था, लेकिन पोस्ट-सबमिट स्थिति में अभी भी डुप्लिकेट UI और कम स्पष्ट अगले चरण थे।
• इतिहास विस्तार पृष्ठ गतिविधि दिखाता था, लेकिन यह अभी तक एक पूर्ण निगरानी सतह की तरह महसूस नहीं हुआ था।
• एक प्रतिशत-पूर्ण मान मौजूद हो सकता था लेकिन उपयोगकर्ताओं को स्पष्ट रूप से यह नहीं बताता था कि यह संसाधित ईमेल का प्रतिनिधित्व करता है या आंतरिक कार्य पूर्णता।
• MCP सार्वजनिक सामग्री अभी भी आंशिक रूप से एक विरासत ?api_key= सेटअप कथा को प्रतिबिंबित करती है।

बाद में

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

यह एक एकल सुविधा नहीं है। यह एक वर्कफ़्लो में एक अर्थपूर्ण गुणवत्ता पास है।

8. इसका विभिन्न दर्शकों के लिए क्या मतलब है

संचालन और विकास टीमों के लिए

आपको कम UI घर्षण के साथ एक सहज बल्क सत्यापन वर्कफ़्लो मिलता है, चलाई जा रही नौकरियों के दौरान बेहतर दृश्यमानता, और आपके द्वारा अभी लॉन्च की गई सटीक नौकरी तक स्पष्ट पहुंच।

उत्पाद और फ्रंटएंड टीमों के लिए

अब आपके पास मजबूत प्रगति शब्दार्थ और मेटाडेटा और लाइव स्थिति के बीच स्वच्छ अलगाव है, जो प्रगति-भारी स्क्रीन बनाना और समझाना आसान बनाता है।

बैकएंड और प्लेटफॉर्म टीमों के लिए

आपके पास वितरित सत्यापन के लिए एक मजबूत स्थिति अनुबंध और इस बारे में एक स्वच्छ कहानी है कि विभिन्न प्रगति मान वास्तव में क्या मायने रखते हैं।

MCP को एकीकृत करने वाले डेवलपर्स के लिए

अब आपके पास सेटअप प्रश्न का एक बहुत स्पष्ट उत्तर है: MCP क्लाइंट के लिए रिमोट MCP प्लस OAuth का उपयोग करें, और REST API के लिए API कुंजियों का उपयोग करें जहां वह मॉडल उपयुक्त है।

9. कहां से शुरू करें

यदि आप अपडेट किए गए अनुभव या इंटीग्रेशन पाथ को एक्सप्लोर करना चाहते हैं, तो यहां से शुरू करें:

• उत्पाद के बारे में अधिक जानें: Email verification
• बड़े वर्कफ़्लो चलाएं: Bulk email verification
• मूल बातें समझें: What is email verification?
• समर्थित क्लाइंट से MCP कनेक्ट करें: MCP overview
• सेटअप पर गहराई से जाएं: MCP guide
• Claude Code को विशेष रूप से सेट अप करें: Claude Code guide
• इसके बजाय API-key-based इंटीग्रेशन का उपयोग करें: API reference

समापन

यह रिलीज़ एक बड़ी चमकदार सतह के बारे में नहीं था। यह वह जगह थी जहाँ अस्पष्टता घुस गई थी, उत्पाद को कसना था।

हमने बल्क सत्यापन यात्रा को स्वच्छ बनाया। हमने async मॉनिटरिंग को अधिक उपयोगी बनाया। हमने प्रगति रिपोर्टिंग को अधिक सच्चा बनाया। और हमने MCP story को उस मंच से मेल खाया जो हम वास्तव में बना रहे हैं।

ये सुधार एक दूसरे को मजबूत करते हैं।

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

यह वह दिशा है जिसमें हम BillionVerify को आगे बढ़ाना जारी रख रहे हैं।

यदि आप पहले से ही BillionVerify का उपयोग कर रहे हैं, तो ये परिवर्तन आपके दिन-प्रतिदिन के वर्कफ़्लो को अधिक सीधा और अधिक अनुमानित महसूस कराएंगे।

यदि आप अभी मंच का मूल्यांकन कर रहे हैं, तो यह अपडेट यह दिखाता है कि हम उत्पाद गुणवत्ता के बारे में कैसे सोचते हैं: ऊपर उपयोगकर्ता-सामना करने वाली स्पष्टता, अंतर्निहित स्पष्ट अनुबंध, और documentation जो वास्तविकता से मेल खाती है।