Verify को किसी दूसरे प्रदाता से माइग्रेट करें

फ़ोन और ईमेल के वन-टाइम सत्यापन कोड (OTP) को किसी दूसरे सत्यापन प्रदाता से Bird Verify पर ले जाने के लिए इस गाइड का उपयोग करें। पोर्ट छोटा है, क्योंकि सतह छोटी है: आपके प्रदाता की create-और-check जोड़ी जैसी भी हो, उसकी जगह दो कॉल ले लेती हैं, और कोड, संदेश और उनके पीछे का डिलीवरी चैनल Bird संभालता है।

एक संरचनात्मक अंतर काम का स्वरूप तय करता है। Bird में न तो प्रति-एप्लिकेशन सर्विस ऑब्जेक्ट है और न ही कोई सत्यापन ID जिसे आपको ट्रैक करना पड़े। सत्यापन की पहचान उसके प्राप्तकर्ता से होती है, इसलिए दोनों कॉल एक ही to लेती हैं, और आपके इंटीग्रेशन को कोई स्टेट रखने की ज़रूरत नहीं रहती।

माइग्रेशन चेकलिस्ट:

create और check कॉल मैप करें
अपने चैनल, देश और प्रेषक सेट करें
सत्यापन की लाइफ़साइकिल पोर्ट करें
वेबहुक बदलें
एक बार में एक कोड की वैधता अवधि के हिसाब से कटओवर करें

चरण 1 और 3 इस पर निर्भर करते हैं कि आप कौन-सा प्रदाता छोड़ रहे हैं। आपकी प्रदाता गाइड में फ़ील्ड-दर-फ़ील्ड मैपिंग और स्टेटस का अनुवाद दिया गया है।

1. create और check कॉल को मैप करें

POST /v1/verify/verifications एक सत्यापन कोड भेजता है। सबसे छोटे अनुरोध में केवल एक प्राप्तकर्ता होता है:

कोड उदाहरण

curl -X POST https://us1.platform.bird.com/v1/verify/verifications \
  -H "Authorization: Bearer $BIRD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to": {"phone_number": "+15551234567"}}'

POST /v1/verify/verifications/check उपयोगकर्ता का टाइप किया हुआ कोड जमा करता है। इसकी कुंजी वही प्राप्तकर्ता और साथ में कोड होता है। पूरे पेलोड सत्यापन भेजना में दिए गए हैं।

पोर्ट करते समय इन चार अंतरों को संभालें:

प्राप्तकर्ता ही कुंजी है। जो प्रोवाइडर सत्यापन SID या ID लौटाते हैं, वे check में उसे वापस मांगते हैं। Bird इसके बजाय पतों के सेट से मिलान करता है, और यह मिलान बिल्कुल सटीक होना चाहिए: ईमेल और फ़ोन नंबर दोनों के साथ बनाया गया सत्यापन इनमें से किसी एक से अकेले नहीं मिलता। प्रोवाइडर की सत्यापन ID रखने वाला कॉलम आप हटा सकते हैं।
गलत कोड पर 200 लौटता है। प्रतिक्रिया में success: false, incorrect_code, expired या attempts_exhausted वाला reason, और attempts_remaining होते हैं। अपना त्रुटि पाथ केवल अनुरोध विफलताओं के लिए रखें। सत्यापन के अंतिम स्थिति में पहुँचने के बाद आगे के check success: false के बजाय 404 लौटाते हैं।
Bird कोड बनाता है और उसे कभी नहीं लौटाता। कस्टम कोड का कोई पैरामीटर नहीं है। इसलिए जो प्रोवाइडर इंटीग्रेशन अपना सत्यापन कोड देता था, या कोड वापस पढ़कर उसे खुद भेजता था, उसका यहाँ कोई विकल्प नहीं है।
दोनों एंडपॉइंट Idempotency-Key लेते हैं। टाइमआउट के बाद दोहराया गया अनुरोध मूल प्रतिक्रिया लौटाता है। वह न दूसरा कोड भेजता है, न कोई प्रयास खर्च करता है।

प्रति-अनुरोध विकल्प जानबूझकर कम रखे गए हैं: options.code_length और options.channels, जो एक अनुरोध के लिए चैनलों का क्रम बदलता है या उन्हें सीमित करता है। बाकी सब कुछ भेजने के अनुरोध का फ़ील्ड नहीं, बल्कि वर्कस्पेस कॉन्फ़िगरेशन है।

2. अपने चैनल, देश और सेंडर सेट करें

