Webhook

Webhook एक तरीका है जिससे IDCloud स्वचालित रूप से आपके सिस्टम को बताता है कि पहचान सत्यापन जर्नी में कुछ हुआ है। आपके सिस्टम द्वारा "क्या यह हो गया?" पूछने के बजाय, IDCloud घटना होने के तुरंत बाद आपके API को कॉल करता है।

इस स्क्रीन पर आप अपने API का एड्रेस सेट करते हैं, IDCloud इसके विरुद्ध किस तरह प्रमाणीकरण करता है, और जब यह प्रतिक्रिया नहीं देता तो क्या होता है।

जानकारी

यह किसके लिए है: वे ग्राहक जो पोलिंग के बिना स्वचालित रूप से जर्नी के परिणाम प्राप्त करना चाहते हैं। यह सभी प्रकार के इंटीग्रेशन पर लागू होता है।

आपके सिस्टम में क्या बदलता है: अब यह हर स्थिति परिवर्तन पर एक सूचना प्राप्त करता है, IDCloud को पोल करने की आवश्यकता के बजाय।

इसे कहाँ खोजें: IDCloud पोर्टल → साइडबार Settings → Webhook टैब।

शुरू करने से पहले

एक्सेस अनुमति

आपके यूज़र को Configurator प्रोफ़ाइल की आवश्यकता है — वही जो Journey Customization तक एक्सेस देती है। यदि Webhook टैब दिखाई नहीं देता है, तो अपने अकाउंट एडमिनिस्ट्रेटर से बात करें।

कॉन्फ़िगरेशन कैसे लागू होता है

Scope	प्रत्येक tenant और branch के लिए एक वेबहुक। कोई सूची नहीं है: यदि एक पहले से कॉन्फ़िगर है, तो उसे एडिट किया जाता है, डुप्लिकेट नहीं।
अलग-अलग वातावरण	Staging पोर्टल UAT वेबहुक को कॉन्फ़िगर करता है; Production वाला Production को कॉन्फ़िगर करता है। एक को कॉन्फ़िगर करने से दूसरे पर कोई असर नहीं पड़ता।
यह कब प्रभावी होता है	जैसे ही आप सेव करते हैं।
सीक्रेट सुरक्षा	सीक्रेट एन्क्रिप्टेड होता है और प्लेन टेक्स्ट में फिर कभी नहीं दिखाया जाता। स्क्रीन पर यह हमेशा मास्क किया जाता है।

क्या तैयार रखें

• आपके API का HTTPS URL जो सूचनाएं प्राप्त करेगा। सेव करने से पहले इसे लाइव होना चाहिए और रिक्वेस्ट स्वीकार करना चाहिए।
• वे क्रेडेंशियल जिनकी आपके API को आवश्यकता है, आपके द्वारा चुनी गई प्रमाणीकरण पद्धति के आधार पर (Step 3 देखें)।
• यदि आपके API की कोई क्षमता सीमा है, तो यह जितने requests per second सपोर्ट करता है।

पहले से क्या तय करें

दो तकनीकी निर्णय आपके API को मैनेज करने वाले व्यक्ति पर निर्भर करते हैं, पोर्टल ऑपरेट करने वाले व्यक्ति पर नहीं। स्क्रीन खोलने से पहले इन पर सहमति बना लेना बेहतर है:

• आपके API को कौन सी प्रमाणीकरण पद्धति चाहिए।
• क्या आप retries को एडजस्ट करेंगे या उन्हें डिफ़ॉल्ट पर छोड़ देंगे। डिफ़ॉल्ट अधिकतर मामलों के लिए काम करता है।

चरण दर चरण

Step 1 — Webhook टैब खोलें

IDCloud पोर्टल में, साइडबार में gear icon (Settings) पर क्लिक करें और Webhook टैब चुनें।

यदि आपके पास अभी तक कोई वेबहुक कॉन्फ़िगर नहीं है, तो स्क्रीन "No webhooks created" और एक Create webhook बटन दिखाती है। यदि आपके पास पहले से एक है, तो स्क्रीन endpoint, प्रमाणीकरण प्रकार और मास्क किए गए सीक्रेट के साथ Your webhook कार्ड दिखाती है, साथ ही इसे एडिट करने के लिए एक Configure webhook बटन।

endpoint, प्रमाणीकरण प्रकार और मास्क किए गए सीक्रेट के साथ "Your webhook" कार्ड।

Step 2 — अपने API का URL दर्ज करें

Create webhook पर क्लिक करें (या Configure webhook, यदि एक पहले से मौजूद है) और "Client information" के अंतर्गत Client URL (Endpoint) फ़ील्ड भरें।

यह वह एड्रेस है जहाँ IDCloud सूचनाएं भेजेगा। इसे HTTPS होना चाहिए।

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

