لم يُبنَ بعد

أن تكتشف بالمحاولة أسوأ من أن يُقال لك. لا شيء من هذا موجود اليوم:

• —تُجرَّب عملية التسليم حتى خمس مرات: فور حدوثها، ثم بعد دقيقة واحدة، و5، و25، وساعتين. تُسجَّل كل محاولة ويمكن قراءتها عبر GET /webhooks/{id}/deliveries، وتحمل كل منها attempt وmaxAttempts. وتتوقف إعادة المحاولة مبكرًا حين تقول الاستجابة إن تكرارها لا طائل منه: فأي شيء غير 408 أو 425 أو 429 أو 5xx يُؤخذ على أنه رفض متعمَّد. وما زال لا توجد نقطة نهاية لإعادة التشغيل، فنقطة نهاية معطّلة لمدة أطول من تلك النافذة تُخلّف فجوة، وسجل التسليم هو حيث تجدها.
• —الرسالة المرتدّة ما زالت تُقرأ على أنها sent عبر GET /emails: فتقرير التسليم يُطابَق بالأصل ويُسمَّى على السلسلة، لكن لا شيء يكتب عائدًا إلى صف الإرسال، الذي لا تحتوي حالته على حالة ارتداد. أما التثبيط الذي يغذّيه فحقيقي: فالارتداد الصلب أو الشكوى يضع العنوان على قائمة تثبيط مساحة العمل هذه ويُرفَض الإرسال التالي إليه. سجل الإرسال هو ما لا يتعلّم.
• —لا يوجد محدِّد عام لمعدل الطلبات. لكن يوجد سقفان محسوبان وكلاهما يجيب بـ 429: مساحة العمل التي تستنفد حصة الإرسال الشهرية التي تتضمنها خطتها تحصل على send_quota_exceeded على كل إرسال لاحق حتى أول الشهر، وصكّ صناديق الوارد المؤقتة محدود بستة في الساعة وثلاثين في اليوم لكل عميل مع too_many_inboxes. ولا يحمل أيٌّ منهما Retry-After. أما محدِّد معدل القراءات والكتابات العادية فهو غياب لا وعد، وغياب سيُصحَّح.
• —لا توجد نقطة نهاية لرفع المرفقات على الـ API. المرفقات المضمّنة هي base64 وبسقف 5 MB عبر الرسالة كلها. والملف الأكبر يُرسَل بصيغة { fileId }، مسمّيًا ملفًا موجودًا أصلًا في مساحة العمل، ويسافر كرابط تنزيل. أما قراءة المرفقات من البريد المستلَم فتعمل.