SMS डिलीवरी स्थिति कॉलबैक सेट करने का तरीका

सही कॉलबैक उपयोग मामले का चयन करें

एक प्रश्न से शुरू करें: कॉलबैक आपके व्यवसाय में क्या बदलाव लाना चाहिए? ऑर्डर अलर्ट, OTP डिलीवरी मॉनिटरिंग, या ग्राहक सूचनाओं के लिए, उत्तर आमतौर पर अलग होता है। एक स्टोर रसीद भेजने से पहले “डिलीवर” स्थिति की परवाह कर सकता है। एक बैंक “फेल” होने की परवाह कर सकता है 30 सेकंड के भीतर, क्योंकि एक लॉगिन कोड जो कभी नहीं पहुंचता, उसका सीधा समर्थन लागत होती है।

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

दायरा संकीर्ण रखें। एक शिपिंग टीम को श्रृंखला में अंतिम SMS के लिए केवल स्थिति अपडेट की आवश्यकता हो सकती है, हर अनुस्मारक के लिए नहीं। एक पासवर्ड-रीसेट प्रवाह को केवल तब कॉलबैक की आवश्यकता हो सकती है जब संदेश को स्वीकार या अस्वीकार किया जाए, क्योंकि “इंतज़ार” एक उपयोगकर्ता के लिए उपयोगी स्थिति नहीं है जो पहले से ही लॉगिन स्क्रीन पर देख रहा है।

अपने SMS प्रदाता के कॉलबैक मॉडल की पुष्टि करें

प्रदाता सभी एक ही भाषा में बात नहीं करते। कुछ डिलीवरी रसीदें उपयोग करते हैं, कुछ वेबहुक का उपयोग करते हैं, और कुछ एक स्थिति URL को उजागर करते हैं जिसे आपको पोल करना होता है। सटीक घटना नामों के लिए प्रदाता दस्तावेज़ पढ़ें और जांचें कि कौन सी स्थितियाँ उपलब्ध हैं।

एक प्रदाता केवल अंतिम स्थितियाँ भेज सकता है। दूसरा एक संदेश के लिए कई अपडेट भेज सकता है, और यह बाद में डेटा को संग्रहीत करने के तरीके को बदलता है। यदि प्रदाता संदेश-स्तरीय और खाता-स्तरीय कॉलबैक दोनों का समर्थन करता है, तो उस विकल्प को चुनें जो ऊपर चुने गए कार्यप्रवाह से मेल खाता है। यह विवरण पहले परीक्षण के आने पर भ्रम को बचाता है और आपका ऐप एक SMS के लिए दो घटनाएँ देखता है।

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

उन टीमों के लिए जो पहले से ही अन्य घटना-आधारित प्रणालियों को संभालती हैं, पैटर्न परिचित लगेगा। लॉजिक लेनदेनात्मक ईमेल के लिए ईमेल वेबहुक घटनाओं के समान है: आपको यह जानने की आवश्यकता है कि कौन सी घटनाएँ मौजूद हैं, कौन सी आपके लिए महत्वपूर्ण हैं, और कौन सी कभी भी ग्राहक-समर्थित लॉजिक को ट्रिगर नहीं करनी चाहिए।

अपने सार्वजनिक कॉलबैक अंत बिंदु को तैयार करें

आपके कॉलबैक एंडपॉइंट को एक सार्वजनिक HTTPS URL की आवश्यकता है। न कि एक स्थानीय पोर्ट। न कि एक निजी IP। प्रदाता को इसे आपके नेटवर्क के बाहर से पहुंचना चाहिए, और अधिकांश SMS प्लेटफार्म उत्पादन में साधारण HTTP को अस्वीकार कर देंगे। एक सामान्य संरचना /webhooks/sms/status है, क्योंकि यह लॉग और डैशबोर्ड भरने पर पढ़ने योग्य रहता है।

मार्ग को स्थिर बनाएं। यदि आप इसे हर सप्ताह नाम बदलते हैं, तो आपके डैशबोर्ड सेटिंग्स आपके कोड से पीछे रह जाएंगी। पहले संस्करण के लिए एक पथ, एक विधि, और एक हैंडलर का उपयोग करें। POST सामान्य विकल्प है।

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

प्रदाता को कनेक्ट करने से पहले एक साधारण अनुरोध बॉडी के साथ मार्ग का परीक्षण करें। एक डमी POST पर 200 प्रतिक्रिया आपको बाद में एक लंबे डिबगिंग सत्र से अधिक बताती है। यदि आप पहले से ही अन्य चैनलों से कॉलबैक डिज़ाइन के साथ सहज हैं, तो वही अनुशासन वेब पुश अधिसूचना सर्वोत्तम प्रथाओं में दिखाई देता है, विशेष रूप से प्रतिक्रिया समय और एंडपॉइंट स्पष्टता के आसपास।

आपके ऐप को आवश्यक इवेंट पेलोड को परिभाषित करें

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

अपने मैपिंग को सख्त रखें। यदि प्रदाता एक फ़ील्ड को sms_id कहता है और आपका डेटाबेस provider_message_id का उपयोग करता है, तो अनुवाद को एक बार लिखें और पुन: उपयोग करें। इससे “स्टेजिंग में काम करता है” समस्याओं से बचा जा सकता है जब एक दूसरा एकीकरण आता है। एक कॉलबैक पेलोड को एक SMS रिकॉर्ड को अपडेट करना चाहिए, रहस्यमय डुप्लिकेट नहीं बनाना चाहिए।

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

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

