承运商集成

接口打通到哪一层,决定你少赔多少钱

只有询价接口的系统,下单靠人工转录、追踪靠登门户、账单靠对着 PDF 抄。我们把询价、下单、追踪、文档、Webhook 与 EDI 一路打通到底。

100+
美国卡车公司
全美
覆盖范围
API + EDI
双通道对接

各通道的集成能力

// 按集成类型的能力覆盖

全国性 3PL / Broker API

询价(含 Volume 大货)
在线下单,回写承运商单号
全程状态追踪
BOL / POD 自动回传(个别渠道仍需人工从门户获取)
Webhook 实时推送(含签名校验)

EDI 承运商

204 下单报文
214 状态报文
990 应答报文
在线询价
单据回传

小包裹 / 仓配 API

多服务等级比价
在线下单出单
面单直出
轨迹追踪
地址校验与住宅判定

同城 / 本地配送 API

即时下单派送
当日 / 次日达时段
与主干运输同一套订单流

每一项都按承运商逐家落地。 各家 API 的成熟度差异很大 —— 有的推送实时状态,有的只开放文档下载,有的走 EDI 报文。我们按每家的实际能力做适配,把可自动化的部分全部自动化,剩下的用流程兜住,不让它掉到人工转录上。
为什么这里不列承运商名字: 你要接的是你自己的承运商合同,不是我们的。真正决定成败的是上面这几层做到多深,而不是我们和谁签了约。具体已对接清单、以及能否接入你现有的账号与费率,在洽谈时提供。
账最后怎么归到同一张订单上,见 财务对账 →

为什么这几层缺一不可

每一层缺失都对应一类真实损失

询价:报错一次,赔一路

密度、NMFC、可堆叠、linear feet、住宅判定 —— 任一项传错,承运商都会按实际重算并发 rebill。系统在提交前把这些校验掉,比事后申诉便宜得多。

下单:人工转录是事故源头

把报价转成订单如果靠人手抄,地址、时间窗、附加费迟早抄错。API 下单直接带回承运商单号,双方账本从一开始就对得上。

追踪:客服成本的大头

定时轮询 + webhook 推送双路,状态回写到订单时间轴。没有这层,每个"我的货到哪了"都得有人去登承运商门户。

文档与 EDI:对账的前提

BOL 与 POD 自动回传归档;EDI 通道走 204/214/990,下单、状态与确认都是报文级往来,不依赖邮件附件。

你有授权,我们就能接

接入与定制是一条独立的服务线,不必连运力一起买

你自己的承运商与供应商

你已签约、已拿到接口授权的任何一方 —— 承运商、报关行、仓库、保险方 —— 我们按它的实际接口做适配接进来,用你的账号与你谈下来的费率。系统里现有的几条主干通道,本来就是这样一条条长出来的。

开放 API:接进你现有的系统

询价、下单、追踪都可以由你的程序直接调用,用独立签发的 API key 鉴权。权限按模块授权 —— 只开你要用的那几个,key 随时可吊销。ERP、WMS、电商后台接进来即可,不用让人再去后台点一遍。

白标:客户看到的是你

你自己的域名与品牌,单据抬头、收款账户与联系方式都是你的。客户从下单到收发票,全程看不到我们。

按你的流程定制

定价规则、审核闸、报表口径、单据版式、财务对接(如 QuickBooks 双向同步)都可以按你的做法改,而不是让你迁就系统预设的流程。

我们只接你已获授权的接口。 账号与合约始终在你名下,我们不代持、不转售、也不绕开对方的接口条款。你随时可以撤销授权,接入即停。

接进来之后长这样

// 一票货在系统里的样子:来源、承运商、PRO、单据、时效、异常

想接哪一家,先说来听听

已接的直接开通,没接的我们评估工作量再报排期。

或者,直接问
微信扫码聊
企业微信客服二维码
不用留资料,先问一句也行