刪除 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 推斷財務結果。

下一步與參考資料

先依刪除帳號文件實作兩種回應分支，再接上具破壞性的介面操作。應用資料與保留政策需另外處理；這不是通用資料抹除流程。

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

• UnifyPort：刪除帳號
• UnifyPort：查詢帳號計費操作
• UnifyPort：帳號清單
• UnifyPort：帳號生命週期
• RFC Editor：RFC 9110 HTTP 語義