如何实时检测手机号是否注册 Telegram

产品只回答一个明确问题

TG Validator 检测提交的手机号在本次请求时是否注册 Telegram。

产品接收一个 E.164 手机号，使用 service_type=tg，并在同一个 HTTP 响应中返回完成结果。应用读取 data.registered 前，不需要轮询任务 ID，也不需要等待回调。

产品范围到注册状态为止。响应不会提供 Telegram 用户名、个人资料、活跃状态、联系人、群组或消息数据，也不会识别控制该手机号的人。这些不是被隐藏的功能，而是完全不属于产品契约。

完成的 false 与检测失败不同

返回数据	注册判断	使用方式
status=success、registered=true	检测时已注册	把 true 作为本次请求结果
status=success、registered=false	检测时未注册	把 false 作为本次请求结果
status=undetermined、registered=null	没有注册判断	不生成布尔值，本次不保留扣费

这个区别很重要，因为 registered=false 是完成检测产生的可用信息。API 错误通过外层响应返回独立的 HTTP 状态与数字 code，它不是 data.status 或 data.registered 的另一种取值。

同步请求路径

1. 准备 E.164 输入 — 从明确的国家信息开始，把号码规范为加号、国家区号和数字。
2. 鉴权请求 — 在 Settings 创建 API Key，并通过文档指定的请求头发送。
3. 选择 Telegram 产品 — 设置 service_type=tg，不要从无关字段猜测产品。
4. 等待当前响应 — 检测同步执行，应用无需轮询即可收到判断。
5. 读取准确结果字段 — data.status 为 success 时使用 data.registered；返回 undetermined 时保持为空。
6. 记录检测时间 — 把结果作为当前观测，而不是无限期保证。

实时性适合哪些场景

当软件继续执行前需要一个当前注册判断时，同步契约很合适。操作人员可以在后台检测一条记录，内部应用可以验证刚提交的号码，后端 worker 也可以逐条处理数据。

处理更大列表时，客户端仍然是一号一请求，并负责调度、速率控制、并发与进度记录。这样底层 API 契约保持简单：每个完成请求只有一个输入、一个 Telegram 注册结果和一个观测时间。

最小应用记录

使用明确字段，不要只写一个含糊的 valid：

字段	用途
source_phone	保留来源系统提交的内容
e164_phone	保存实际被检测的规范号码
service_type	记录 tg 这一结果契约
status	原样保留返回的 success 或 undetermined 结果状态
registered	仅为完成检测保存 true/false
checked_at	为注册观测增加时间戳

应用需要更新答案时，应再次发起同步调用，而不是修改旧值的时间戳，也不能声称缓存值是实时结果。

避免错误数据的接入原则

data.status=success 确认 registered 布尔值就是本次完成的注册答案。

这种两阶段解读可以让输入问题和临时服务状态远离 Telegram 注册字段，也让产品承诺保持准确：检测完成时，TG Validator 同步提供一次当前注册观测；何时需要新观测，由接入系统决定。