IP分省批量处理接口和infobip发送报告信息接收接口，本质上是一对“上游识别”与“下游确认”的配合关系：前者在消息发送前判断用户IP归属地，后者在消息发送后接收通道回执，两者打通才能让短信运营实现精准分省调度和送达率闭环。
很多做短信业务的团队都卡在这两个接口的对接细节上，尤其是infobip这种国际通道和国内IP库的字段差异，稍不注意就会导致数据错位，这篇文章直接讲清楚两个接口各自怎么用、怎么联调,以及实际操作中容易踩的坑。
IP分省批量处理接口怎么对接才算合格
这个接口的核心价值就一句话：把一批IP地址批量解析出对应的省份，供业务系统做地域判断，它通常用在短信发送前的风控环节，比如判断用户是否在常用省份登录,或者按省份分流到不同的短信通道。
接口协议和调用方式
行业里通用的做法是走HTTP POST请求，数据格式用JSON,一个标准的请求体包含三个字段：
ip_list：IP地址数组，单次建议不超过500个，超过会被服务端拒绝request_id：调用方生成的唯一标识，用于排查问题timestamp：毫秒级时间戳，配合签名使用
响应体里最关键的是province字段，返回的是“广东”“北京”这种标准省份名，少数接口返回的是省份编码（如GD）,对接时要做映射表。
鉴权机制和签名规则
绝大部分IP分省接口采用AppKey + Sign的方式鉴权，签名算法一般是MD5或HMAC-SHA256，把请求参数按字典序拼接后加盐哈希,具体步骤：
- 将请求参数（除
sign外）按key的字母序排序 - 拼接成
key1=value1&key2=value2格式 - 末尾拼接
&key=你的AppSecret - 对整个字符串做MD5，得到32位小写签名
签名串拼接顺序错误是新手最常犯的错，差一个字符就返回401，建议先在本地写个脚本验证签名逻辑,再上线。
批量解析的性能表现
单个IP解析耗时大约在5-15毫秒，批量500个IP的接口整体耗时在1-2秒之间，如果业务对延迟敏感，比如登录风控场景，建议把IP批量解析放到异步队列里,不要阻塞主流程。
行业里也有本地化的IP库方案，比如把纯真IP库加载到内存，单次查询耗时能压到1毫秒以内，但本地库的更新频率通常不如在线接口，
IP归属地数据每周都有变化,纯本地方案会导致一部分IP解析结果过时。
infobip回执接口对接的核心逻辑
infobip发送报告信息接收接口，本质是一个Webhook回调，infobip的短信发出后，运营商会返回投递状态,infobip把这些状态推送到你配置的回调地址上。
回调地址配置和参数说明
在infobip后台的Routes菜单里新建一条Route，设置Channel为SMS，Destination填你的回调URL，infobip支持同时配置多个回调地址，但生产环境建议只配一个主地址,避免重复处理。
回调消息的JSON结构包含几个关键字段：
messageId：infobip的消息唯一ID，和发送接口返回的bulkId对应to：接收方手机号，格式是447912312312这种国际格式status.groupId：状态分组，3表示投递成功，4表示投递失败status.name：具体状态名，如DELIVERED、UNDELIVERED、REJECTEDprice：本条消息的计费金额，单位是EUR
回执状态码对照表
infobip的状态码体系和国内通道差异很大，对接时一定要建映射表,以下是最常见的几组对照：
| infobip状态名 | groupId | 含义 | 国内通道对应 |
|---|---|---|---|
| DELIVERED | 3 | 用户收到 | DELIVRD |
| UNDELIVERED | 4 | 运营商投递失败 | UNDELIV |
| REJECTED | 4 | 被运营商拒绝 | REJECTD |
| EXPIRED | 4 | 消息过期 | EXPIRED |
| ABSENT | 4 | 用户不在服务区 | 无对应 |
特别注意ABSENT状态，国内通道没有这个枚举，很多团队对接时直接忽略，导致这部分消息被算成“丢失”而不是“失败”,影响后续重发策略的判断。
回执去重和幂等处理
infobip的Webhook有一定概率重复推送，尤其是网络抖动时,处理逻辑必须做幂等：
- 以
messageId为唯一键，落到Redis或数据库唯一索引 - 相同
messageId的重复回调直接忽略 - 先查重再更新状态，顺序反了会导致状态被旧回执覆盖
实际业务中，infobip的回执延迟波动很大，慢的可能在发出后2小时才收到，超时未收到回执的消息，需要主动调用infobip的查询接口补拉状态,不能干等回调。
两个接口配合的业务场景实例
把IP分省接口和infobip回执接口放在一起用，最常见的是跨境短信的风控调度场景。
以一个出海电商平台的验证码短信为例,完整链路是这样的：
- 用户发起登录请求，带上当前IP
- 系统调用IP分省批量处理接口，判断用户IP属于哪个国家/地区
- 根据IP归属地选择对应的infobip发送通道（比如欧洲用户走德国通道,东南亚用户走新加坡通道）
- 短信发出后，infobip回调接口接收投递状态
- 如果回执状态是失败，系统结合IP归属地判断是否要切换备用通道重发
这个链路里，IP分省接口解决的是“从哪儿发”的问题，infobip回执接口解决的是“发得怎么样”的问题。两者缺一个，调度策略就是盲跑。
接口联调和问题排查的实操步骤
联调阶段最容易出问题的三个点：IP分省接口的签名校验不过、infobip回调收不到、回执状态解析错位。
用curl模拟IP分省接口调用
curl -X POST https://api.example.com/ip/province/batch
-H "Content-Type: application/json"
-d '{"ip_list":["8.8.8.8","1.1.1.1"],"request_id":"test001","timestamp":1700000000000,"sign":"your_md5_sign"}'
先用官方文档给的测试IP跑通，再换真实IP。公网IP和内网IP的处理逻辑不同，部分接口会把内网IP归为“未知”，测试时不要用168.x.x。
用ngrok调试infobip回调
infobip要求回调地址必须是公网可访问的HTTPS地址，本地联调时可以先用ngrok暴露一个临时域名,配置到infobip后台的Route里。
ngrok http 8080
然后在本地启动一个简单的HTTP服务，打印收到的POST body，确认infobip的推送格式。注意infobip的回调请求头里有Authorization字段，需要校验签名,不要只验body。
回执状态延迟的排查路径
如果发现infobip回执迟迟不来,按以下顺序排查：
- 检查infobip后台的Route是否激活，
Status是否为ACTIVE - 确认回调地址返回的HTTP状态码是
200，返回其他状态码infobip会一直重试 - 查看infobip后台的
Logs页面，看推送记录里是否有SENT但无DELIVERED - 排除手机号本身的问题，比如
to字段填了国际格式但缺了国家码
关于接口收费模式的业内共识
IP分省批量处理接口的计费方式各家不同，但主流是按次调用计费，价格在5元到2元/千次之间，量大可以谈阶梯价，也有按QPS包月的模式,适合日均调用量稳定在百万级以上的团队。
infobip的接口本身不收对接费，但短信发送按条计费，各通道价格差异大。回执接口不额外收费，但回调推送数量会计入API调用量,部分套餐有速率限制。
选择IP分省接口供应商时，建议拿同一批真实IP样本让几家服务商做对比测试，重点看三点：各省份识别准确率、响应耗时、签名文档是否清晰，据行业内专家经验，价格最低的供应商不一定整体性价比最高,解析准确率差距在实际业务中会被放大。
常见问题速查
IP分省接口返回的省份和用户实际位置不一致怎么办
IP归属地本来就做不到100%准确，运营商级IP还好，公司专线IP和移动基站IP的误差率较高，如果业务对抗风险要求高，可以叠加基站定位或GPS定位做交叉验证。不要只依赖IP归属地做一刀切决策。
infobip回执里的price字段怎么和账单对账
price字段是单条消息的计费金额，货币单位EUR，精确到小数点后4位，对账时按bulkId聚合，把每条消息的price累加，和infobip月度账单对比。注意账单里的税费和附加费不计入price字段,对不上是正常的。
回调地址更换后旧地址还能收到回执吗
不能，infobip的路由配置是即时生效的，旧地址在配置更改后不会再收到新回执，但已发送消息的延迟回执仍有小概率推到旧地址，建议在旧地址上保留一段时间的日志,避免漏数据。
IP分省批量处理接口管好“发前”，infobip回执接口管好“发后”，把这两个环节的数据拉通，短信业务的省份分析、通道调度、送达率监控才算真正闭环。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/557130.html