Endpoint फ़ील्ड, HTTPS आवश्यकता के बारे में हेल्पर टेक्स्ट के साथ।

Step 3 — चुनें कि IDCloud आपके API के विरुद्ध कैसे प्रमाणीकरण करे

"Authentication" के अंतर्गत, Authentication type चुनें। चार विकल्प हैं, और हर एक अलग-अलग फ़ील्ड मांगता है:

Type	दिखाई गई फ़ील्ड	कब उपयोग करें
None	कोई नहीं	आपके API को प्रमाणीकरण की आवश्यकता नहीं है। इसका उपयोग केवल तभी करें जब इसमें कोई अन्य सुरक्षा हो — बिना प्रमाणीकरण के, जो भी URL खोज लेता है वह इसे डेटा भेज सकता है
API Key	Secret	आपका API एक निश्चित कुंजी को वेलिडेट करता है
Basic Auth	Secret	आपका API HTTP Basic स्टाइल में username और password का उपयोग करता है
OAuth 2.0	Auth URL, Client ID, Secret	आपके API को एक टोकन की आवश्यकता है। IDCloud उस URL से टोकन प्राप्त करता है और इसे स्वयं रिन्यू करता है

OAuth 2.0 के लिए, Auth URL वह एड्रेस है जहाँ से IDCloud टोकन प्राप्त करता है — यह वह URL नहीं है जो सूचनाएं प्राप्त करता है। ये अलग-अलग एड्रेस हैं, और इन्हें आपस में बदल देना इस स्क्रीन पर सबसे सामान्य गलती है।

Secret एन्क्रिप्टेड स्टोर किया जाता है। मौजूदा वेबहुक को एडिट करते समय, फ़ील्ड खाली दिखाई देती है: इसे भरने से मौजूदा सीक्रेट ओवरराइट हो जाता है, और इसे खाली छोड़ने से जो पहले से मौजूद है वह बना रहता है।

सेव करने से पहले अपने API को मैनेज करने वाले व्यक्ति के साथ पद्धति की पुष्टि करें। गलत प्रमाणीकरण स्क्रीन पर कोई एरर उत्पन्न नहीं करता — यह एक ऐसी सूचना उत्पन्न करता है जो बाद में साइलेंटली फेल हो जाती है, और आपको इसका पता तभी चलता है जब कोई परिणाम नहीं आता।

Authentication type फ़ील्ड और संबंधित क्रेडेंशियल फ़ील्ड।

Step 4 — यदि आवश्यक हो, तो retries एडजस्ट करें

Retry configuration सेक्शन वैकल्पिक है और डिफ़ॉल्ट रूप से बंद रहता है। इसे केवल तभी ऑन करें जब आपको डिफ़ॉल्ट बिहेवियर बदलने की आवश्यकता हो।

इसे ऑन करने से छह फ़ील्ड दिखाई देती हैं:

Field	यह क्या नियंत्रित करता है	डिफ़ॉल्ट
Maximum retries	हार मानने से पहले IDCloud कितनी बार फिर से प्रयास करता है	—
Rate limit (req/s)	प्रति सेकंड अधिकतम सूचनाएं। यदि आपके API की क्षमता सीमित है तो इसे कम करें	—
Minimum time (s)	प्रयासों के बीच न्यूनतम अंतराल	2s
Maximum time (s)	प्रयासों के बीच अधिकतम अंतराल	10s
Maximum duration (s)	इसे विफलता मानने से पहले प्रति प्रयास कितना समय प्रतीक्षा करनी है	2s
Maximum doublings	प्रयासों के बीच अंतराल की वृद्धि दर (backoff)	5

संयुक्त बिहेवियर: IDCloud प्रयास करता है, minimum time प्रतीक्षा करता है, फिर से प्रयास करता है, और maximum doublings के अनुसार अंतराल को maximum time तक बढ़ाता रहता है — यह maximum retries तक दोहराता है। हर व्यक्तिगत प्रयास maximum duration के बाद हार मान लेता है।

कुछ और छूने से पहले Rate limit एडजस्ट करें। यदि लोड के तहत आपका API फेल हो जाता है, तो समस्या थ्रूपुट की है, retries की नहीं — और इस स्थिति में retries बढ़ाने से यह और बिगड़ जाता है, क्योंकि यह कॉल्स को मल्टीप्लाई कर देता है। पहले rate को कम करें।

Maximum retries बढ़ाना एक स्थिर API का विकल्प नहीं है। Retries क्षणिक अनुपलब्धता को कवर करते हैं। यदि आपका API बार-बार फेल होता है, तो यह सेटिंग केवल उस पल को टाल देती है जब आप सूचना खो देते हैं।

टॉगल ऑन करने के बाद दिखाई गई छह retry फ़ील्ड।

Step 5 — सेव करें