Bird ईमेल, SMS, WhatsApp, Telegram और वॉइस कॉल पर कोड भेजता है। फ़ोन प्राप्तकर्ता के लिए ज़्यादातर देशों में पहले WhatsApp आज़माया जाता है और SMS फ़ॉलबैक होता है। भेजना विफल होने पर डिलीवरी प्लान के अगले चैनल पर चली जाती है। Countries पेज पर हर देश के लिए क्रम सेट करें या कोई चैनल बंद करें। वहीं उन देशों को भी बंद कर दें जिनमें आप सेवा नहीं देते, क्योंकि अप्रयुक्त गंतव्य से पहुँच नहीं बढ़ती, बल्कि SMS पंपिंग का जोखिम बढ़ता है।

कोई तारीख तय करने से पहले अपने मौजूदा फ़्लो से इन दो कमियों की जाँच करें:

कोई साइलेंट नेटवर्क ऑथेंटिकेशन नहीं है। बिना कोड वाले फ़्लो के लिए यहाँ कोई दूसरा समाधान चाहिए। जो उपयोगकर्ता SMS प्राप्त नहीं कर पाते, उनके लिए फ़ोन कॉल वाला फ़ॉलबैक पोर्ट हो जाता है: उन देशों के लिए वॉइस चालू करें और चैनल क्रम में उसे SMS के बाद रखें। प्राप्तकर्ता की भाषा चाहे जो हो, कॉल कोड को अंग्रेज़ी में पढ़ती है, इसलिए स्थानीय भाषा वाला कॉल फ़्लो साथ नहीं आता।
कटओवर से पहले सेंडर चुनें। Email, SMS और WhatsApp डिफ़ॉल्ट रूप से Bird Verify का उपयोग करते हैं, और इनकी जगह Authifly का उपयोग कर सकते हैं। आप अपना सत्यापित ईमेल डोमेन, कोई मौजूदा SMS Sender ID, या स्वीकृत ऑथेंटिकेशन टेम्पलेट वाला कोई कनेक्टेड WhatsApp नंबर भी उपयोग कर सकते हैं। Telegram अपने स्वयं के सत्यापित नोटिफ़िकेशन अकाउंट का उपयोग करता है। अगर आप ऐसा SMS सेंडर रखना चाहते हैं जिसे आपके उपयोगकर्ता पहले से पहचानते हैं, तो जाँचें कि वह हर गंतव्य देश में समर्थित और पंजीकृत है। सेंडर और ब्रांडिंग में विकल्प और फ़ॉलबैक व्यवहार दिए गए हैं।

अगर आप अपना WhatsApp नंबर उपयोग करते हैं, तो अपने Verify कॉन्फ़िगरेशन में कोई मौजूदा स्वीकृत ऑथेंटिकेशन टेम्पलेट चुनें। ईमेल और SMS संदेश का टेक्स्ट Bird नियंत्रित करता है। किसी एक सत्यापन अनुरोध में आप टेम्पलेट ID या कस्टम संदेश बॉडी नहीं भेज सकते।

3. सत्यापन का जीवनचक्र पोर्ट करें

कोई सत्यापन तब तक pending रहता है जब तक उसका निपटारा न हो जाए: समय पर सही कोड आने पर verified, कारण attempts_exhausted या undeliverable के साथ failed, या कारण ttl_elapsed के साथ expired। अपने प्रोवाइडर की अंतिम स्थितियों को इन तीनों से मैप करें, और reason को एक खुला enum मानें।

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

दो व्यवहार आम तौर पर आपके मौजूदा कोड की जगह ले लेते हैं:

दोबारा भेजना, create कॉल को फिर से करना ही है। उसी प्राप्तकर्ता के साथ create कॉल करें: कूलडाउन के दौरान यह बिना भेजे सक्रिय सत्यापन लौटाता है, और कूलडाउन के बाद नया कोड भेजा जाता है। किसी सक्रिय सत्यापन के लिए भेजा गया हर कोड तब तक मान्य रहता है जब तक सत्यापन का निपटारा न हो जाए, इसलिए दूसरा कोड आने के बाद पहला कोड दर्ज करने वाले उपयोगकर्ता को इसका नुकसान नहीं होता।
"I didn't get a code" का अपना एंडपॉइंट है। POST /v1/verify/verifications/next-channel प्लान के अगले चैनल पर जाता है और तुरंत वहाँ भेजता है। यह दोबारा भेजने के कूलडाउन को अनदेखा करता है, लेकिन समाप्ति समय, प्रयासों का बजट और सत्यापन वही रखता है। जो चैनल कोड नहीं पहुँचा रहा, उस पर बार-बार दोबारा भेजने के बजाय इसे बटन से जोड़ें।

