از اینجا شروع کنید
خطاها و تلاش مجدد
ساختار استاندارد خطای JSON را parse کنید و تشخیص دهید چه زمانی تلاش مجدد امن است.
ساختار خطا
خطاهای JSON API از یک شیء error در سطح بالا استفاده می‌کنند که شامل یک message قابل‌فهم برای انسان، status عددی HTTP و یک code پایدار اختیاری است. قرارداد OpenAPI برای خطاهای مورد انتظار و غیرمنتظره به همین schema ارجاع می‌دهد.
{
"error": {
"code": "invalid_request",
"message": "A verified From domain is required",
"status": 403
}
}خطاهای سمت کلاینت
خطاهای ورودی 400 را پیش از تلاش مجدد اصلاح کنید. پس از 401 اعتبارنامه‌های نامعتبر را جایگزین یا باطل کنید. 402 به اشتراک پولی نیاز دارد، 403 نشان‌دهنده مرز سیاست یا مجوز است، 404 یعنی منبعی در محدوده tenant پیدا نشد، 409 تعارض وضعیت یا idempotency است، 413 از محدودیت پیوست فراتر رفته و 422 خطاهای اعتبارسنجی یا توقف ارسال را پوشش می‌دهد.
تصمیم‌گیری درباره تلاش مجدد
خطاهای احراز هویت، اعتبارسنجی، توقف ارسال یا تعارض را به‌صورت خودکار تکرار نکنید. 423 یعنی همان هویت From مشخص متوقف شده است؛ آن جریان را متوقف کنید، گیرندگانش را اصلاح کنید و فقط پس از آنکه معیارهای دوره‌ای آن به حالت عادی برگشت، دوباره تلاش کنید. فراخواننده می‌تواند پاسخ‌های گذرای 429، 502 یا 503 را با exponential backoff محدود و jitter دوباره امتحان کند. هنگام تلاش مجدد برای یک ارسال منطقی واحد، همان Idempotency-Key و payload یکسان JSON را حفظ کنید.
اطلاعات لازم برای پشتیبانی
زمان درخواست، مسیر، وضعیت HTTP، شناسه منبع SendHQ و فیلدهای غیرمحرمانه خطا را ثبت کنید. هرگز کلید API، کوکی نشست، متن پیام یا فهرست گیرندگان را در گزارش پشتیبانی قرار ندهید.