号码状态检测选型：空号与在网能力要不要分开买
采购评审上摆着两份需求，一份要号码状态检测，一份要可触达的在网名单，看上去该买两个接口。这篇按场景算清分开买多花的钱藏在哪三处、只买二元结果会缺什么、什么条件下分开才合理，以及签约前要问的四个问题。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
采购评审开到一半，两份需求并排摆在桌上：短信通道那边要空号检测，把明显无效的号码从触达名单里剔掉，免得短信费白花；外呼系统那边要一份可触达名单，把关机、欠费、没有短信能力的号码挑出来单独排期。采购同事的反应很自然——两家供应商、两个接口、各报各的预算。等到技术评审再往下问一层，问题冒出来了：这两份需求要的东西，本来就是同一份状态返回。
先看短信侧要什么。它要判断的其实是三件事：这个号码是不是空号，是不是已经不在网，值不值得发。
外呼侧要的多一层：正常在网的直接排进当天批次；关机、通话中、长时间关机的丢进「稍后再试」；欠费的先走提醒；无短信能力的只能走外呼，别的渠道都算浪费。
把这些诉求对齐到接口返回，会发现八种状态（正常、空号、通话中、不在网、关机、无短信能力、欠费、长时间关机）已经全部覆盖，再叠上携号转网识别，号码换了运营商也不会被误判成异常。一份返回，两边各取所需，区别只在动作分支怎么定。
第一处是重复调用。按次计费下，同一个号码被短信链路查一次、被外呼链路再查一次，就是两份钱。两个场景的名单重叠度通常很高，七八成重叠并不稀奇，等于每个号码平均付了一次半到两次。
第二处是口径打架。两条链路各自维护状态到动作的映射，缓存窗口、刷新时间、空号的定义都可能不一样。同一批号码在两个系统里跑出不同结论时，排查第一步是先把两边口径对齐，而这一步的耗时常常超过写映射本身。
第三处是运维翻倍。两套密钥托管、两套限流配额、两套错误码对照表、两页对账口径；外部服务抖动的时候，还得先判断是哪一家在抖。鉴权走请求头携带 AppCode 这类细节，供应商之间的写法各不相同，网关里得写两遍。
反过来算：预算有限，只买一个布尔式的空号检测，把号码压成「可发」与「不可发」，够不够用？
对纯短信场景，多数时候够。但外呼侧的排期会缺信息——关机与通话中被压进「可发」，打过去听到的是关机提示音；欠费的号码被当成正常在网，催了一遍没反应，反而多一次被投诉的风险。要补救只能再查一次完整状态，绕回原点。
还有一层隐性成本：运营看报表时问「为什么这批号码发不出去」，布尔结论给不出细分原因，只能重查或者人工抽样，这一来一回又是人力。
三种情形下分开买是合理的。旧接口还在生产跑着、合同没到期，替换链条上的回归成本高于省下来的调用量，可以等下一轮续签再合。需求本身就只有「发得出去发不出去」这一个二元判断，量也不大，不在意关机与欠费的区分。两条链路的等级要求差得远，比如前台交互只允许毫秒级的本地判断，外呼侧可以隔夜跑批，这时按链路分别采购反而省心。
除这三种之外，合并成一次调用通常更划算。
一次调用能不能同时拿到状态结果与携号转网识别，还是后者要额外计费、额外调用一次。状态是近实时值还是缓存值，缓存窗口多长——这决定了你要不要自己在网关再存一层快照。配额怎么给，QPS 上限多少，按次计费的计量单位是什么，失败请求与未覆盖号码算不算调用量，这四条直接影响预算模型。覆盖范围之外的那些号码由谁兜底：号段归虚拟运营商所有、卡是物联网卡、号码本身在境外，这几种情况下接口不会给出状态，评估表上要单列一行，别指望换一家供应商就能解决。
上线两周就能看出答案。盯三个数字：一次调用的成功率、重复调用比例、按天调用量曲线的斜率。重复调用比例高，多半说明两条链路还在各查各的；曲线斜率异常，先查名单来源，再查配额。
想把两边的诉求并成一次调用的，可以从【手机号在网状态 API】起步：直连移动、联通、电信三网，一次返回八种状态，支持携号转网识别，鉴权在请求头里携带 AppCode，按次计费、即买即用，字段定义与计量口径以商品详情页文档为准。自建、直连与号段库三条路的取舍，在号码状态检测接口选型：自建、直连与号段库里已经算过一遍；拿到状态之后每一种该怎么落到动作上，见号码状态检测结果怎么解读：八种状态对应动作；采购阶段还担心两家结果对不上，先看阿里云号码状态检测对比第三方：结果不一致怎么定基准。
文章评论
发表评论
请先注册/登录后评论