از اینجا شروع کنید

مهاجرت از Resend

ارسال‌های HTTP در Resend را به SendHQ نگاشت کنید و پیش از انتقال، مرزهای سازگاری را در نظر بگیرید.

مرز سازگاری

SendHQ فیلدهای رایج JSON به سبک Resend را برای ارسال‌های مستقیم HTTP می‌پذیرد، اما جایگزین مستقیم SDK ‏Resend نیست. adapter سمت سرور HTTP خود را به /api/v1/emails اشاره دهید؛ فرض نکنید SDKی که میزبان Resend در آن hardcode شده قابل پیکربندی مجدد است.

نگاشت فیلدها

from، to، cc، bcc، subject، html، text، reply_to و headers سفارشی ایمن مستقیماً نگاشت می‌شوند. SendHQ همچنین message_class، ارجاع به template میزبانی‌شده، draft_id و فیلدهای پاسخ/رشته گفتگو را می‌پذیرد. payloadهای React مخصوص Resend، آرایه‌های پیوست inline، tagها، audienceها، broadcastها و فیلدهای ارسال زمان‌بندی‌شده معادل پذیرفته‌شده‌ای ندارند.

پیوست‌ها و قالب‌ها

پیوست‌ها را روی یک پیش‌نویس SendHQ بارگذاری کنید و سپس با draft_id ارسال کنید. قالب‌های میزبانی‌شده منابعی از SendHQ با نسخه‌های منتشرشده و داده تایپ‌شده‌اند؛ به‌جای کپی کردن شناسه قالب ارائه‌دهنده، شناسه‌های قالب و فراخوانی‌های رندر را به‌صورت صریح مهاجرت دهید.

تلاش مجدد

برای هر ارسال منطقی یک Idempotency-Key پایدار تولید کنید. همان payload یکسان JSON را با همان کلید دوباره تلاش کنید. اگر موضوع، بدنه، گیرنده، هدر یا داده قالب تغییر کند، از کلید جدید استفاده کنید؛ در غیر این صورت SendHQ پاسخ 409 برمی‌گرداند. پاسخ ذخیره‌شده‌ای که دوباره برگردانده شود شامل Idempotent-Replayed: true است.

چک‌لیست انتقال

  1. هر دامنه From و نشانی دقیق فرستنده‌ای را که استفاده خواهید کرد تأیید کنید.
  2. پیام‌های کنترل‌شده متنی و HTML را به صندوق ورودی متعلق به خودتان بفرستید.
  3. پذیرش توسط ارائه‌دهنده را جدا از رویدادهای تحویل بررسی کنید.
  4. مدیریت 409، 422، 423، 429 و 5xx را آزمایش کنید.
  5. adapter ارائه‌دهنده قبلی را تا زمانی که هر دو مسیر تراکنشی و چرخه عمر (lifecycle) با موفقیت کار کنند در دسترس نگه دارید.