刪除 UnifyPort 訊息帳戶：分清 202 與 204

刪除 UnifyPort 訊息帳戶可能傳回 204 No Content 或 202 Accepted。配額模式刪除完成後傳回 204；錢包模式傳回 202，表示已受理，渠道清理及可能的退款仍以非同步方式繼續。收到 202 後，應保存 operation_id 並查詢計費操作。帳戶從目前列表消失，不等於清理或退款已完成。

重點

• 只有確定停用並移除訊息帳戶時才刪除，不要用它來暫停連線。
• 先按 HTTP 狀態分支，再解析 JSON：204 沒有回應內容。
• 202 的操作識別碼應獨立於帳戶列表保存。
• REVIEW 表示尚未確認，不是退款成功的證明。

先確認是否需要刪除帳戶

停止執行階段 API會停止連線程序，但不刪除帳戶。如果只需要暫停連線，應選擇這個操作。恢復保留的帳戶時，請使用執行階段復原手冊，不要把刪除當作重新啟動工具。

如果只有 CRM 或 AI 工作程序需要維護，也不一定要停止連線或刪除帳戶。Webhook 維護方案比較說明如何持續驗證及儲存事件，同時暫停下游處理。

本文處理的是 UnifyPort 帳戶資源，不是註銷用戶在 Telegram、WhatsApp 或 LINE 的原生身份，也不是清除 CRM 記錄或取消工作程序已領取的任務。

按刪除規格解讀回應

刪除帳戶 API 文件定義了 DELETE /v1/accounts/{account_id} 及兩種成功回應：

回應	文件所述含義	應用程式處理方式
204 No Content	配額模式刪除完成	不解析 JSON，保留診斷標頭
202 Accepted	錢包模式刪除已受理，清理及可能的退款非同步繼續	保存 data.operation_id，另外查詢操作
逾時或無法讀取回應	客戶端無法確定結果	保留不確定狀態，核對後再決定下一次修改

這符合 RFC 9110 的 DELETE 語義：接受請求與已執行刪除、無須再傳回內容，是不同的結果。不要一律顯示「已全部刪除並退款」。

帳戶列表規格指出：配額模式在刪除完成後移出列表，錢包模式則在刪除受理後就移出。因此，帳戶是否仍在列表中，不能用來判斷非同步操作是否完成。

移除介面資料列前，先保存結果

建議在應用程式記錄所選工作空間背景、account_id、渠道、操作人員確認及請求時間。這些是應用設計建議，並非新增 API 欄位。在自己的排程層停止為該帳戶建立新任務，並決定如何處理執行中的工作。應用層開關不能保證取消先前已提交的傳送請求。

以下 Node.js 範例只嘗試刪除一次。請傳入已核對的帳戶 ID 和伺服器端 API Key。程式沒有自動重試，也未實作持久化儲存。

export async function deleteMessagingAccount(accountId, apiKey) {
  const response = await fetch(
    `https://api.unifyport.ai/v1/accounts/${encodeURIComponent(accountId)}`,
    { method: 'DELETE', headers: { 'X-Api-Key': apiKey } }
  );
  const requestId = response.headers.get('X-Request-Id');

  if (response.status === 204) {
    return { httpStatus: 204, requestId };
  }

  const body = await response.json();
  if (response.status === 202 && body.data?.operation_id) {
    return { httpStatus: 202, requestId, operation: body.data };
  }
  throw new Error(`Deletion needs reconciliation; HTTP ${response.status}`);
}

httpStatus、requestId、operation 是應用程式自行定義的傳回名稱，不是新的 UnifyPort 回應欄位。先持久化保存結果，再移除介面上的帳戶資料列。呼叫端應捕捉網絡、解析與非預期回應錯誤，不能直接改成「刪除完成」。保留已遮蔽機密資料的錯誤詳情供排查。

追蹤操作，而非已消失的帳戶

收到 202 後，用保存的識別碼呼叫查詢帳戶計費操作：GET /v1/account-operations/{operation_id}，並使用同一工作空間的 API Key。

刪除受理範例包含 operation_id、kind: DELETE、state: PENDING 和 account_id。操作查詢文件亦列出 state: REVIEW、last_error_code: cleanup_unconfirmed。REVIEW 代表尚未確認，不能證明已退款。 介面應保留這個未確認狀態，而不是顯示成功。

獨立保存操作觀察記錄，避免帳戶從選單移除後連查詢入口也消失。為應用程式設定有界輪詢策略及升級處理規則；本文不承諾完成時間或退款金額。如果最初回應遺失，且沒有保存操作識別碼，請勿從 request_id 拼出操作 ID，也不要假設查列表就能找回。保留帳戶 ID、時間及診斷資料以供核對。

204 沒有回應內容，診斷識別碼位於 X-Request-Id 標頭。請求 ID 追蹤指南說明請求診斷與業務操作追蹤的分別。

驗收檢查與常見問題

啟用刪除按鈕前，測試 204 不會觸發 JSON 解析、202 的操作 ID 在重新整理頁面後仍存在，以及 REVIEW 一直顯示為未解決。逾時應留下調查記錄，不應自動重建帳戶或反覆刪除。

停止執行階段會刪除訊息帳戶嗎？

不會，該操作明確保留帳戶。帳戶生命週期文件亦把授權狀態與連線狀態分開。

202 是否表示刪除失敗？

不是。它表示錢包模式的非同步刪除已受理，但不代表所有相關步驟完成。

帳戶從列表消失，是否代表退款成功？

不是。錢包模式受理刪除後就會移出列表。應查詢計費操作，不要從列表狀態或 REVIEW 推斷財務結果。

下一步與參考資料

先按刪除帳戶文件實作兩種回應分支，再接上具破壞性的介面操作。應用資料及保留政策需另行處理；此 API 不是通用資料清除流程。

資料核對日期：2026-10-30。

• UnifyPort：刪除帳戶
• UnifyPort：查詢帳戶計費操作
• UnifyPort：帳戶列表
• UnifyPort：帳戶生命週期
• RFC Editor：RFC 9110 HTTP 語義