溫柔、可回復的移轉橋接

保留熟悉的寄送呼叫，
換一個更懂你的落點。

ForwardHello 接受目前 Resend Node.js SDK 使用的 Email Route，因此你可以先只更換 API Key 與 baseUrl，小心地開始移轉；準備好後，再切換至完整的 ForwardHello SDK。

從 Sandbox 開始查看完整快速開始

這座橋不會代理你的舊 Resend 帳號。每一次呼叫都使用 ForwardHello 的驗證、額度、Suppression、內容保留與寄送控制。

migration.ts

import { Resend } from "resend";

const forward = new Resend(process.env.FORWARD_API_KEY!, {
  baseUrl: process.env.FORWARD_BASE_URL!
});

const { data, error } = await forward.emails.send(
  {
    from: "Mia <hello@paperkite.co>",
    to: "friend@example.com",
    subject: "歡迎加入 ✨",
    html: "<strong>一起寄出美好的第一封信。</strong>"
  },
  { idempotencyKey: "welcome/customer-1042" }
);

emails.send

單封寄送、排程、Header、Tag，以及 Base64 字串附件。

batch.send

每批最多 100 封；同樣不接受附件與排程。

emails.list / get

既有 Resend SDK 讀取方法會回傳 ForwardHello Email 紀錄。

emails.update / cancel

變更或取消排程 Email 時，仍會套用 ForwardHello 一般安全檢查。

不要假設一般帳號匯出會包含封鎖名單。

Resend 的官方 CSV 匯出文件目前沒有將 Suppression 列為獨立資源。請匯出或查詢底層 Email 歷史中的 bounced、complained 與 suppressed 結果，合併自己的 Webhook 紀錄，再將收件人縮減成單一 email 欄位。ForwardHello 會把聯集匯入整個 Workspace，避免 Region 缺口變成意外寄送。

查看 Resend Suppression 範圍

同一個 Resend 網域不能同時在兩個帳號中啟用。

若第一次所有權證明後，ForwardHello 偵測到 Resend 回覆「already registered」，寄送會維持鎖定，並開啟私人營運 Queue。ForwardHello 會啟動 Resend Domain Claim、提供完整的第二筆 TXT Record、從公開 DNS 驗證，之後才重試供應商設定。在新 SPF 與 DKIM Record 準備完成前，請保留舊 DNS 與流量路徑；近期仍有活動的網域可能需要 Resend Support 協助。

閱讀供應商限制

五個小心步驟

切換流量，也保留完整的安全軌跡。

先保護收件人，再依序證明身分、憑證、Payload 與寄送結果。相容 Route 不會放寬 ForwardHello 的正式環境閘門。

先建立封鎖名單 CSV

從 Resend Email 匯出與你自己的 Event 歷史收集退信、垃圾郵件檢舉與已封鎖收件人，每列只放一個 Email 地址。合併所有預計移轉的 Resend 寄送 Region，再到 ForwardHello Suppression 完成審查。

驗證寄件網域

先加入 ForwardHello 私人所有權 TXT。若該網域仍由 Resend 帳號持有，ForwardHello 會協調另一筆 Domain Claim TXT，完成後才顯示新的 SPF 與 DKIM Record。

建立正確權限的 Key

Sending Access Key 已足以處理單封與 Batch 寄送。只有舊程式也會讀取、重新排程或取消 Email 時，才使用 Workspace-wide Full Access Key。

讓 SDK 指向 ForwardHello

橋接期間保留 Resend Package，替換 API Key，並將 baseUrl 設成 ForwardHello 完整的公開 Origin；不要加入 Path 或尾端 API Prefix。

先在測試模式證明流程

寄信至 delivered@forward.test，確認 ForwardHello ID 與 Webhook Trail，再申請正式寄送權限；核准前不要切換客戶流量。

誠實的相容範圍

這是一座橋，不是假裝成另一個服務。

保留熟悉的 Email 方法，是為了降低切換風險。ForwardHello 不會假裝每一種 Resend 產品資源都能互相替換。

可直接沿用

from、to、cc、bcc 與 replyTo
subject、html、text 與由 SDK Render 的 React Email
安全 Header、Tag、排程與 Idempotency-Key
包含檔名與 Content Type 的 Base64 字串附件

需要重建一次

寄件網域驗證與 DNS Record
將 Resend Template 重建為 ForwardHello Template 與 Alias
使用全新 ForwardHello Signing Secret 的 Webhook Endpoint
將既有封鎖名單整理為已審查、只含 Email 的 CSV
安全 Sandbox 測試後的正式寄送權限

刻意不同的邊界

Resend Resource ID 不會移轉
Resend Suppression 依 Region 分開；ForwardHello 的 Suppression 安全範圍涵蓋整個 Workspace
不會讀取遠端附件 Path 或序列化的 Node Buffer
Resend topic_id 會被拒絕，不會默默略過同意檢查
Domain、API Key、Contact 與 Webhook 使用 ForwardHello API 或 Dashboard 管理

完成切換之後

用自己的步調，從熟悉介面走向完整原生能力。

當你想從同一個 Client 使用具型別的額度 Metadata、測試模式 Flag、API Request ID、Domain、Template、Webhook、Inbound Email、Audience、Broadcast 與其他 ForwardHello 能力時，再切換至 @forward-email/sdk。

認識 ForwardHello SDK

DNS 準備好，我們就準備好

第一封 ForwardHello Email，仍然可以很熟悉。

先完成結果固定的 Sandbox 寄送、保留一個穩定的 Idempotency Key，並等到新網域與 Event Trail 全部通過後，再移轉正式流量。

建立 Workspace 查看測試地址

Resend 是其權利人所有的商標。ForwardHello 是獨立服務，與 Resend 沒有關聯，也未獲得 Resend 背書。

保留熟悉的寄送呼叫，換一個更懂你的落點。