适用场景与接口能力边界运营商三要素核验API主要用于校验用户提交的「姓名 手机号 身份证号」三组信息是否真实一致。典型场景包括账户实名准备在用户准备环节快速比对身份信息降低虚假准备风险。风控准入在贷款、保险等金融业务中验证用户身份真实性。身份一致性校验在修改敏感信息或找回密码时确认操作者为本人。能力边界本接口仅返回核验结论一致/不一致/异常不返回明文个人信息所有敏感字段手机号、身份证号在响应中自动脱敏。QPS 上限为 5 次/秒超出会返回限流错误。接口需在取得信息主体明确授权后才可调用且按次计费。请求参数与鉴权方式请求方法及地址请求方法POST请求地址https://v1.apizero.cn/api/carrier-3c鉴权 Header接口使用 Bearer Token 鉴权推荐在请求头中传递Authorization或X-API-Key两者任选其一官方 curl 示例使用X-API-Key。Authorization: Bearer 你的 API Key // 或 X-API-Key: 你的 API Key请求体格式请求体为 JSON 对象包含三个必填字段字段名类型必填说明别名namestring是真实姓名中文长度不超过 30 字符realname, xmmobilestring是11 位手机号需满足中国大陆手机号格式phone, sjidcardstring是18 位身份证号末位可以是 X 或 x需符合身份证校验规则id_card, sf注意接口同时兼容别名例如可以用realname代替name用phone代替mobile。但同一请求中不要混用别名与主名否则可能解析冲突。完整 curl 请求示例以下示例直接使用真实的接口地址请务必将$APIZERO_API_KEY替换为你自己的有效 Keycurl -sS \ -X POST \ -H X-API-Key: $APIZERO_API_KEY \ -H Content-Type: application/json \ -d {name:张三,mobile:13800138000,idcard:110101199001011234} \ https://v1.apizero.cn/api/carrier-3c若使用 Authorization 头等价写法为curl -sS \ -X POST \ -H Authorization: Bearer $APIZERO_API_KEY \ -H Content-Type: application/json \ -d {name:张三,mobile:13800138000,idcard:110101199001011234} \ https://v1.apizero.cn/api/carrier-3c响应字段解读成功响应HTTP 200的 JSON 结构如下{ code: 0, msg: 成功, request_id: abc123, data: { match: true, result: 三要素一致, name: 张三, mobile: 138****0000, idcard: 110***********001X } }核心字段说明code: 业务状态码。0表示调用成功非0表示异常需根据msg排错详见下文错误列表。msg: 对code的中文描述。request_id: 请求唯一标识可用于在服务端日志中追踪问题。data.match: 布尔值true代表三要素一致false代表不一致。仅当code 0时有效。data.result: 核验结论的文本描述如“三要素一致”“三要素不一致”“信息无法判定”。data.name / mobile / idcard: 输入参数的回显已脱敏用于客户端核对传入值是否与预期一致。常见错误与排错策略1. 认证失败401 Unauthorized现象HTTP 401返回{code: 1001, msg: 认证失败}或类似提示。可能原因API Key 无效或已过期。请求头写错了参数名如拼写为X-API-KEY注意大小写。使用了错误的认证方式如误传Bearer但 Key 不带前缀。排查步骤检查 API Key 是否拷贝完整是否包含空格或换行。确认在控制台生成 Key 后已经启用且未超出有效期。使用 curl -v 查看实际发出的请求头curl -v -X POST -H X-API-Key: your_key ... 21 | grep \确认请求头格式正确。2. 请求体字段校验失败400 Bad Request现象HTTP 400返回{code: 1002, msg: 参数错误: xxx}。常见错误字段错误信息示例原因解析参数错误: name不能为空未传递name字段或值为空字符串。参数错误: 手机号格式不正确mobile不是合法的 11 位数字开头非 1或包含非数字字符。参数错误: 身份证号格式不正确idcard位数不对、末位校验码错误、包含非法字符。参数错误: 请求体不是合法JSON提交的 body 不是合法的 JSON 格式如缺少引号、末尾多逗号。参数错误: 字段名冲突: name与realname同时出现同时使用了主字段和别名字段导致接口无法确定使用哪个值。排查步骤用在线 JSON 校验工具验证请求体格式。确认mobile字段仅包含 11 位数字前两位为 13/14/15/17/18/19 等常见号段即可接口不做严格号段判定。检查idcard是否满足 18 位最后一个字符若为 X 必须大写。确保只传递一组字段名不要同时使用name和realname。3. 三要素核验结果异常code0 but matchfalse现象HTTP 200code0但data.match为falsedata.result为“三要素不一致”。原因用户提交的姓名、手机号、身份证号三者中至少有一项与运营商记录不匹配。排查方向确认手机号是否已实名且与身份证号绑定的姓名一致。对于携号转网或物联网卡等特殊情况运营商可能无法返回准确结果此时result可能为“信息无法判定”。检测用户在输入时是否有空格或全半角问题如中文空格、全角数字。处理建议在前端提示用户核对输入信息尤其是姓名中的生僻字部分运营商库可能不包含生僻字。若出现“无法判定”可建议用户更换其他验证方式如银行卡四要素。4. 请求频率超限429 Too Many Requests现象HTTP 429返回{code: 1003, msg: 请求过于频繁}。原因单个 API Key 在 1 秒内发起了超过 5 次请求。解决方案在客户端实现请求队列或限流确保每秒不超过 5 次。对于批量核验场景可采用固定间隔如 200ms逐条发送。若确实需要更高 QPS联系服务方申请提额。示例限流代码片段Python 伪代码import time import requests def call_api(name, mobile, idcard, api_key, max_retries3): time.sleep(0.2) # 至少间隔 200ms保证 1s 内不超过 5 次 headers {X-API-Key: api_key, Content-Type: application/json} payload {name: name, mobile: mobile, idcard: idcard} for attempt in range(max_retries): resp requests.post(https://v1.apizero.cn/api/carrier-3c, jsonpayload, headersheaders) if resp.status_code 429: wait (attempt 1) * 0.5 time.sleep(wait) continue return resp.json() return {code: -1, msg: 限流重试失败}5. 网络超时与连接错误现象curl 报告Connection timed out或Operation timed outHTTP 状态码为空。可能原因客户端与 API 服务器之间的网络链路不稳定。使用了代理但未正确配置。服务器端临时过载返回 503 Service Unavailable 时也是类似表现。排查步骤使用ping v1.apizero.cn或curl -m 5 https://v1.apizero.cn/api/carrier-3c测试连通性。在 curl 中使用--connect-timeout 10 --max-time 30参数增加超时常量。如果频繁超时可考虑在客户端实现指数退避重试策略。6. 返回非预期的 code 值除了常见的 1001、1002、1003 外还可能返回其他业务码codemsg 含义处理方式1004身份证号与姓名不匹配提示用户信息有误1005手机号未实名建议用户先完成手机实名1006运营商系统异常稍后重试若持续报错联系技术支持1007余额不足按次计费充值后继续调用2000服务器内部错误联系接口提供方当遇到非code0且不在此表内的值先查看msg字段获取详细描述必要时记录request_id提供给技术支持。工程化注意事项1. 数据合规与授权调用前必须获得信息主体的明确授权并在《隐私政策》或《用户协议》中告知数据用途。不要缓存明文结果到本地数据库仅保留脱敏后的结论。2. 安全密钥管理不要将 API Key 硬编码到客户端代码或 GitHub 仓库中。在服务端使用环境变量或密钥管理服务如 AWS Secrets Manager存储。定期轮换 API Key。3. 重试与幂等由于网络波动或服务器偶发错误建议对部分错误如 503、429、timeout实现重试机制。接口本身不是幂等的每次请求按次计费因此重试应限定次数如 2-3 次并记录日志以便对账。4. 日志与监控记录每次请求的request_id、HTTP 状态码、code和耗时。对非code0的响应设置告警阈值及时发现异常模式。监控 QPS 使用情况避免在接近上限时因突发流量被限流。参考文档接口文档页https://apizero.cn/aidocs/carrier-3c原始 Markdown 文档https://apizero.cn/aidocs/carrier-3c/raw.md