做外卖CPS的人都知道，霸王餐是社群裂变的爆单抓手——高佣、零门槛参与感强、天然适合做免费福利拉新。但很多团队卡在对接环节：签名总验不过、订单拉不齐、佣金对不上账。这篇文章以云瞻开放平台CPS业务OpenAPI开发文档为准，把饿了么霸王餐的API对接全流程拆成可落地的操作步骤，从申请到对账闭环一次讲清。

一、对接前置：拿到身份凭证

所有接口调用的第一步，是在云瞻平台申请 app_key 和 app_secret——这是调用接口的凭据和身份的唯一标识。后续所有请求都走统一域名：https://openapi.yunzhanxinxi.com，公共参数固定三个：app_key、sign、timestamp 。

二、签名机制：90%对接失败卡在这里

云瞻的签名规则文档写得很明确，实操时逐字执行：

1. 所有请求参数按key的ASCII升序排序，拼成 key=value 格式，用&符号连接；

2. 生成的字符串前后各加一次app_secret；

3. 最后做MD5加密，输出32位小写字符串作为sign。

文档给的示例很直观：请求参数含 app_key=123456、telephone、goods_id=2、timestamp=1630291270，排序拼接后为 888888app_key=123456&goods_id=2&telephone=13800138000×tamp=1630291270888888，MD5后得到32位小写签名。

两个易错点：一是数组类参数（如嵌套的biz对象）要先做JSON序列化再参与排序，PHP环境下记得加 JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES，否则中文和斜杠转义会导致签名不一致；二是文档提供了Java和PHP两版签名参考代码，直接复用比自己写稳。

三、第一步实操：拉业务ID全集，定位霸王餐

对接订单接口前，先调用 获取订单业务类型接口（/api/business/platform-list），拿到支持API的全部业务platform列表。这个接口的价值在于：业务ID是动态全集，以接口返回为准，而不是硬编码。

在返回列表里你能看到外卖赛道的完整版图：饿了么（platform=3）、饿了么（阿里本地生活）（platform=44）、霸王餐（饿了么官方）（platform=137），同时还有霸王餐（美团官方）=92、霸王餐（三方）=128等相邻业务。做饿了么霸王餐，对应的就是platform 137，后续查询订单时按这个业务类型过滤。

四、订单接口实操：参数与状态机

核心接口是获取订单列表（/api/api-list/order_list），POST请求、urlencoded格式，关键参数：

· startTime / endTime：秒级时间戳，拉单时间区间；

· queryType：查询时间类型，1创建时间、2更新时间、3结算时间、4支付时间——这里有个实操技巧：增量拉单用queryType=2（更新时间），订单状态变更才能及时同步，漏单率远低于只按创建时间拉；

· type 固定传0，platform 传对应业务ID；

· settle_task_id：传入结算单ID后，时间区间查询会失效，用于按结算单精确对账。

返回数据里重点盯三个字段：

· order_status状态机：1订单失效、2订单付款、3订单结算——只有状态3的钱才是真正落袋的；

· estimate_amount与settle_amount：预估佣金和结算佣金是两个数，预估是钩子、结算是真金，财务核算必须以后者为准；

· order_no + order_child_no：文档明确这两个字段组合做唯一判断，你的去重逻辑必须用组合键，单一order_no会撞子订单。

另一个容易忽略的字段是 tech_service_fee（上游技术服务费）——算实际到手收益时要把它从佣金里扣掉，很多团队对账差额就出在这里。

五、结算闭环：结算单列表接口

订单结算后，通过获取结算单列表（/api/api-list/order-settle-list）按入账时间区间查询，返回字段包括 settle_num（结算单号）、task_id（结算任务ID，可直接回填到订单列表的settle_task_id做精确查询）、entry_time（入账时间）、statistics_date（收益月份）。

标准对账流程：拉结算单 → 拿task_id → 回查该结算单下所有订单 → 核对settle_amount合计与提现流水，一分钱都能追到出处。

六、回调订阅：业务上下架通知

霸王餐活动有明显的生命周期，活动上下架要实时感知，靠轮询效率太低。云瞻提供设置CPS业务上下架回调通知地址接口（/subscribe/callback），传 type=cps 和你的 url 即完成订阅。

回调机制有两个关键点：你的接口返回"success"才算通知成功，否则平台会重试回调3次——所以回调处理务必幂等，避免同一通知被重复消费；通知内容包含 business_id 和 status（1上架、2下架），收到上架通知就是社群推活动的最佳时机。

七、避坑清单：频率限制与状态码

· 频率限制：标准版每小时最多10000次、每天240000次，QPS限制20；不够用可升级，每小时单次/0.3元，QPS每档200元、最高40QPS，更高需单独定制。拉单程序务必做分页节流，别把配额烧在无效轮询上；

· 状态码速查：90000102功能未购买或已到期（联系客服）、90000100未开放接口、90000001参数错误、90000500系统错误——把code映射写进统一异常处理，报错不再靠猜。

写在最后

饿了么霸王餐API对接的完整路径，其实就是五步：申请凭证 → 按规则签名 → 拉业务ID定位137 → 按更新时间增量拉单+组合键去重 → 结算单对账+回调订阅。文档里的每个字段设计都有它的用意：queryType的四类时间是给你做增量同步的，order_no+order_child_no是给你做幂等的，结算单task_id是给你做精确对账的。

把这些细节吃透，霸王餐这条爆单管道才能跑得稳、对得平、赚得明白。