消息发错后：编辑、撤回还是仅本地隐藏？

通过已连接账号发错消息后，先确定要改变什么：编辑替换已发送的文本，撤回请求从会话所有参与者处收回消息，本地隐藏只改变自己应用的显示。UnifyPort 文档支持 WhatsApp 文本编辑，以及 Telegram、WhatsApp、LINE 消息撤回。两种动作都只针对账号自己发送的消息；能接收编辑或删除 webhook，不代表可以执行对应动作。

核心要点

• 修改文字用编辑，收回自己发出的消息用撤回，仅调整工作台显示用应用自身的控制。
• 账号、会话、消息必须作为一个目标保存；确认后不要重新选择“最新一条”。
• 主动操作能力与事件接收能力要分别核对。
• API 返回、webhook 观察结果、下游副本清理是三类不同证据。

编辑、撤回与本地隐藏的区别

假设客服把预约时间发错了。更正消息正文，与让它从客服界面消失，并不是同一个需求。

目标	应使用的控制	不能据此证明
更正已发文字	编辑消息	收件人从未看过原文
收回本账号发出的消息	撤回消息	所有保存或转发的副本已消失
隐藏自己收件箱的一行	应用自身的显示控制	客户聊天中的消息发生了变化
响应已观察到的撤回	处理 message.deleted	已发起新的撤回请求

WhatsApp 的官方删除说明提醒：收件人可能在删除前已看到消息，iOS 用户保存到照片中的媒体也可能保留。因此，不要把按钮命名为“彻底擦除”，也不要把撤回当作敏感内容从未暴露的保证。

这里的本地隐藏是应用设计，不是文档中存在的 UnifyPort 单条消息本地删除端点。conversation.deleted 和 conversation.cleared 描述本地会话变化，也不等于为所有人撤回一条消息。

看动作矩阵，不要只看事件矩阵

当前渠道动作矩阵列出的映射如下：

渠道	编辑已发文本	撤回本人消息
whatsapp	支持	支持
telegram	不支持	支持
line	不支持	支持
twitter、zalo、tiktok、whatsapp-protocol	不支持	不支持

这是适配器能力映射，并不保证每次请求都满足上游条件或账号限制。未实现的组合返回 501 unsupported_by_provider。

例如，LINE 编辑事件处理文章解决的是接收和归并 message.updated，并没有开放 LINE 主动编辑。不要因为接收器识别此事件，就显示可用的“编辑”按钮。

UnifyPort 的撤回契约也比某些原生群管理功能更窄：只允许撤回已连接账号自己发送的消息。即使操作人员是群管理员，也不要据此提供撤回其他成员消息的功能。

提交纠错前，固定被选中的消息

从已保存的 message.received 观察中取出 account_id、data.conversation.id 和 data.message.id。该事件既可能是入站消息，也可能是出站消息；执行前检查 data.message.direction 并核对归属。顶层事件 id 不是消息 ID。

建议在应用中加入以下检查：

1. 验证操作人员有权使用所选消息账号及会话。
2. 在确认窗口中固定消息身份，显示当前内容与动作范围。
3. 核对渠道能力及消息是否由本账号发送；编辑只允许文本消息。
4. 对同一目标串行处理纠错，避免两位客服互相覆盖决定。
5. 将动作记录及结果与可见消息正文分开保存。

以下是使用虚构标识符的 JSON 请求体示例，不是实际客户流量。通过服务端使用 X-Api-Key 发送，不能把密钥放入浏览器代码。

POST /v1/messages/edit 中的 content 是完整替换文本，不是局部补丁：

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C",
  "content": "更正：预约时间为 15:00。"
}

POST /v1/messages/revoke 使用同一个明确目标，不需要替换内容：

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C"
}

撤回文档说明 sender_id 默认是账号自身，通常可省略。填入其他发送者不会扩大权限。不要自行设定跨渠道统一的纠错期限，也不要把另一套 API 的权限套进来。

请求结果与副本清理分开处理

两份端点文档的成功示例均含 data.ok: true。记录实际结果，但不要将它解释为所有收件人及下游系统均已清除旧内容。

观察结果	建议处理
501 unsupported_by_provider	禁用该渠道动作，不重复原请求
edit_message_failed 或 revoke_message_failed	检查错误及目标上下文，再决定下一步
HTTP 超时或响应丢失	保持结果不确定，调查后再考虑重试
收到匹配的 message.updated 或 message.deleted	对明确作用域内的消息幂等归并
没有匹配事件	不仅凭缺失就判断成功或失败

按请求追踪指南保存返回的 request_id，用于排查，而不是幂等令牌或保证可关联 webhook 的键。

接收事件时遵循投递契约：配置 signing_secret，对时间戳与原始请求体验证 HMAC-SHA256，检查时效，持久化后再确认。事件顺序没有保证。自有搜索、CRM、AI 副本仍需独立清理；撤回内容清理指南说明了这一应用边界。

常见问题

编辑端点能替换附件吗？

文档只支持文本消息。不要将 content 当作媒体替换字段。

收件箱隐藏后，客户就看不到了吗？

不是。本地可见性和渠道侧撤回是不同操作，界面必须写明范围。

支持 message.deleted，就代表每次撤回都有回调吗？

不是。事件映射不保证每个上游账号或部署都会产生全部事件。分别保留 HTTP 结果与事件观察状态。

下一步与来源

先阅读撤回消息参考，在获授权的测试会话中检查选择与确认流程。UnifyPort 是非官方接口，不替代原生平台规则，也不保证擦除外部副本。

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

• UnifyPort：编辑消息
• UnifyPort：撤回消息
• UnifyPort：渠道动作支持
• WhatsApp：如何删除消息