एक स्वीकृत भेजना बाद में डिलीवरी के दौरान विफल हो सकता है। उसके रिस्पॉन्स हेडर रखने से सपोर्ट मूल कॉल की जाँच मैसेज के बाद के इवेंट के साथ कर सकता है।
Request ID कहाँ मिलेगा?
सफल और विफल कॉल पर X-Request-Id रिस्पॉन्स हेडर पढ़ें। Bird विफलताओं पर शीर्ष-स्तरीय error ऑब्जेक्ट के अंदर request_id भी शामिल करता है।
जब आपका क्लाइंट रिस्पॉन्स प्राप्त करे तब हेडर सेव करें। सफल भेजने के लिए भी इसे लॉग में शामिल करें, क्योंकि अप्रत्याशित डिलीवरी परिणाम बाद में आ सकता है।
सपोर्ट को क्या भेजें?
प्रभावित प्रयास का request ID, उसका समय, ऑपरेशन और अप्रत्याशित परिणाम भेजें। HTTP स्टेटस और कोई भी त्रुटि code और name शामिल करें।
फिर से प्रयास का अपना request ID होता है। अगर पहला प्रयास विफल हुआ और दूसरा सफल रहा, तो विफलता के बारे में पूछते समय पहले प्रयास का ID शामिल करें।
डिलीवरी संबंधी सवालों के लिए message ID भी शामिल करें। एक ईमेल बैच अनुरोध एक request ID के तहत 100 तक मैसेज कतार में लगा सकता है।
मेरा क्लाइंट क्या लॉग करे?
हर प्रयास के लिए रिस्पॉन्स हेडर, HTTP स्टेटस, अनुरोध समय और ऑपरेशन लॉग करें। त्रुटियों के लिए एनवेलप से code, name और request_id भी रिकॉर्ड करें।
ये फ़ील्ड अलग-अलग सवालों के जवाब देते हैं। कोड प्रलेखित विफलता की पहचान करता है। नाम लॉग को पढ़ने योग्य बनाता है। Request ID सपोर्ट को प्रयास ट्रेस करने देता है।
लौटाए गए message ID को अपने एप्लिकेशन के भेजने के रिकॉर्ड के साथ रखें। केवल इन आइडेंटिफ़ायर को बनाए रखने के लिए क्रेडेंशियल या मैसेज बॉडी लॉग करने से बचें।
इवेंट को अपने रिकॉर्ड से कैसे जोड़ें?
send endpoint जो फ़ील्ड सपोर्ट करता है, उनका इस्तेमाल करके अपने एप्लिकेशन का आइडेंटिफ़ायर अटैच करें। ईमेल भेजने के लिए, metadata और tags webhook इवेंट में वापस आते हैं।
उदाहरण के लिए, एक ऑर्डर आइडेंटिफ़ायर डिलीवरी इवेंट को उस ऑर्डर से जोड़ सकता है जिसने ईमेल ट्रिगर किया। API कॉल की जाँच के लिए request ID अलग से रखें।
कौन सा आइडेंटिफ़ायर इस्तेमाल करें?
एक API प्रयास के लिए request ID और डिलीवरी इतिहास के लिए message ID इस्तेमाल करें।
| आइडेंटिफ़ायर | इसका उपयोग |
|---|---|
X-Request-Id | एक API प्रयास के बारे में सपोर्ट से पूछना। |
| Message ID | एक मैसेज को उसके डिलीवरी इवेंट में ट्रैक करना। |
Idempotency-Key | जानबूझकर दूसरा ऑपरेशन बनाए बिना वही write फिर से प्रयास करना। |
webhook-id | एक ही इवेंट की दोहराई गई डिलीवरी को डीडुप्लिकेट करना। |
metadata या tags में आपका आइडेंटिफ़ायर | सपोर्टेड इवेंट को अपने एप्लिकेशन के रिकॉर्ड से जोड़ना। |
एक write के फिर से प्रयासों में idempotency key स्थिर रखें। Request ID हर प्रयास के साथ बदलता है। Webhook इवेंट डिलीवरी के फिर से प्रयासों में अपना आइडेंटिफ़ायर बनाए रखता है।
त्रुटि गाइड दिखाती है कि त्रुटि प्रतिक्रियाओं में request ID कहाँ दिखता है।
संक्षेप में
रिस्पॉन्स हेडर लॉग करें।
X-Request-Idप्रयास की पहचान करता है, चाहे वह सफल हो या विफल। त्रुटियों में उनके एनवेलप मेंrequest_idभी शामिल होता है।हर फिर से प्रयास को अलग रखें।
फिर से प्रयास करने पर एक नया request ID मिलता है, भले ही वही idempotency key इस्तेमाल हो।
डिलीवरी संबंधी सवालों के लिए message ID शामिल करें।
एक API कॉल कई मैसेज कतार में लगा सकता है, इसलिए केवल उसका request ID प्रभावित प्राप्तकर्ता की पहचान करने के लिए पर्याप्त न भी हो।
रिकॉर्ड जोड़ने के लिए एप्लिकेशन आइडेंटिफ़ायर इस्तेमाल करें।
ईमेल भेजने पर, metadata और tags आपके आइडेंटिफ़ायर को webhook इवेंट में ले जाते हैं।