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

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

एक संरचनात्मक अंतर काम की रूपरेखा तय करता है। Bird में कोई प्रति-एप्लिकेशन सर्विस ऑब्जेक्ट नहीं है और ट्रैक करने के लिए कोई verification 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 यूज़र ने जो टाइप किया उसे सबमिट करता है, उसी प्राप्तकर्ता और कोड के आधार पर। पूरे पेलोड सत्यापन भेजना में हैं।

पोर्टिंग के दौरान संभालने योग्य चार अंतर:

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

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

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

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

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

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

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

3. सत्यापन लाइफसाइकल पोर्ट करें

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

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

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

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

आपकी सेटिंग के ऊपर प्लेटफ़ॉर्म गार्डरेल हैं जिन्हें आप कॉन्फ़िगर नहीं करते: प्रति-एड्रेस प्रति घंटा send कैप और प्रति-प्राप्तकर्ता check कैप, दोनों 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 डिलीवरी की dead end को कवर करता है: यह reason: "undeliverable" के साथ तब फ़ायर होता है जब प्लान समाप्त हो जाता है और इसकी रिकॉर्ड की गई विफलताएँ बताती हैं कि कोई सत्यापन कोड नहीं भेजा गया, और इसका last_attempt_reason आखिरी आज़माए गए चैनल पर विफलता का नाम देता है। जो सत्यापन एक्सपायर हो जाता है या अपने चेक प्रयास समाप्त कर लेता है वह कोई सेशन इवेंट नहीं भेजता, इसलिए उन दोनों परिणामों को चेक रिस्पॉन्स से लें।

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

5. एक बार में एक कोड लाइफ़टाइम के हिसाब से कटओवर करें

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

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

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

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

किसी विशिष्ट प्रोवाइडर से माइग्रेट करना

Twilio Verify: Services वर्कस्पेस सेटिंग्स बन जाती हैं, VerificationCheck प्राप्तकर्ता-आधारित चेक बन जाता है, चैनल और स्टेटस ट्रांसलेशन
Prelude: लगभग समान create-and-check आकार, जिसमें रूटिंग सिग्नल और साइलेंट वेरिफ़िकेशन वे हिस्से हैं जो पोर्ट नहीं होते

अगले कदम

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

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