首页/产品线/飞陆统一网关
接入层 · 一套 API

飞陆统一网关

三类运力,一套接口。客户不必对接三个系统、维护三份合同、做三本对账;下单、计费、状态回传三件事在网关这一层统一掉。

1 个下单入口
1 套计费口径
8 字段最小订单契约
3 类运力自动分流

它解决什么

多运力协同最难的不是运力本身,是接口、口径与责任在三方之间对不齐。

没有网关时,客户要分别对接空运、陆运、客运三套系统:字段不一样、状态定义不一样、计费口径不一样,出问题还要三方扯皮。网关把这些差异吸收在这一层,对客户只暴露一套稳定的接口。

分流规则也在网关:重量与业务类型双判据,20 公斤以下走 飞陆空运、以上走 飞陆陆运、乘车需求走 飞陆智载。客户不需要知道背后是哪条线,也不需要自己判断。

核心能力

01统一下单入口

一次提单,填重量、起点、终点即可,地址自动转坐标,运力由系统判定。

交付形态:下单接口 + 小程序入口

02自动分流

按重量与业务类型双判据分流,规则透明可查,派单环节零人工介入。

交付形态:分流规则配置

03统一计费口径

三类运力共用同一套计费与对账流程,客户只收一份账单。

交付形态:计费规则 + 月度对账

04统一状态回传

各运力的节点状态映射为同一套事件口径,客户系统一次订阅即可。

交付形态:状态事件流 + 回调

058 字段最小订单契约

用尽量少的必填字段完成下单,避免对接方为内部字段反复改造。

交付形态:接口文档 + 联调支持

06可独立部署

网关与调度可作为独立系统交付到客户侧部署,数据不出客户环境。

交付形态:部署包 + 运维文档

最小订单契约

下单只需要 8 个字段。以下为字段示意,实际联调以接口文档为准。

字段含义
order_id客户侧订单号,用于幂等与对账
weight_kg货物重量(公斤),决定空运或陆运
from_addr起点地址,自动转坐标
to_addr终点地址,自动转坐标
biz_type业务类型:货运 / 载人
expect_time期望送达或上车时间
contact收件人或乘客联系方式
callback_url状态回传地址

调用形态

示意,非最终接口定义;实际以联调时提供的接口文档为准。

# 下单:一次调用,运力由网关判定 POST /v1/orders { "order_id": "C20261113001", "weight_kg": "12.5", "from_addr": "合肥市高新区天达路71号", "to_addr": "合肥市高新区望江西路某园区B栋", "biz_type": "freight", "expect_time": "2026-11-13T18:00:00+08:00", "contact": "181****3829", "callback_url":"https://your-domain/callback" } # 返回:判定结果与运力归属 { "order_id": "C20261113001", "carrier": "air", // air | ground | ride "eta": "2026-11-13T17:26:00+08:00", "status": "accepted" }

接入一次,怎么走完

四步,把技术对接和业务跑通分开处理。

1 · 需求对齐

确认运力组合、业务类型、计费口径与回传要求,出一份对接方案。

2 · 沙箱联调

在测试环境完成下单、分流、状态回传闭环,处理异常与幂等场景。

3 · 试运行

小批量真实单量运行,校验计费与对账,确认时效承诺可达成。

4 · 正式接入

切换到生产环境,纳入监控与月度对账,按需调整分流规则。

接入后你能拿到什么

一份账单

三类运力合并计费,不用分别对账。

一套状态

不同运力的状态统一口径,系统只解析一次。

一个对接方

技术问题只有一个联系窗口,不用三方协调。

可解释的分流

每一单为什么走空运或陆运,规则可查可复核。

// 下一步

要接口文档,或先聊聊对接

说明你的系统形态(小程序 / ERP / 自建平台)与日均单量,我们给一版对接方案。