删除 UnifyPort 消息账号：正确处理 202 与 204

删除 UnifyPort 消息账号可能返回 204 No Content 或 202 Accepted。额度模式删除完成后返回 204；钱包模式返回 202，表示已受理，渠道清理及可能的退款仍异步进行。收到 202 后，应保存 operation_id 并查询计费操作。账号从当前列表消失，并不能证明清理或退款已经完成。

要点

• 只有确定不再使用该消息账号时才删除；临时停止连接应选择其他控制。
• 先按 HTTP 状态分支，再解析 JSON：204 没有响应正文。
• 202 返回的操作标识应独立于账号列表保存。
• REVIEW 表示结果尚未确认，不代表退款成功。

先确认要删除的是哪个资源

停止运行时接口停止连接进程，但不删除消息账号。如果只是临时停止连接，应选择这个边界。需要恢复保留的账号时，使用运行时恢复手册，不要把删除当成重启工具。

如果只是 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 响应字段。先持久化结果，再移除账号界面行。调用方应捕获网络异常、JSON 解析失败和非预期响应，不能静默转为“删除完成”；应保留脱敏后的错误信息以便排查。

跟踪操作，而不是已经消失的账号

收到 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 响应头。请求追踪与业务操作跟踪的区别，见 UnifyPort 请求 ID 排查指南。

验收检查与常见问题

启用删除按钮前，测试 204 不触发 JSON 解析、202 的操作 ID 在刷新页面后仍存在、REVIEW 始终显示为未解决。超时应留下调查记录，而不是自动重建账号或反复删除。

停止运行时会删除消息账号吗？

不会。停止运行时明确保留账号。账号生命周期文档也区分授权状态与连接状态。

202 表示删除失败吗？

不是。它表示钱包模式的异步删除已经受理，但不证明所有关联步骤完成。

账号从列表消失，是否意味着退款成功？

不是。钱包模式受理删除后就会移出列表。应查询计费操作，不能从列表状态或 REVIEW 推断资金结果。

下一步与参考资料

先按照删除账号接口实现两种响应分支，再连接具有破坏性的界面操作。应用数据及保留策略需单独处理；该 API 不是通用的数据擦除流程。

资料核对日期：2026-10-30。

• UnifyPort：删除账号
• UnifyPort：查询账号计费操作
• UnifyPort：账号列表
• UnifyPort：账号生命周期
• RFC Editor：RFC 9110 HTTP 语义