आपकी सेटिंग्स के ऊपर प्लेटफ़ॉर्म की सुरक्षा सीमाएँ लागू होती हैं, जिन्हें आप कॉन्फ़िगर नहीं करते: प्रति पते प्रति घंटे भेजने की सीमा और प्रति प्राप्तकर्ता जाँच की सीमा। दोनों का जवाब 429 और Retry-After के साथ मिलता है। अगर आपके मौजूदा प्रोवाइडर ने प्रति एंडपॉइंट दर सीमाएँ बढ़ाने दी थीं और आपने बढ़ाई थीं, तो कटओवर से पहले अपने पीक ट्रैफ़िक की तुलना दुरुपयोग सुरक्षा सीमाएँ में दिए आँकड़ों से करें।

4. वेबहुक बदलें

Verify दो स्तरों पर इवेंट भेजता है। सेशन इवेंट, यानी verify.verification.created, verify.verification.verified और verify.verification.failed, स्वयं सत्यापन को ट्रैक करते हैं। प्रयास इवेंट, यानी verify.attempt.sent, verify.attempt.delivered और verify.attempt.undelivered, हर एक सत्यापन कोड भेजने को ट्रैक करते हैं, इसलिए दोबारा भेजने या चैनल फ़ेलओवर से उसी सेशन में नए प्रयास जुड़ते हैं। POST /v1/webhooks के ज़रिए किसी एंडपॉइंट को अपनी ज़रूरत के इवेंट प्रकारों के लिए सब्सक्राइब करें; पेलोड Verify इवेंट में हैं।

अपने इंटीग्रेशन के लिए ज़रूरी सत्र इवेंट की सदस्यता लें। verify.verification.failed डिलीवरी के गतिरोध को संभालता है: यह तब reason: "undeliverable" के साथ ट्रिगर होता है जब प्लान समाप्त हो जाता है और उसकी दर्ज विफलताएँ बताती हैं कि कोई सत्यापन कोड नहीं भेजा गया। इसका last_attempt_reason आख़िरी आज़माए गए चैनल की विफलता बताता है। जो सत्यापन समाप्त हो जाता है या अपने सभी जाँच प्रयास खर्च कर देता है, वह कोई सत्र इवेंट नहीं भेजता, इसलिए ये दोनों परिणाम जाँच प्रतिक्रिया से लें।

ये इवेंट एनालिटिक्स, अलर्टिंग और सपोर्ट टूलिंग के लिए हैं। आपका प्रमाणीकरण निर्णय जाँच कॉल से आता है, जो सिंक्रोनस रूप से जवाब देती है। किसी लॉगिन फ़्लो को उपयोगकर्ता को अंदर आने देने के लिए कभी वेबहुक का इंतज़ार नहीं करना चाहिए। डिलीवरी कम से कम एक बार और बिना क्रम के होती है, और Standard Webhooks के अनुसार साइन की जाती है। इसलिए हर दूसरे Bird इवेंट की तरह webhook-id हेडर के आधार पर डुप्लिकेट हटाएँ।

5. एक बार में एक कोड की वैधता अवधि के हिसाब से स्विच करें

Verify में कोई सिम्युलेटेड प्राप्तकर्ता नहीं हैं, क्योंकि जाँचने लायक चीज़ कोड का पहुँचना ही है। इसलिए प्रोडक्शन को छूने से पहले, सक्षम किए गए हर चैनल पर, अपने नियंत्रण वाले फ़ोन नंबर और मेलबॉक्स के साथ इंटीग्रेशन चलाएँ।

स्विच करने का एक नियम आसानी से छूट जाता है। आपके पुराने प्रदाता द्वारा जारी कोड की जाँच Bird नहीं कर सकता, और न ही इसका उल्टा संभव है। इसलिए क्रिएट कॉल पर स्विच करें, और एक कोड की वैधता अवधि तक हर जाँच को उसी प्रदाता के पास भेजें जिसने वह सत्यापन जारी किया था। व्यवहार में:

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

केवल डिलीवरी नहीं, कन्वर्ज़न पर भी नज़र रखें। Verifications पेज और Verify मेट्रिक्स भेजे गए और डिलीवर हुए संदेश दिखाते हैं, और यह भी कि कितने सत्यापन verified तक पहुँचे। यही संख्या बताती है कि कोई चैनल क्रम या नई प्रेषक पहचान आपको साइन-अप गँवा रही है या नहीं।

किसी खास प्रदाता से माइग्रेट करना

Twilio Verify: Services वर्कस्पेस सेटिंग बन जाती हैं, VerificationCheck प्राप्तकर्ता के आधार पर होने वाली जाँच बन जाता है, साथ में चैनल और स्टेटस का अनुवाद
Prelude: लगभग एक जैसी create-और-check संरचना, जिसमें रूटिंग सिग्नल और साइलेंट सत्यापन वे हिस्से हैं जो पोर्ट नहीं होते

अगले कदम

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

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

अभ्यास करें और इम्प्लीमेंटेशन ब्रीफ़ पाएँ

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