अभी नहीं बना

आज़माकर पता लगाना, बता दिए जाने से बुरा है। इनमें से कुछ भी आज मौजूद नहीं है:

• —डिलीवरी पाँच बार तक आज़माई जाती है: तुरंत, फिर 1 मिनट, 5, 25 और 2 घंटे बाद। हर प्रयास दर्ज होता है और GET /webhooks/{id}/deliveries से पढ़ा जा सकता है, हर एक अपना attempt और maxAttempts लिए हुए। जब जवाब बता देता है कि दोहराना बेकार है तो पुनःप्रयास जल्दी रुक जाता है: 408, 425, 429 या किसी 5xx के अलावा सब कुछ जानबूझकर किया गया अस्वीकरण माना जाता है। रीप्ले एंडपॉइंट अब भी नहीं है, इसलिए उस विंडो से ज़्यादा देर बंद रहा एंडपॉइंट एक अंतराल छोड़ता है, और वह अंतराल डिलीवरी लॉग में मिलता है।
• —बाउंस हुआ संदेश GET /emails में अब भी sent ही दिखता है: डिलीवरी रिपोर्ट मूल संदेश से मिलाई जाती है और थ्रेड पर लेबल होती है, पर send row में कुछ वापस नहीं लिखा जाता, जिसकी status में कोई bounced अवस्था है ही नहीं। जो दमन यह पोषित करता है वह असली है: hard bounce या शिकायत उस पते को इस वर्कस्पेस की suppression सूची में डाल देती है और उसे अगला भेजना मना हो जाता है। बस send रिकॉर्ड ही नहीं सीखता।
• —सामान्य अनुरोध दर-सीमक नहीं है। गिनी जाने वाली दो सीमाएँ ज़रूर हैं और दोनों 429 देती हैं: जो वर्कस्पेस अपने प्लान में शामिल मासिक भेजने की सीमा खर्च कर देता है उसे महीने की पहली तारीख तक हर आगे के भेजने पर send_quota_exceeded मिलता है, और डिस्पोजेबल इनबॉक्स बनाना प्रति क्लाइंट छह प्रति घंटा और तीस प्रति दिन पर सीमित है, too_many_inboxes के साथ। इनमें से किसी में Retry-After नहीं होता। सामान्य पढ़ने-लिखने की दर पर सीमक एक अनुपस्थिति है, वादा नहीं, और उसे ठीक किया जाएगा।
• —API पर अटैचमेंट अपलोड एंडपॉइंट नहीं है। इनलाइन अटैचमेंट base64 होते हैं और पूरे संदेश पर 5 MB तक सीमित हैं। इससे बड़ी फ़ाइल { fileId } के रूप में भेजी जाती है, जो वर्कस्पेस में पहले से मौजूद फ़ाइल को नाम देती है, और डाउनलोड लिंक के रूप में जाती है। प्राप्त मेल से अटैचमेंट पढ़ना काम करता है।