डीएलटी एपीआई एकीकरण गाइड
डीएलटी अनुमोदन तभी उपयोगी है जब डेवलपर्स अनुमोदित पेलोड भेज सकें।
डीएलटी अनुमोदन के बाद, व्यावहारिक कार्य प्रदाता एपीआई फ़ील्ड, टेम्पलेट आईडी, प्रेषक हेडर, वेरिएबल ऑर्डर, डिलीवरी रिपोर्ट, पुनः प्रयास व्यवहार, लॉगिंग और एक रनबुक पर स्थानांतरित हो जाता है जिसे समर्थन समझ सकता है।
डीएलटी अनुमोदन के बाद एसएमएस गेटवे एपीआई एकीकरण वह जगह है जहां व्यवसाय अनुपालन कार्य उत्पादन सॉफ्टवेयर से मिलता है। पोर्टल स्वीकृत हेडर और टेम्प्लेट दिखा सकता है, लेकिन एप्लिकेशन को अभी भी प्रदाता के एपीआई के माध्यम से सटीक स्वीकृत संदेश पैटर्न भेजने की आवश्यकता है।
यह गाइड डेवलपर्स, संस्थापकों और संचालन टीमों के लिए है जो डीएलटी पंजीकरण के बाद एक ऐप में ओटीपी, ऑर्डर अलर्ट, रिमाइंडर और सेवा सूचनाएं भेज रहे हैं।
एपीआई हैंडऑफ़ मानक
त्वरित उत्तर
डीएलटी अनुमोदन के बाद, उत्पादन कोड लिखने से पहले एक पेलोड मानचित्र बनाएं।
एक डेवलपर हैंडऑफ़ में शामिल होना चाहिए:
- एसएमएस प्रदाता खाता और एपीआई दस्तावेज़ीकरण।
- प्रत्येक संदेश के लिए स्वीकृत प्रेषक शीर्षलेख.
- प्रत्येक संदेश के लिए सामग्री टेम्पलेट आईडी.
- प्रदाता द्वारा आवश्यक पीई आईडी या अन्य डीएलटी पहचानकर्ता।
- परिवर्तनीय क्रम और अनुमत मूल्य उदाहरण।
- डमी डेटा का उपयोग करके नमूना अनुरोध और प्रतिक्रिया।
- डिलीवरी रिपोर्ट वेबहुक विवरण।
- पुनः प्रयास करें, समयबाह्य और विफलता-हैंडलिंग नियम।
- टेम्प्लेट शब्दों और आईडी के लिए नियंत्रण बदलें।
डीएलटी अनुमोदन के बाद डेवलपर्स को क्या चाहिए
डेवलपर्स को स्क्रीनशॉट से कहीं अधिक की आवश्यकता है। उन्हें एक नियतात्मक अनुबंध की आवश्यकता है।
| इनपुट | यह क्यों मायने रखता है? |
|---|---|
| प्रदाता क्रेडेंशियल | एपीआई कॉल को प्रमाणित करने के लिए आवश्यक है। दस्तावेज़ों में नहीं, सुरक्षित रूप से संग्रहित करें। |
| प्रेषक शीर्षलेख | प्रेषक की पहचान को नियंत्रित करता है और अनुमोदित डीएलटी संपत्ति से मेल खाना चाहिए। |
| टेम्पलेट आईडी | संदेश के मुख्य भाग को स्वीकृत सामग्री टेम्पलेट से जोड़ता है। |
| परिवर्तनशील क्रम | मानों को गलत प्लेसहोल्डर में उतरने से रोकता है। |
| पीई या इकाई पहचानकर्ता | कुछ प्रदाता एपीआई या डीएलटी मैपिंग के लिए आवश्यक हैं। |
| डीएलआर समापनबिंदु | सिस्टम को डिलीवरी स्थिति और विफलता विवरण प्राप्त करने देता है। |
| परीक्षण के मामले | ग्राहक ट्रैफ़िक से पहले उत्पादन व्यवहार की पुष्टि करता है। |
यदि कोई पंक्ति गायब है, तो एकीकरण सैंडबॉक्स में काम कर सकता है लेकिन लाइव भेजने के दौरान विफल हो जाता है।
पेलोड मैपिंग मॉडल
प्रदाता एपीआई अलग-अलग हैं, इसलिए फ़ील्ड नामों को आँख बंद करके कॉपी न करें। एक प्रदाता-विशिष्ट पेलोड मानचित्र बनाएं।
डीएलटी एसएमएस एपीआई पेलोड वर्कशीट
| संकल्पना | उदाहरण फ़ील्ड नाम | उदाहरण डमी मान | टिप्पणियाँ |
|---|---|---|---|
| प्राप्तकर्ता | to | 919999999999 | केवल निजी परीक्षण योजनाओं में वास्तविक परीक्षण संख्याओं का उपयोग करें। |
| प्रेषक | sender | ABCOTP | अनुमोदित हेडर से मेल खाना चाहिए. |
| टेम्पलेट | template_id | TMP-XXXX-7754 | संदेश ईवेंट नाम के साथ स्टोर करें. |
| चर | variables | ["123456", "5"] | ऑर्डर टेम्प्लेट प्लेसहोल्डर्स से मेल खाना चाहिए। |
| इकाई | pe_id | PE-XXXX-1420 | प्रदाता-विशिष्ट आवश्यकता. |
| कॉलबैक | callback_url | /api/sms/dlr | यदि प्रदाता उनका समर्थन करता है तो हस्ताक्षर मान्य करें। |
स्रोत कोड में कभी भी एपीआई कुंजियाँ या प्रदाता रहस्य न लिखें। होस्टिंग सेटअप के साथ संरेखित पर्यावरण चर या गुप्त भंडारण का उपयोग करें।
डिलीवरी रिपोर्ट, पुनः प्रयास और लॉग
200 OK प्रदाता की प्रतिक्रिया के बाद एसएमएस एकीकरण बंद नहीं होना चाहिए। प्रदाता अनुरोध स्वीकार कर सकता है और बाद में विफल डिलीवरी स्थिति लौटा सकता है।
डीएलआर और विफलता-हैंडलिंग चेकलिस्ट
- सहसंबंध के लिए स्टोर प्रदाता संदेश आईडी।
- जहां समर्थित हो वहां डिलीवरी रिपोर्ट कॉलबैक प्राप्त करें।
- यदि प्रदाता हस्ताक्षर या टोकन प्रवाह का दस्तावेजीकरण करता है तो कॉलबैक प्रामाणिकता को मान्य करें।
- एपीआई सबमिशन विफलता को नेटवर्क डिलीवरी विफलता से अलग करें।
- क्षणिक प्रदाता त्रुटियों के लिए पुनः प्रयास नियम परिभाषित करें।
- टेम्प्लेट, हेडर या डीएलटी मैपिंग अमान्य होने पर आँख बंद करके पुनः प्रयास करने से बचें।
- संवेदनशील ओटीपी मान संग्रहीत किए बिना डीबग करने के लिए पर्याप्त संदर्भ लॉग करें।
- जब विफलता दर एक सीमा पार कर जाती है तो अलर्ट ऑपरेशन।
ओटीपी प्रवाह के लिए, पुनः प्रयास करते समय विशेष रूप से सावधान रहें। किसी उपयोगकर्ता को एप्लिकेशन को यह समझे बिना कि कौन सा वर्तमान है, कई वैध कोड प्राप्त नहीं होने चाहिए।
गो-लाइव परीक्षण योजना
उत्पादन से पहले, प्रत्येक अनुमोदित टेम्पलेट का परीक्षण करें:
स्थैतिक मानचित्रण समीक्षा
स्वीकृत पोर्टल टेम्पलेट, हैंडओवर शीट और प्रदाता पेलोड फ़ील्ड की तुलना करें। नामों की कतार लगनी चाहिए.
नियंत्रित प्रेषण
केवल आंतरिक परीक्षण नंबर भेजें। प्रेषक प्रदर्शन, संदेश का मुख्य भाग, चर और प्रदाता प्रतिक्रिया की पुष्टि करें।
डिलिवरी रिपोर्ट की जांच
कॉलबैक, स्टेटस मैपिंग, लॉग और विफलता प्रबंधन सत्यापित करें।
रनबुक हैंडओवर
दस्तावेज़ में नया टेम्प्लेट कैसे जोड़ें, प्रदाता कुंजियाँ घुमाएँ, डीबग विफलताएँ और समर्थन का अनुरोध करें।
सामान्य एपीआई एकीकरण गलतियाँ
बिना नाम के हार्डकोडिंग टेम्प्लेट आईडी
आईडी को संदेश ईवेंट नामों से जोड़ा जाना चाहिए। अन्यथा, कोई नहीं जानता कि कौन सी आईडी लॉगिन ओटीपी, ऑर्डर अपडेट या अपॉइंटमेंट रिमाइंडर की है।
कोड में स्वीकृत शब्दों को बदलना
बेहतर यूएक्स के लिए डेवलपर्स कॉपी जोड़ सकते हैं, लेकिन उत्पादन एसएमएस अनुमोदित टेम्पलेट पैटर्न से मेल खाना चाहिए।
डिलीवरी रिपोर्ट को नजरअंदाज करना
स्वीकृत एपीआई अनुरोध वितरित संदेशों के समान नहीं हैं। प्रदाता डिलीवरी स्थिति को ट्रैक करें।
लॉगिंग रहस्य या ओटीपी मान
लॉग को क्रेडेंशियल्स, ग्राहक रिकॉर्ड या संवेदनशील कोड को उजागर किए बिना डिबग रूटिंग और स्थिति में मदद करनी चाहिए।
अक्सर पूछे जाने वाले प्रश्न
क्या एसएमएस एपीआई को डीएलटी अनुमोदन से पहले एकीकृत किया जा सकता है?
आप पहले प्रदाता क्लाइंट को तैयार कर सकते हैं, लेकिन उत्पादन पेलोड को अनुमोदित हेडर, टेम्पलेट आईडी, परिवर्तनीय क्रम और वर्तमान प्रदाता आवश्यकताओं का उपयोग करना चाहिए।
यदि टेम्प्लेट शब्दांकन बदल जाए तो क्या होगा?
इसे उत्पादन परिवर्तन के रूप में मानें। डीएलटी प्रभाव की समीक्षा करें, प्रदाता मैपिंग को अपडेट करें, पुनः परीक्षण करें और लाइव उपयोग से पहले रनबुक को अपडेट करें।
क्या ओटीपी मानों को एसएमएस लॉग में संग्रहीत किया जाना चाहिए?
लॉग में संवेदनशील ओटीपी मान संग्रहीत करने से बचें। कोड लीक किए बिना डिबगिंग के लिए आवश्यक सहसंबंध आईडी और स्थिति विवरण संग्रहीत करें।
क्या शिंका डीएलटी एपीआई एकीकरण में मदद कर सकती है?
हाँ. शिंका अनुमोदित डीएलटी परिसंपत्तियों को प्रदाता एपीआई फ़ील्ड में मैप कर सकता है, नमूना पेलोड बना सकता है, परीक्षण भेज सकता है और अंतिम हैंडऑफ़ का दस्तावेजीकरण कर सकता है।
