← 所有文章
对比选型

WhatsApp 静音还是屏蔽?共享收件箱的操作选择

只想减少 WhatsApp 通知干扰,应选择会话静音;希望阻止某个人向账号发消息,才考虑屏蔽联系人。两者都不能代替系统内部的“暂停自动回复”或“工单已解决”。共享收件箱应把这些决定分开,避免为了安静而切断客户联系,或者以为静音后 AI 就不会继续回复。

三种控制,三种目的

WhatsApp 通知指南将静音作为聊天通知设置。屏蔽指南说明,被屏蔽的联系人无法再给你打电话或发送消息;解除屏蔽后,也不会收到对方在屏蔽期间发送的消息。因此,屏蔽不是可以稍后恢复消费的消息缓冲区。

目的应选控制不能据此推断
减少聊天通知干扰会话静音工单已解决,或 webhook 收件已关闭
阻止特定联系人联系经授权确认后屏蔽联系人历史内容已删除,或解除后会补回消息
暂停 AI 自动回复应用自己维护的自动化暂停状态平台静音或屏蔽会取消本地队列任务
保留后续跟进事项本地工单状态,必要时辅以未读标记未读等于静音

后两项是应用设计建议,不是新增的 WhatsApp API 功能。已读相关边界可参阅WhatsApp 已读与未读同步指南。通知偏好、阅读回执和团队任务分配解决的是不同问题。

UnifyPort 实际提供哪些操作

UnifyPort 的非官方接口把会话操作和联系人操作分开。下表描述的是 UnifyPort 契约,不是 Meta Cloud API 路由。

操作输入及文档边界参考
静音conversation_id,加秒数 duration 或未来的 RFC3339 时间 mute_until;两者不能同时传静音会话
取消静音conversation_id取消会话静音
屏蔽或解除屏蔽contact_id,必须是 digits@lid 形式的 WhatsApp 规范 LID屏蔽联系人与解除屏蔽
查看屏蔽列表返回 data.blocklist 和列表指纹 data.dhash获取黑名单

静音参数 duration: 0 表示永久静音,不是关闭静音。恢复通知应调用明确的取消静音操作。

展示按钮前,先查看平台操作支持矩阵。当前文档将屏蔽、解除屏蔽和黑名单读取映射到 WhatsApp;静音支持 WhatsApp,LINE 为部分支持,取消静音也映射到 LINE。统一路由不意味着所有平台行为一致;不支持的组合返回 501 unsupported_by_provider。

不要自行拼造屏蔽标识

WhatsApp 屏蔽和解除屏蔽操作不接受手机号或 @s.whatsapp.net JID 来替代规范 LID。应通过文档中的联系人流程取得实际标识,不能给手机号拼上 @lid 就认为指向同一个人。

联系人响应可能包含不同的 id、provider_user_id 和 conversation_id,保存时应保留各自含义。联系人 API 与 vCard 指南也解释了修改通讯录与发送联系人资料为何属于不同操作。本文并不是要求你为了屏蔽某人先把对方添加为联系人。

先设计收件箱决策,再调用接口

假设客服队列不断收到重复消息:如果仍需要审核这些内容,静音可以处理通知干扰,本地暂停状态可以阻止不合适的 AI 回复。如果有权限的审核人员决定屏蔽联系人,应把它作为另一项明确操作。

建议采用以下应用流程:

  1. 清楚命名。 分开显示“静音通知”“屏蔽联系人”和“暂停自动回复”,并限定所选消息账号及目标。
  2. 确认身份。 屏蔽必须使用与该账号对应、已核实的规范 LID。身份不确定时停止并交给人工,而不是猜测。
  3. 本地记录意图。 保存操作人、原因、目标和请求的操作。这些是应用审计记录,不是应额外塞进 API 的字段。
  4. 检查结果。 文档中的变更响应包含 data.ok。不能仅因点击按钮就显示成功;保留脱敏错误与 request_id 便于排查。
  5. 核对不确定结果。 屏蔽或解除屏蔽请求超时后,先读取黑名单再考虑下一次变更。按一致规则比较标识;dhash 能提示列表变化,但不能说明是谁、为何修改。
  6. 单独处理排队中的自动化。 决策前创建的任务可能仍在数据库里。发送前让工作进程检查本地暂停策略,不能把平台设置当作自己的队列取消机制。

对于静音变更,事件参考记录了 conversation.updated 以及 muted、mute_until 等设置。收到事件时可作为状态观察,但不要保证每次操作都有对应确认。公开事件目录未记录联系人屏蔽事件,应使用已文档化的黑名单查询,而不是自行假设事件存在。

验收检查与限制

使用自己控制的账号测试:界面应区分变更失败与已生效;取消静音不能调用解除屏蔽;解除屏蔽不能自动放行旧回复任务。还应测试标识被拒绝和超时后结果不明的情况。这些是建议测试,不是已完成的测试结果。

不要用静音控制 webhook 流量。静音接口改变会话状态,文档没有说它会关闭事件投递。同样,本文不承诺屏蔽会删除已保存内容、管理共同群组,或取消 CRM 中的任务,这些都应单独定义。

如果原生应用内的人工操作已经足够,直接使用原生控制即可。如果需要官方商业集成,应独立评估其契约,不要把这些 UnifyPort 路由当成 WhatsApp 官方接口。

常见问题

静音聊天会停止自动回复吗?

不能这样假设。应由回复工作进程检查明确的本地暂停状态;静音没有被文档定义为取消任务的操作。

可以使用手机号 JID 屏蔽联系人吗?

UnifyPort 的 WhatsApp 屏蔽操作不可以。必须使用规范 digits@lid,而非手机号或 @s.whatsapp.net 值。

解除屏蔽后会补收屏蔽期间的消息吗?

不会。WhatsApp 官方帮助明确说明不会补收,因此不要把屏蔽设计成可恢复的消息缓冲区。

dhash 变化能证明我的操作成功吗?

不能单独证明。它是整个黑名单的指纹,应检查目标联系人是否存在,并单独保留操作结果。

下一步与参考资料

先阅读屏蔽联系人参考,确认标识映射后,再在共享收件箱启用按钮。

核对日期:2026-09-25。

UnifyPort API

让消息接入变成一条稳定的产品管线。

先用统一 API 跑通发送,再用标准事件把所有入站消息接回业务系统。