Save पर क्लिक करें। Cancel सब कुछ डिस्कार्ड कर देता है और पिछला कॉन्फ़िगरेशन बनाए रखता है।

जब पद्धति OAuth 2.0 है, तो IDCloud सेव करने की अनुमति देने से पहले टोकन URL को वेलिडेट करता है।

सेव करने के बाद, Your webhook कार्ड endpoint और प्रमाणीकरण प्रकार दिखाता है। सीक्रेट मास्क होकर दिखाई देता है और इसे स्क्रीन से फिर से प्राप्त नहीं किया जा सकता — यदि आप वैल्यू खो देते हैं, तो आपको एक नया सेट करना होगा।

इसे पूर्ण मानने से पहले एक वास्तविक टेस्ट चलाएं। Staging में एक जर्नी शुरू करें और पुष्टि करें कि सूचना आपके API तक पहुंची। स्क्रीन इस बात की पुष्टि करती है कि कॉन्फ़िगरेशन सेव हो गया, न कि यह कि आपके API को यह प्राप्त हुआ।

FAQ

क्या मैं एक से अधिक वेबहुक रजिस्टर कर सकता हूँ? नहीं। यह प्रत्येक tenant और branch के लिए एक वेबहुक है। यदि एक पहले से मौजूद है, तो उसे एडिट किया जाता है — दूसरा बनाने का कोई तरीका नहीं है।

मैंने इसे Staging में कॉन्फ़िगर किया। क्या यह Production पर भी लागू होता है? नहीं। वातावरण स्वतंत्र हैं: Staging पोर्टल UAT वेबहुक को कॉन्फ़िगर करता है, और Production वाला Production को कॉन्फ़िगर करता है। आपको Production पोर्टल में कॉन्फ़िगरेशन दोहराना होगा।

मैंने जो सीक्रेट रजिस्टर किया है उसे मैं कैसे देखूं? आप नहीं देख सकते। यह सेव होने पर एन्क्रिप्टेड होता है और हमेशा मास्क दिखाया जाता है। यदि आपने वैल्यू खो दी है, तो Secret फ़ील्ड के माध्यम से एक नया रजिस्टर करें — इसे भरने से पिछला वाला ओवरराइट हो जाता है।

मैंने वेबहुक एडिट किया लेकिन सीक्रेट बदलना नहीं चाहता। मुझे क्या करना चाहिए? Secret फ़ील्ड को खाली छोड़ दें। मौजूदा वैल्यू बनी रहती है।

मैं वेबहुक कैसे डिलीट करूं? स्क्रीन डिलीशन का विकल्प नहीं देती। कॉन्फ़िगरेशन हटाने के लिए, Unico सपोर्ट से संपर्क करें। यदि लक्ष्य केवल सूचनाएं प्राप्त करना बंद करना या डेस्टिनेशन बदलना है, तो इसके बजाय URL एडिट करें।

मैंने सेव किया और सूचनाएं नहीं आ रही हैं। इस क्रम में जांचें: URL सही है और HTTPS है; आपका API लाइव है; प्रमाणीकरण पद्धति वही है जो यह अपेक्षित करता है; और सीक्रेट सही टाइप किया गया था। प्रमाणीकरण विफलताएं इस स्क्रीन पर एरर के रूप में नहीं दिखती हैं — वे डिलीवरी के समय होती हैं।

"Maximum duration" और "Maximum time" में क्या अंतर है? "Maximum time" दो प्रयासों के बीच का सबसे लंबा अंतराल है। "Maximum duration" यह है कि IDCloud इसे विफलता मानने से पहले प्रति प्रयास कितना प्रतीक्षा करता है।

यदि मैं API के माध्यम से परिणाम के लिए पहले से पोल करता हूँ तो क्या मुझे वेबहुक की आवश्यकता है? यह आवश्यक नहीं है, लेकिन यह आपके सिस्टम को पोल करने से बचाता है। यदि आपके पास पहले से एक काम कर रही पोलिंग रूटीन है, तो वेबहुक एक ऑप्टिमाइज़ेशन है, आवश्यकता नहीं।

त्वरित संदर्भ

IDCloud पोर्टल
 └─ Settings (साइडबार में gear icon)
     └─ Webhook टैब
         ├─ Client information ....... Client URL (Endpoint), HTTPS
         ├─ Authentication ............ None | API Key | Basic Auth | OAuth 2.0
         │                             OAuth 2.0: + Auth URL और Client ID
         └─ Retries (वैकल्पिक) ....... Maximum retries
                                       Rate limit (req/s)
                                       Minimum time (2s) · Maximum time (10s)
                                       Maximum duration (2s) · Maximum doublings (5)

प्रत्येक tenant और branch के लिए एक वेबहुक · UAT और Production स्वतंत्र · Secret कभी नहीं दिखाया जाता · Cancel · Save