एक webhook handler को विफल डिलीवरी और सफलता दोनों के लिए परीक्षण चाहिए। जो परीक्षण send response पर रुक जाता है वह यह पुष्टि नहीं कर सकता कि आपका एप्लिकेशन बाद के इवेंट को कैसे संभालता है।
Magic destinations आपको वास्तविक inbox या हैंडसेट तक पहुँचे बिना उन परिणामों का अभ्यास करने देते हैं। अनुरोध सत्यापन फिर भी लागू होता है, इसलिए वे गलत तरीके से बने sends को भी उजागर करते हैं।
परीक्षण अनुरोध कैसे भेजें?
अपनी सामान्य API credentials और endpoint का उपयोग करके किसी पहचाने गए magic destination पर भेजें।
कोई test mode सक्षम करने की ज़रूरत नहीं है। Email के लिए, messagebird.dev पर एक प्रलेखित पता उपयोग करें। SMS के लिए, नीचे दिए गए नंबरों में से एक उपयोग करें।
सिमुलेटेड प्राप्तकर्ता सामान्य इवेंट और signed-webhook पथों का अनुसरण करते हैं। वे बाहरी इंफ्रास्ट्रक्चर पर डिलीवरी का अभ्यास नहीं करते। इसलिए वे वास्तविक inbox प्लेसमेंट या हैंडसेट रेंडरिंग की पुष्टि नहीं कर सकते।
जब परीक्षण में किसी से संपर्क नहीं होना चाहिए, तो केवल पहचाने गए magic destinations का उपयोग करें। एक अनुरोध में सिमुलेटेड और वास्तविक प्राप्तकर्ता मिले-जुले हो सकते हैं। वास्तविक प्राप्तकर्ताओं को सामान्य रूप से डिलीवर किया जाता है।
कौन-से email पते उपयोग करने चाहिए?
प्राप्तकर्ता सर्वर द्वारा स्वीकृति का परीक्षण करने के लिए delivered@messagebird.dev का उपयोग करें। नीचे दिए गए अन्य पते bounce, complaint और rejection हैंडलिंग का अभ्यास कराते हैं।
| पता | परिणाम |
|---|---|
delivered@messagebird.dev | प्राप्तकर्ता सर्वर संदेश स्वीकार करता है। |
bounce@messagebird.dev या hardbounce@messagebird.dev | SMTP 550 के साथ hard bounce; permanent-failure हैंडलिंग का परीक्षण करें। |
softbounce@messagebird.dev | SMTP 451 के साथ soft bounce; temporary-failure वर्गीकरण का परीक्षण करें। |
deferred@messagebird.dev या delay@messagebird.dev | बाद में कोई सिमुलेटेड retry न होने वाला deferral। |
complaint@messagebird.dev या spam@messagebird.dev | एक spam complaint। |
suppressed@messagebird.dev | पहले से suppressed प्राप्तकर्ता के रूप में rejection; कोई processing या delivery इवेंट नहीं। |
reject@messagebird.dev | डिलीवरी प्रयास से पहले rejection। |
मिलान केस-असंवेदी है। परिणाम चुनने से पहले यह +label हटा देता है। उदाहरण के लिए, bounce+signup-flow@messagebird.dev फिर भी bounce करता है। पूरा पता इवेंट्स में बना रहता है ताकि आप उन्हें उस परीक्षण से जोड़ सकें।
उस डोमेन पर केवल प्रलेखित नाम ही magic हैं। bounce@yourdomain.com एक सामान्य प्राप्तकर्ता है, जैसे messagebird.dev पर कोई अपरिचित नाम भी।
सिमुलेटेड bounces और complaints Bird की suppression सूची में पते नहीं जोड़ते और न ही sending reputation को प्रभावित करते हैं। आपका एप्लिकेशन फिर भी उनके इवेंट प्राप्त करता है, इसलिए जाँचें कि आपका अपना suppression लॉजिक उन्हें कैसे संभालता है।
Email डिलीवरी का परीक्षण करें पूर्ण इवेंट अनुक्रम और मिलान नियमों की सूची देता है।
कौन-से फ़ोन नंबर उपयोग करने चाहिए?
सफल SMS डिलीवरी का परीक्षण करने के लिए +15005550006 का उपयोग करें। नीचे दिए गए अन्य नंबर rejection और failure पथों का अभ्यास कराते हैं।
| Destination | परिणाम |
|---|---|
+15005550001 | invalid_destination के साथ submission rejection। |
+15005550002 | sms.sent, फिर unreachable के साथ sms.undelivered। |
+15005550003 | sms.sent, फिर provider_unavailable के साथ sms.failed। |
+15005550004 | sms.sent, फिर blocked_by_carrier के साथ sms.failed। |
+15005550006 | sms.sent, फिर sms.delivered। |
+15005550009 | sms.sent, फिर recipient_opted_out के साथ sms.failed। |
Destinations के अंतर्गत United States सक्षम करें। US के लिए मान्य एक from sender उपयोग करें। वहाँ alphanumeric sender अस्वीकृत हो जाता है, इसलिए वह इन नंबरों का सफलतापूर्वक परीक्षण नहीं कर सकता।
+15005550006 पर भेजकर अपने success handler का परीक्षण कर सकते हैं। अलग undelivered पथ की जाँच के लिए +15005550002 का उपयोग करें। SMS माइग्रेशन गाइड में एक smoke-test अनुक्रम शामिल है।
परीक्षण की लागत या प्रभाव क्या है?
सिमुलेटेड sends वास्तविक allowances का उपयोग करते हैं और आपके आँकड़ों को प्रभावित कर सकते हैं।
किसी magic number पर SMS की बिलिंग destination की सामान्य दर पर होती है। बार-बार परीक्षण सीमित रखें क्योंकि हर सिमुलेटेड send पर शुल्क लग सकता है।
एक सिमुलेटेड email प्राप्तकर्ता आपकी send allowance के विरुद्ध गिना जाता है। Email sandbox ट्रैफ़िक समग्र आँकड़ों में भी शामिल होता है, जिसमें bounce और complaint दरें भी हैं। अपने विश्लेषण में इसे अलग रखें ताकि परीक्षण विफलताएँ ग्राहक डिलीवरी समस्याओं जैसी न दिखें।
परीक्षण परिणाम की पहचान कैसे करें?
इवेंट को उस परीक्षण प्राप्तकर्ता या संदेश पहचानकर्ता से मिलाएँ जो आपने भेजते समय रिकॉर्ड किया था।
एक स्वीकृत सिमुलेटेड email 202 और सामान्य इवेंट आकार लौटाता है। पेलोड में कोई test flag नहीं होता। इसलिए केवल स्वीकृति से परीक्षण की पहचान नहीं होती।
Email इवेंट्स को किसी रन से जोड़ने के लिए bounce+signup-flow@messagebird.dev जैसे प्राप्तकर्ता label का उपयोग करें। आप webhook receiver चलाए बिना email संदेश की timeline या इवेंट्स API भी पढ़ सकते हैं।
जब आपको रेंडरिंग या प्राप्ति की पुष्टि करनी हो तो वास्तविक-डिलीवरी जाँच अलग रखें। Magic destinations डिलीवरी पथ के उन हिस्सों का परीक्षण नहीं करते।
संक्षेप में
Destination परीक्षण का परिणाम तय करता है।
अपनी सामान्य API key और endpoints का उपयोग करें। पहचाने गए पते और नंबर सिमुलेटेड डिलीवरी परिणाम ट्रिगर करते हैं।
परीक्षण केवल ज्ञात magic destinations तक सीमित रखें।
एक अनुरोध में सिमुलेटेड और वास्तविक प्राप्तकर्ता मिले-जुले हो सकते हैं। अपरिचित पतों को सामान्य प्राप्तकर्ताओं की तरह संसाधित किया जाता है।
परीक्षण में भी वास्तविक allowances खर्च होती हैं।
सिमुलेटेड email प्राप्तकर्ता send allowance का उपयोग करते हैं। SMS magic numbers पर destination की सामान्य दर से बिलिंग होती है।
रिकॉर्ड करें कि कौन-से संदेश किसी परीक्षण से संबंधित हैं।
इवेंट्स में कोई test flag नहीं होता। Email labels प्राप्तकर्ता पतों में बने रहते हैं, जिससे आप इवेंट्स में परीक्षण रन की पहचान कर सकते हैं।