---
title: "Verify के सर्वोत्तम तरीके"
description: "सत्यापन कोड की लंबाई और वैधता अवधि कैसे तय करें, किस काम के लिए कौन-सा चैनल इस्तेमाल करें, और Bird के डिफ़ॉल्ट कहाँ पहले से NIST SP 800-63B का पालन करते हैं तथा कौन-सी सेटिंग आपको उसके बाहर ले जा सकती है।"
canonical: "https://bird.com/hi-in/dastavez/guides/verify/best-practices"
---

# Verify के सर्वोत्तम तरीके

Verify ऐसे डिफ़ॉल्ट के साथ आता है जो ज़्यादातर वन-टाइम सत्यापन कोड फ़्लो के लिए उपयुक्त हैं। यह गाइड उन फ़ैसलों को कवर करती है जो डिफ़ॉल्ट आपके लिए नहीं लेते: कोड कितनी देर तक मान्य रहे, उसमें कितने अंक हों, आप असल में जो सत्यापित कर रहे हैं उसके लिए कौन-सा चैनल उपयुक्त है, और डिलीवरी की समस्या को सत्यापन की समस्या से कैसे अलग पहचानें।

जहाँ किसी सार्वजनिक मानक में कोई स्पष्ट नियम है, वहाँ यह गाइड उसे उद्धृत करती है। सत्यापन कोड से ऑथेंटिकेशन का मानक NIST SP 800-63B, [Digital Identity Guidelines: Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html) है, जिसे 3 सितंबर 2026 को प्राप्त किया गया। उद्धरण वर्तमान संशोधन से हैं। पुराने Revision 3 को, जिसका हवाला OTP से जुड़ी कई सलाहें अब भी देती हैं, NIST ने स्वयं इस सूचना के साथ चिह्नित किया है: 1 अगस्त 2025 से SP 800-63-4 द्वारा प्रतिस्थापित।

## कोड छह या उससे अधिक अंकों का रखें

