WhatsApp 入群审批：通过 API 开启或关闭

通过 UnifyPort 开启或关闭 WhatsApp 入群审批，调用 POST /v1/accounts/{account_id}/groups/join-approval-mode，提交 group_id 和必填布尔值 enabled。true 表示要求审批，false 表示关闭这项要求。这是在修改群设置，不是对待处理申请执行“全部批准”或“全部拒绝”。

要点

• 把开关作为明确的管理操作，不要在打开审批列表时顺便修改。
• 必须发送 JSON 布尔值，不能使用字符串 "false"、遗漏的复选框值或自行设计的切换动作。
• 当前操作支持 whatsapp，不适用于独立的 whatsapp-protocol 或其他渠道。
• 分开记录期望设置、API 返回结果和后续核验。

先区分群设置与审批动作

Meta 的 WhatsApp 群管理官方说明介绍了管理员在分享邀请链接或允许社区成员加入群组时控制入群资格的能力。平台设置与审核申请人的软件是两个层次。

操作意图	对应操作
新加入者需要审批	设置 enabled: true
关闭入群审批要求	设置 enabled: false
批准或拒绝指定申请人	使用独立的入群申请更新操作
获取邀请网址	使用邀请链接读取操作

逐人审核请参考 WhatsApp 入群申请审批队列；分发邀请请参考邀请链接读取与重置的区别。这两个流程都不应暗中改变群组的准入规则。

设计明确的开启与关闭表单

审批模式接口文档要求提交 group_id 和布尔值 enabled。渠道动作矩阵将该操作限定为 WhatsApp。UnifyPort 使用已连接消息账号的非官方接口；这里不是 WhatsApp Cloud API 请求。

同时选择账号与群组，通过列出群组获取群 ID，不要只按群名称确定目标。确认已连接的身份有群管理员权限，并在自己的应用中验证操作人员是否有权改变准入规则。持有工作空间 API Key 不等于拥有群管理员权限。

建议表单遵循以下规则：

1. 在确认页面展示所选账号与群组。
2. 要求明确选择开启或关闭审批。
3. 当前设置未知时显示“未知”，不能把缺失信息显示成“关闭”。
4. 仅在操作人员确认后提交，不在页面加载或列表刷新时写入。
5. 校验和序列化时保留 false；简单的真值判断可能把关闭操作丢掉。

公开群组读取示例没有定义审批模式字段。不要自行构造响应属性填充表单。没有文档支持的回读能力时，请授权管理员在 WhatsApp 内查看设置，并把应用保存的值标为“上次请求的设置”，而非当前状态。

提交一次经过确认的修改

下面是使用真实请求字段的服务端 JavaScript 示例，未在此执行，也没有自动重试：

export async function setJoinApproval({ apiKey, accountId, groupId, enabled }) {
  if (!apiKey || !accountId || !groupId || typeof enabled !== 'boolean') {
    throw new Error('Account, group, credential and boolean choice required');
  }

  const response = await fetch(
    `https://api.unifyport.ai/v1/accounts/${encodeURIComponent(accountId)}/groups/join-approval-mode`,
    {
      method: 'POST',
      headers: { 'X-Api-Key': apiKey, 'Content-Type': 'application/json' },
      body: JSON.stringify({ group_id: groupId, enabled })
    }
  );
  const requestId = response.headers.get('X-Request-Id');
  const body = await response.json();
  return { httpStatus: response.status, requestId, body };
}

API Key 必须留在后端。返回对象中的 httpStatus、requestId 和 body 是应用自己的变量名，不是新增 API 字段。文档中的成功响应为 200 OK，包含 data.ok: true。先保存目标布尔值与结果，再显示成功。调用方必须处理网络和 JSON 解析异常；没有收到响应时应保持“结果未确认”，不能显示为“已关闭”。

在应用内按账号与群组串行处理修改。如果先有人要求开启，随后另一人要求关闭，旧请求的延迟重试可能恢复过时的选择。本地锁或版本检查是应用防护，不是上游提供的条件写入功能；管理员仍可在原生应用中独立修改。

分别核验准入设置与待处理申请

待处理列表为空不能证明审批已关闭，也可能只是无人等待。group.join_request 是申请信号，不是设置修改的回执。公开事件契约没有承诺专门确认审批模式的回调。

开启后，请授权管理员检查设置，并在广泛分发链接前进行受控邀请测试。审批流程继续轮询列出入群申请；该文档明确说明推送信号是尽力交付。

关闭前先检查未处理申请，并明确之后由谁核对。审批模式契约没有说明关闭对存量申请的影响。不要声称关闭会批准所有人、拒绝所有人、移除现有成员或重置邀请链接。针对具体申请人的决定应使用独立审批操作。

请求超时后，保留目标值与诊断记录，检查原生设置，再要求重新确认是否提交。不要自动发送相反值当作回滚：其他管理员可能已经改变了规则。

常见问题

能否省略 enabled，表示保持不变？

不能。该操作要求布尔值。不需要修改时就不要调用。

enabled=false 会拒绝所有等待者吗？

文档没有这样承诺。关闭设置与处理存量申请是两项任务。

审批任务能否每次轮询时都开启审批？

不建议。轮询是读取，准入配置是管理写入。分开处理才能避免后台任务撤销管理员的主动选择。

Telegram 或 LINE 能使用这个操作吗？

当前 UnifyPort 动作矩阵未支持。相同的路由形状不代表所有渠道都具备该能力。

下一步与参考资料

依据设置入群审批模式实现表单。建议测试两种布尔值、字符串输入拒绝、初始状态未知、相反选择并发提交及响应丢失。这些是建议的验收项，不是已执行的测试结果。

资料核对日期：2026-11-02。

• Meta：WhatsApp 群管理功能说明
• UnifyPort：设置入群审批模式
• UnifyPort：渠道动作支持
• UnifyPort：列出入群申请