هنوز ساخته نشده

فهمیدن با آزمون‌وخطا بدتر از این است که به شما گفته شود. هیچ‌کدام از این‌ها امروز وجود ندارد:

• —هر تحویل تا پنج بار تلاش می‌شود: همان لحظه، سپس پس از ۱ دقیقه، ۵، ۲۵ و ۲ ساعت. هر تلاش ثبت می‌شود و از راه GET /webhooks/{id}/deliveries خواندنی است، و هر کدام attempt و maxAttempts خودش را دارد. وقتی پاسخ بگوید تکرار بی‌فایده است، تلاش دوباره زودتر متوقف می‌شود: هر چیزی جز 408، 425، 429 یا یک 5xx ردّ عمدی تلقی می‌شود. هنوز اندپوینتی برای بازپخش نیست، پس اندپوینتی که بیش از آن بازه از دسترس خارج باشد شکافی برجا می‌گذارد، و لاگ تحویل جایی است که آن را می‌یابید.
• —پیامی که برگشت خورده باز هم از راه GET /emails به صورت sent خوانده می‌شود: گزارش تحویل به پیام اصلی تطبیق داده و روی رشته برچسب‌گذاری می‌شود، اما چیزی به سطر ارسال بازنوشته نمی‌شود، چون وضعیت آن حالت برگشت‌خورده ندارد. سرکوبی که این گزارش تغذیه می‌کند واقعی است: یک برگشت سخت یا یک شکایت، آن نشانی را در فهرست سرکوب همین فضای کاری می‌گذارد و ارسال بعدی به آن رد می‌شود. این رکورد ارسال است که چیزی نمی‌آموزد.
• —محدودکنندهٔ نرخ عمومی برای درخواست‌ها وجود ندارد. دو سقف شمارشی هست و هر دو 429 پاسخ می‌دهند: فضای کاری‌ای که سهمیهٔ ارسال ماهانهٔ پلنش را تمام کند تا اول ماه روی هر ارسال بعدی send_quota_exceeded می‌گیرد، و ساختن صندوق‌های یک‌بارمصرف به ازای هر کلاینت به شش در ساعت و سی در روز محدود است با too_many_inboxes. هیچ‌کدام Retry-After با خود ندارند. محدودکننده‌ای روی نرخ خواندن‌ها و نوشتن‌های معمول یک غیبت است نه یک وعده، و غیبتی که جبران خواهد شد.
• —اندپوینت آپلود پیوست روی API وجود ندارد. پیوست‌های درون‌خطی base64 هستند و در کل پیام به 5 MB محدودند. فایل بزرگ‌تر به صورت { fileId } فرستاده می‌شود، که به فایلی که از پیش در فضای کاری است اشاره می‌کند، و به شکل یک پیوند دانلود می‌رود. خواندن پیوست‌های نامه‌های دریافتی کار می‌کند.