अपने SMS सेटिंग्स में कॉलबैक को रजिस्टर करें

अधिकांश प्रदाता आपको डैशबोर्ड स्क्रीन में या API सेटिंग के माध्यम से कॉलबैक URL दर्ज करने की अनुमति देते हैं। कुछ को पहले खाता स्तर पर सेटअप की आवश्यकता होती है, फिर बाद में संदेश स्तर पर ओवरराइड। डिलीवरी कॉलबैक, स्थिति कॉलबैक, वेबहुक URL, या रसीद URL जैसे लेबल की तलाश करें। शब्दावली भिन्न होती है, लेकिन लक्ष्य वही रहता है।

जब डैशबोर्ड आपसे फ़ील्ड नामों के लिए पूछता है, तो प्रदाता के सटीक फ़ील्ड नामों का उपयोग करें। डिलीवरी घटनाओं के लिए एक URL इनबाउंड उत्तरों के लिए एक URL से अलग हो सकता है। यदि आप दोनों को मिलाते हैं, तो आपका ऐप डेटा प्राप्त कर सकता है जिसे वह व्याख्या नहीं कर सकता। यह एक साधारण गलती है, और यह इतनी सामान्य है कि इसे चेकलिस्ट आइटम के रूप में शामिल किया जाना चाहिए।

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

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

आगामी अनुरोधों को सुरक्षित और प्रमाणित करें

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

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

IP अनुमति सूची सरल लगती है जब तक कि प्रदाता बुनियादी ढांचे को नहीं बदलता। इसका उपयोग केवल तभी करें जब प्रदाता निश्चित रेंज प्रकाशित करता है और उन्हें अपडेट रखता है। गुप्त टोकन आमतौर पर बनाए रखना आसान होता है, और हस्ताक्षर मान्यता एक स्थिर टोकन से अधिक मजबूत होती है। एक त्वरित aside: यदि आपकी सुरक्षा टीम तीनों की मांग करती है, तो वे नाटकीय नहीं हो रहे हैं।

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

अपने सिस्टम में डिलीवरी अपडेट स्टोर करें

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

स्थिति परिवर्तनों को क्रम में लिखें। यदि प्रदाता ने कतारबद्ध, फिर भेजा, फिर वितरित किया, तो उस अनुक्रम को बनाए रखें। यदि एक पुराना कॉलबैक देर से आता है, तो उसे अनदेखा करें या इसे सहेजने से पहले नवीनतम ज्ञात स्थिति के खिलाफ तुलना करें। एक विलंबित “भेजा गया” अपडेट को नए “वितरित” स्थिति को अधिलेखित नहीं करना चाहिए।

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

एक साधारण तालिका टीम को स्थिति प्रबंधन पर सहमत होने में मदद कर सकती है:

डाउनस्ट्रीम रिपोर्टिंग के बारे में भी सोचें। यदि आपकी ग्राहक सफलता टीम अभियान के अनुसार वितरण दर देखना चाहती है, तो संदेश के साथ एक अभियान ID स्टोर करें। यदि वित्त OTP मात्रा को समेटना चाहता है, तो टेम्पलेट नाम रखें। छोटे फ़ील्ड लंबे बैठकों को बचाते हैं।

अलर्ट और फॉलबैक हैंडलिंग सेट करें

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

“कॉलबैक बंद” के लिए एक अलर्ट सेट करें, “मान्यता विफल” के लिए एक और, और “त्रुटि स्थिति प्राप्त” के लिए एक तीसरा। ये तीन अलग-अलग समस्याएँ हैं। एक गायब कॉलबैक का मतलब नेटवर्क की समस्या हो सकती है। एक विफल स्थिति का मतलब हो सकता है कि कैरियर ने SMS को अस्वीकार कर दिया। एक मान्यता विफलता का मतलब हो सकता है कि आपका रहस्य घुमाया गया और प्रदाता को अपडेट नहीं किया गया।

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

यदि आपकी टीम पहले से ही अन्य चैनलों में डिलीवरबिलिटी संकेतों पर नज़र रखती है, तो समान आदतें ईमेल बाउंस हैंडलिंग सर्वोत्तम प्रथाओं में लागू होती हैं। चैनल अलग है, लेकिन संचालनात्मक प्रतिक्रिया वही है: त्रुटि स्थितियों पर नज़र रखें, उन्हें साफ-सुथरा लॉग करें, और निर्णय लें कि कब पुनः प्रयास करना है, चेतावनी देनी है, या रोकना है।

बैकअप नियम को एक स्थान पर दस्तावेज़ित करें और समर्थन को इसे पढ़ने के लिए कहें। एक ग्राहक को यह अनुमान नहीं लगाना चाहिए कि क्या एक विफल SMS स्वचालित रूप से पुनः प्रयास करेगा। यदि उत्तर “OTPs के लिए नहीं” है, तो इसे स्पष्ट रूप से कहें। यदि उत्तर “10 मिनट बाद पोल करें” है, तो सही संख्या एक बार लिखें और इसे हर जगह उपयोग करें।