霸王餐是外卖CPS赛道里佣金最高的玩法（35%-61%），但真正把API对接跑通的团队不多——签名总验不过、订单拉不齐、佣金对不上账，是三个最常见的卡点。这篇以云瞻开放平台CPS业务OpenAPI开发文档为准，把饿了么霸王餐API的对接全流程拆成可落地的五步，从授权申请到订单回传一次讲清。

一、对接前置：先确认你有资格接

动手写代码前，先把两件事核清楚：

① 资质与权限门槛

饿了么官方对霸王餐权限有明确准入规则：个人账号，或近7日饿了么CPS日均订单≥500单的企业账号可申请；清退后需30日才能再次申请。个人开发者直接对接官方门槛高，主流路径是通过云瞻开放平台这类已合规接入饿了么霸王餐业务的聚合平台间接对接——云瞻负责与饿了么的技术对接和合规保障，你不需要直接接触饿了么底层API。

② 准备工作清单

企业或个体户营业执照（个人主体无法做佣金结算）、微信认证小程序+微信支付商户号（用于用户佣金提现）、云瞻开放平台账号开通与实名认证。

二、五步走实操流程

第一步：授权申请，拿到身份凭证

所有接口调用的第一步，是在云瞻平台申请 app_key 和 app_secret——这是调用接口的凭据和身份唯一标识。

后续所有请求都走统一域名：https://openapi.，公共参数固定三个：app_key、sign、timestamp。

动作清单：注册云瞻账号→完成实名认证→提交API使用申请→审核通过后获取app_key/app_secret→在密钥管理里集中存放（严禁硬编码）。

第二步：签名规则，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（上游技术服务费）——算实际到手收益时要把它从佣金里扣掉，很多团队对账差额就出在这里。

第五步：订单回传与对账闭环

① 主动拉取+被动接收双保险

生产环境用Push+Pull双重保障机制：主动轮询定时调订单查询接口拉取增量，同时配置回调地址接收上游主动推送的订单状态变更，保证数据的实时性和完整性。

② 结算单列表接口

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

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

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

霸王餐活动有明显的生命周期，活动上下架要实时感知，靠轮询效率太低。云瞻提供设置CPS业务上下架回调通知地址接口（/subscribe/call...），订阅后活动状态变更实时推送，前端可即时上下线活动入口。

④ 回调幂等与去重

上游为保证通知可达会多次重推，必须用"平台ID+订单号+子订单号+状态"做组合键去重，否则佣金重复入账就是资金级事故。

三、两个高频故障排查

故障一：签名不一致

排查顺序：参数是否都参与了排序→数组/嵌套对象是否做了JSON序列化→中文和斜杠是否正确转义→app_secret是否首尾各加一次→MD5输出是否32位小写。90%的签名失败都是转义问题，用官方参考代码跑一遍基准样本能快速定位。

故障二：订单撞单/漏单

撞单：检查去重键是否用了order_no+order_child_no组合；漏单：检查增量拉单是否用了queryType=2、拉单时间窗口是否有重叠覆盖、回调地址是否正确注册。兜底方案：每日凌晨全量跑一次前24小时订单做对账补漏。

四、三条合规红线

· 不碰刷单与机刷：自注册多账号下单、虚拟收货地址、群控脚本批量下单，触发饿了么风控直接封号，已结算佣金可能被追回；

· 不碰爬虫：抓包破解或调用饿了么未公开API属于违规行为，涉及《数据安全法》甚至刑法第285条；爬虫抓取型三方接口丢单率高且随时面临法律风险，只认官方授权渠道；

· 不篡改归因参数：替换跳转链接中的渠道参数、返佣参数导致佣金归属错误，平台识别后冻结资金并追究违约责任。

写在最后

饿了么霸王餐API的对接难点不在接口本身，而在三处细节——签名规则的转义、状态机的理解、对账闭环的搭建。五步走下来，前两步决定能不能跑通，后三步决定能跑多久。

接口对接只是起点，把霸王餐的高佣优势和日常外卖的复购管道串联起来，配合锁粉机制和社群SOP，本地生活CPS的收益结构才算真正搭起来。