WA Lookup
一个手机号验证流程以确认结果结束的抽象示意图
同步请求让工作流在下一步决策前获得当前信号。

在真正需要决策的时刻使用当前信号

线索资格判断常被视为后续的名单清洗步骤。它当然有价值，但注册信号并不只在那个时刻有用。表单提交、客服请求或 CRM 更新，都可能在下一条规则执行前需要一个答案。

WA Lookup 通过同步 API 提供这个答案。调用方既可以提交一个手机号，也可以一次提交最多 100 个号码的小批量请求，并在同一个 HTTP 响应中收到所选的 WhatsApp 结果。因此，当工作流需要立即补全记录、选择处理队列或请求更多信息时，可以直接使用该响应。

这个结果的范围很明确：它只报告所选产品在检测时返回的已文档化字段。它不识别号码背后的人、不证明联系同意、不显示在线状态或消息历史，也不保证未来一定可触达。

选择刚好能回答问题的信号

WA Lookup 的请求形状一致，由 service_type 决定返回字段。

Service type 可使用的结果 工作流示例
ws registered 保存当前注册信号后，再继续线索路由规则。
ws_avatar registered、avatar、avatar_url 在 CRM 审查流程中补充已文档化的资料可用性字段。
ws_business registered、business 当该区分有用时，将记录送入 B2B 审查路径。

请选择能回答当前问题的最低成本产品。头像或 Business 字段只是补充上下文，不会让注册判断更具权威性。

发起清晰请求并遵守响应契约

调用前应规范号码。E.164 让国际号码具备明确的国家区号格式，避免把含糊的本地号码误当成完整的全球号码。

curl -X POST "https://walookup.com/api/v1/check" \
  -H "X-API-Key: sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"service_type":"ws","identifier":"+14155552671"}'

完成的注册检测会使用公开响应结构返回：

{
  "code": 0,
  "msg": "ok",
  "data": {
    "service_type": "ws",
    "identifier": "+14155552671",
    "registered": true
  }
}

只有在检测完成后才使用 data.registered。无效请求、余额不足、并发拒绝、超时或无法判定都不是“号码未注册”的证据。应将这些运行状态与注册观测分开保存，并按文档执行纠正或重试。

保存观测，而不是身份结论

一条有用的 CRM 记录应保留提交内容、检测内容和观测时间。这样，后续刷新可以被解释，而不是悄悄覆盖旧值。

  • 分别保存来源原始值与规范后的 E.164 号码。
  • 将选用的 service_type 与返回字段一起保存。
  • 将检测时间与完成结果一起记录。
  • 将请求错误和无法判定与 registered=false 明确区分。
  • 只有后续工作流需要新观测时，才重新检测。

账户可在网页或 API 中使用；请以当前价格页和 API 文档为准。

一条简单的路由原则

安全的原则很简单：只对完成的响应分支处理，并把字段视为当前工作流输入，而不是永久事实。例如，CRM 可以连同检测时间和 service type 保存 registered=true；而临时失败应保持为可重试状态，不能覆盖已有的完成观测。

同步验证最适合的地方正是这里：它在工作流真正需要做决策的时刻，提供一个结构化答案。

参考来源