Bird के कोड डिफ़ॉल्ट रूप से 6 अंकों के होते हैं और `options.code_length` प्रति अनुरोध 4 से 8 अंक स्वीकार करता है ([सत्यापन सेटिंग्स](/docs/guides/verify/sending-verifications#verification-settings))। डिफ़ॉल्ट सही विकल्प है, जबकि इस सीमा का निचला सिरा सही नहीं है:

> The verifier SHALL generate random authentication secrets that are at least six decimal digits (or equivalent) in length using an approved random bit generator

4 या 5 अंकों का कोड API की स्वीकृत सीमा के भीतर है, लेकिन मानक की अनुमति के बाहर है। कोड को छोटा केवल उसी फ़्लो में करें जहाँ आपने तय किया है कि सुरक्षा सत्यापन कोड की एन्ट्रॉपी पर निर्भर नहीं है।

## वैधता अवधि दस मिनट या उससे कम रखें

**Duration** डिफ़ॉल्ट रूप से 10 मिनट है और 1 से 999 तक के मान स्वीकार करता है ([सत्यापन सेटिंग्स](/docs/guides/verify/sending-verifications#verification-settings))। डिफ़ॉल्ट ठीक मानक की अधिकतम सीमा पर है:

> In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes.

यानी स्वीकृत मान इस सीमा से कहीं आगे तक जाते हैं। एक्सपायर हुए कोड को लेकर सपोर्ट अनुरोध कम करने के लिए Duration बढ़ाना ही वह एक सेटिंग बदलाव है जो चुपचाप किसी फ़्लो को 800-63B के बाहर ले जाता है। अगर उपयोगकर्ताओं तक पहुँचने से पहले ही कोड एक्सपायर हो रहे हैं, तो आम तौर पर समाधान वैधता अवधि में नहीं, बल्कि भेजने की प्रक्रिया में होता है।

## अनुरोध दर सीमित करने की दो परतों की अपेक्षा रखें

जाँच के हर प्रयास पर दो सीमाएँ लागू होती हैं, और दोनों अलग-अलग खतरों से बचाती हैं।

**आपकी सेटिंग।** **Maximum Retries** का डिफ़ॉल्ट 5 है और यह 1 से 10 तक का मान स्वीकार करती है। यह सीमा पार होने पर सत्यापन `attempts_exhausted` के साथ विफल हो जाता है। इतने छोटे कोड के लिए मानक यह सीमा अनिवार्य करता है, और साथ में एक नियम भी जोड़ता है:

> Generating a new authentication secret SHALL NOT reset the failed authentication count.

इस सीमा की एक ऊपरी हद है, और यही एक जगह है जहाँ Verify का हर उपलब्ध मान मानक के भीतर आराम से रहता है:

> the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator

Maximum Retries का अधिकतम मान 10 है, इसलिए आप कोई भी कॉन्फ़िगरेशन चुनें, वह 100 तक नहीं पहुँचता। ऊपर के दो खंडों में स्थिति उलटी है: कोड की लंबाई और अवधि, दोनों का एक समर्थित मान 800-63B से बाहर ले जाता है, जबकि प्रयास की सीमा का ऐसा कोई मान नहीं है।

**Bird की प्लेटफ़ॉर्म सीमाएँ** लागू रहती हैं, चाहे आप कुछ भी कॉन्फ़िगर करें। शुरू करने और दोबारा भेजने को मिलाकर, हर पते पर किसी भी लगातार एक घंटे में 5 भेजे जा सकते हैं। प्राप्तकर्ता पतों के हर सेट पर प्रति मिनट 10 जाँचें की जा सकती हैं। दोनों सीमाएँ `Retry-After` हेडर के साथ `429` लौटाती हैं ([दुरुपयोग से सुरक्षा](/docs/guides/verify/sending-verifications#abuse-guardrails))। ये इसलिए हैं ताकि OTP ट्रैफ़िक का इस्तेमाल आपके खर्च या किसी अनजान व्यक्ति के फ़ोन के खिलाफ़ हथियार की तरह न हो। इसलिए यहाँ `429` मिलने का मतलब है कि सिस्टम ठीक से काम कर रहा है। इसे ऐसी सीमा न समझें जिससे बचने का रास्ता बनाना हो।

## आप जो सत्यापित कर रहे हैं, उसके अनुसार चैनल चुनें

Verify ईमेल, SMS, WhatsApp और Telegram से कोड भेजता है ([चैनल](/docs/guides/verify/overview#channels))। मानक इनमें से दो चैनलों के साथ बहुत अलग व्यवहार करता है। यह अंतर इस पर निर्भर करता है कि कोड _किस काम_ के लिए है, इस पर नहीं कि उसे कौन-सा चैनल पहुँचाता है।

**ईमेल प्रमाणीकरण का कारक नहीं है।** 800-63B इस पर साफ़ है:

> Email SHALL NOT be used for out-of-band authentication because it may be vulnerable to:
>
> - Access using only a password
> - Interception in transit or at intermediate mail servers
> - Rerouting attacks, such as those caused by Domain Name System (DNS) spoofing

उसी अंश में उस स्थिति को छूट दी गई है जिसके लिए Verify का ईमेल चैनल बना है:

> Confirmation codes that are sent to validate email addresses or are issued as recovery codes (see Sec. 4.2.1.2) are not authentication processes and not affected by the above prohibition.

इसलिए अगर ईमेल कोड यह साबित करता है कि किसी पते पर किसी व्यक्ति का नियंत्रण है, तो यह मानक की छूट के दायरे में आता है और ठीक है। साइन-इन पर दूसरे कारक के रूप में इस्तेमाल होने वाला ईमेल कोड इस दायरे में नहीं आता। अगर आपका फ़्लो दूसरी तरह का है, तो ईमेल चैनल का इस्तेमाल न करें।

**SMS और वॉइस की अनुमति है, लेकिन शर्तों के साथ।** टेलीफ़ोन नेटवर्क से कोड भेजने पर तीन ज़िम्मेदारियाँ आती हैं, जो लगातार दो वाक्यों में दी गई हैं:

> Accordingly, verifiers SHALL ensure that alternative authenticator types are available to all subscribers and SHOULD remind subscribers of this limitation of PSTN out-of-band authenticators before binding one or more devices controlled by the subscriber. Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret.

`SHALL` प्रोडक्ट की ज़रूरत है, Verify की कोई सेटिंग नहीं। अगर SMS आपका इकलौता कारक है, तो आप यह ज़रूरत पूरी नहीं करते। Verify का देश-वार चैनल क्रम डिलीवरी में मदद करता है, क्योंकि ज़्यादातर देशों में पहले WhatsApp आज़माया जाता है और SMS विकल्प के रूप में रहता है ([चैनल](/docs/guides/verify/overview#channels))। लेकिन SMS, WhatsApp और Telegram, तीनों एक ही तरह के ऑथेंटिकेटर, यानी आउट-ऑफ़-बैंड, के डिलीवरी रास्ते हैं। इसलिए इनके बीच बदलने से कोई दूसरी तरह का ऑथेंटिकेटर नहीं मिलता। दोनों `SHOULD` प्रोडक्ट टीम को लागू करने होते हैं: जब उपयोगकर्ता कोई फ़ोन नंबर जोड़ता है, तब एक सूचना दिखाना, और उस नंबर पर भेजने से पहले पोर्टिंग और सिम बदलने के संकेत जाँचना।

## दोबारा भेजने से पहले विफलता को समझें

जो कोड पहुँचता ही नहीं और जो कोड पहुँचकर गलत टाइप हो जाता है, उन्हें अलग-अलग तरह से संभालना होता है, और इवेंट इन दोनों में अंतर बताते हैं ([इवेंट](/docs/guides/verify/events))।

`verify.attempt.undelivered` में एक `reason` होता है, और आगे क्या होगा यह प्राप्तकर्ता के चैनल प्लान पर निर्भर करता है। जिस प्राप्तकर्ता के लिए एक से अधिक चैनल उपलब्ध हैं, उसके लिए यह सत्यापन को समाप्त नहीं करता: Bird अगले चैनल पर चला जाता है, जिसे अपना अलग `verify.attempt.sent` मिलता है। इसलिए एक अनडिलीवर प्रयास से सत्यापन समाप्त नहीं होता और आपको दोबारा भेजने की ज़रूरत नहीं होती। एक ही चैनल वाले प्राप्तकर्ता के लिए आगे जाने का कोई चैनल नहीं होता, और सत्यापन समाप्त हो जाता है।

इस समाप्ति को अलग से संभालना होता है, और एक इवेंट इसकी पहचान करता है। `failed` स्टेटस दो स्थितियों में आता है: जब बहुत अधिक गलत सत्यापन कोड जमा किए गए हों, तब `reason` `attempts_exhausted` के साथ, और जब कोई भी नियोजित चैनल कोड डिलीवर न कर सका हो, तब `reason` `undeliverable` के साथ। केवल दूसरी स्थिति में `verify.verification.failed` भेजा जाता है। इसलिए एक ही चैनल वाले प्राप्तकर्ता के मामले में स्टेटस नहीं, बल्कि यही इवेंट बताता है कि किसी को कोड नहीं मिला।

एक गुण ऐसा है जिसे बाद में पता चलने के बजाय पहले से डिज़ाइन में शामिल करें, और यह मानक का नहीं बल्कि Bird का अपना है: [इवेंट](/docs/guides/verify/events) के अनुसार डिलीवरी रिपोर्ट संकेत मात्र हैं, गारंटी नहीं, क्योंकि कैरियर और मेलबॉक्स प्रदाता अलग-अलग बातें और अलग-अलग गति से पुष्टि करते हैं। कुछ बाज़ारों में प्रयास इवेंट कुछ मिनट देर से आता है या डिलीवरी और स्वीकृति में अंतर नहीं करता। "I didn't get a code" पाथ को ऐसे डिलीवरी इवेंट के इंतज़ार पर न बनाएँ जो शायद न आए, बल्कि [`POST /v1/verify/verifications/next-channel`](/docs/guides/verify/sending-verifications#send-the-code-on-another-channel) पर बनाएँ, जो सत्यापन को आगे बढ़ाता है।

## सत्यापन को नहीं, अनुरोध को फिर से प्रयास करें

Verify के तीनों एंडपॉइंट `Idempotency-Key` स्वीकार करते हैं ([सुरक्षित रूप से फिर से प्रयास करना](/docs/guides/verify/sending-verifications#retrying-safely))। टाइमआउट या कनेक्शन टूटने के बाद उसी कुंजी के साथ फिर से प्रयास करने पर मूल प्रतिक्रिया ही दोबारा मिलती है: न दूसरा कोड जाता है और न कोई जाँच प्रयास खर्च होता है। कुंजी के बिना, प्रतिक्रिया खो जाने के बाद किया गया फिर से प्रयास एक और कोड भेजता है और प्रति घंटे की सीमा में से एक और भेजना खर्च करता है।

## जानें कि एक बार भेजने की लागत क्या है

बिलिंग भेजे गए हर कोड पर, गंतव्य के लिए चैनल की दर से लगती है, और हर दोबारा भेजना या फ़ॉलबैक प्रति भेजने पर एक शुल्क जोड़ता है ([लागत और बिलिंग](/docs/guides/verify/sending-verifications#cost-and-billing))। फिर से प्रयास की नीति पर इसके दो असर पड़ते हैं:

- जो सत्यापन कई चैनलों से होकर गुज़रता है, उसकी लागत कई बार भेजने के बराबर होती है। इसलिए बड़ा चैनल प्लान डिलीवरी के साथ-साथ लागत का भी निर्णय है।
- Telegram का बिल अलग चरण पर बनता है। Telegram से पूछा जाता है कि क्या वह नंबर संदेश प्राप्त कर सकता है, और जवाब हाँ होने पर पूरी दुनिया में एक समान दर से शुल्क लगता है। जिस नंबर तक पहुँचा नहीं जा सकता, उसका कोई शुल्क नहीं लगता और सत्यापन बिना बिल के अगले चैनल पर चला जाता है। इसलिए शुल्क का अर्थ है कि कोड डिलीवरी के लिए स्वीकार हुआ, यह नहीं कि वह पहुँच गया: यदि वह कोड बाद में डिलीवर नहीं होता, तो शुल्क बना रहता है, और सत्यापन अगले चैनल के लिए फिर से भुगतान करता है। जहाँ यह दूसरा शुल्क नहीं चाहिए, वहाँ Countries पेज पर उन देशों के चैनल क्रम से Telegram को हटा दें ([लागत और बिलिंग](/docs/guides/verify/sending-verifications#cost-and-billing))।

## अगले कदम

- [सत्यापन भेजना](/docs/guides/verify/sending-verifications): सेटिंग्स, सुरक्षा सीमाएँ और स्थितियों की पूरी सूची
- [इवेंट](/docs/guides/verify/events): हर सेशन और डिलीवरी इवेंट, उसके पेलोड के साथ
- [देश](/docs/guides/verify/countries): हर देश के लिए चैनल का क्रम और उपलब्धता
- [सेंडर और ब्रांडिंग](/docs/guides/verify/senders): हर संदेश कैसा दिखता है

## Related resources

- [Verify phone numbers at signup](/learn/series/verify-phone-numbers-at-signup) (video)
- [What does OTP mean? One-time passwords explained](/explained/verify/what-does-otp-mean) (answer)
- [Customer verification](/verify-api) (product)
- [Build your first integration](/learn/paths/integration) (course)

[Get an implementation brief](/learn/workspace?topic=verify)