UnifyPortのメッセージングアカウント削除：202と204の処理

UnifyPortのメッセージングアカウントを削除すると、204 No Content または 202 Accepted が返ります。クォータ方式では削除完了時に204、ウォレット方式では受付時に202が返り、プロバイダー側のクリーンアップと、該当する場合の返金は非同期で続きます。202では operation_id を保存し、課金操作を照会してください。一覧からアカウントが消えても、クリーンアップや返金の完了は証明できません。

要点

• 削除はアカウントを廃止するときに選び、一時的な接続停止には使わない。
• JSONを解析する前にHTTPステータスで分岐する。204には本文がない。
• 202の操作IDは、アカウント一覧とは別に保存する。
• REVIEW は未確認を意味し、返金成功を示すものではない。

本当にアカウントを削除する必要があるか

ランタイム停止APIは、アカウントを削除せず接続プロセスを停止します。目的が一時的な接続制御なら、こちらを選びます。保持したアカウントを再びオンラインにする際は、削除を再起動の代わりにせず、ランタイム復旧手順を使ってください。

LINEの受信を続けながらCRMやAIワーカーだけを保守したい場合、アカウント削除も接続停止も不要かもしれません。Webhook保守方法の比較では、署名検証と永続保存を継続し、下流処理だけを止める構成を説明しています。

この記事の対象はUnifyPortのアカウントリソースです。LINE、Telegram、WhatsAppのネイティブアカウント自体の退会、CRMデータの消去、ワーカーが取得済みのジョブのキャンセルを説明するものではありません。

削除契約に沿ってレスポンスを読む

アカウント削除リファレンスは DELETE /v1/accounts/{account_id} と、次の成功レスポンスを定義しています。

レスポンス	文書化された意味	アプリケーションの処理
204 No Content	クォータ方式の削除が完了	JSONを解析せず、診断用ヘッダーを保存
202 Accepted	ウォレット方式の削除を受付。クリーンアップと該当する返金は非同期で継続	data.operation_id を保存し、操作を別途照会
タイムアウトや読めないレスポンス	クライアントでは結果を確定できない	不確実な状態を保持し、次の変更前に照合

これは RFC 9110のDELETEの意味とも一致します。受付と、削除を実行済みで追加の本文がない状態は別です。両方を一律に「すべて削除・返金済み」と表示してはいけません。

アカウント一覧の契約では、クォータ方式は削除完了後、ウォレット方式は削除受付後に一覧から消えるとされています。したがって、一覧への表示は非同期処理の完了監視には使えません。

画面の行を消す前に結果を保存する

アプリケーション側では、選択したワークスペースのコンテキスト、account_id、プロバイダー、操作者の確認、リクエスト時刻を保存することを推奨します。これは設計上の推奨事項であり、新しいAPIフィールドではありません。自社のスケジューラーで対象アカウントへの新規ジョブを止め、実行中の処理をどう扱うか決めます。この制御だけで、すでに送信済みのAPIリクエストを取り消せるわけではありません。

次のNode.js例は削除を一度だけ試行します。確認済みのアカウントIDとサーバー側のAPIキーを渡してください。自動再試行や永続ストレージの実装は含みません。

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を受け取ったら、保存したIDでアカウント課金操作の照会を行います。エンドポイントは GET /v1/account-operations/{operation_id} で、同じワークスペースのAPIキーを使用します。

削除受付の文書例には operation_id、kind: DELETE、state: PENDING、account_id が含まれます。操作照会には state: REVIEW と last_error_code: cleanup_unconfirmed の例もあります。REVIEWは未確認であり、返金を証明しません。 UIでも未確認のまま表示します。

操作の観測記録を独立して保持し、アカウントが選択肢から消えても追跡リンクを失わないようにします。アプリケーションでポーリングの上限とエスカレーション条件を決めてください。この記事は完了期限や返金額を保証しません。最初のレスポンスが失われて操作IDが残っていない場合、request_id からIDを作ったり、一覧の再取得で復元できると仮定したりしないでください。アカウントID、時刻、診断情報を残して照合します。

本文のない204では、診断IDは X-Request-Id ヘッダーにあります。リクエスト追跡と業務操作追跡の違いは、リクエストIDの診断ガイドを参照してください。

受け入れ確認とFAQ

削除ボタンを有効にする前に、204でJSON解析が走らないこと、202の操作IDがページ再読み込み後も残ること、REVIEWが未解決として表示されることを確認します。タイムアウト時には調査記録を残し、アカウントの自動再作成や削除の連打を行わないようにします。

ランタイムを止めるとアカウントも削除されますか？

いいえ。停止操作はアカウントを保持します。アカウントライフサイクルでも認証と接続状態は別に扱われています。

202は削除失敗ですか？

いいえ。ウォレット方式の非同期削除が受理されたことを示しますが、関連する全工程の完了を示すものではありません。

一覧から消えたら返金済みですか？

いいえ。ウォレット方式では受付時に一覧から消えます。課金操作を照会し、一覧表示やREVIEWだけから金銭的な結果を推測しないでください。

次のステップと出典

削除リファレンスに沿って両方のレスポンスを処理してから、破壊的なUI操作に接続してください。アプリケーションのデータや保存方針は別に管理します。このAPIは汎用のデータ消去手順ではありません。

確認日：2026-10-30。

• UnifyPort：アカウント削除
• UnifyPort：アカウント課金操作の照会
• UnifyPort：アカウント一覧
• UnifyPort：アカウントライフサイクル
• RFC Editor：RFC 9110 HTTP Semantics