先说结论：关于 "API vs EDI warehouse integration" 这道题，答案不在技术里，在"谁说了算"里。零售商的供应商合规包写了 EDI，你就老老实实用 EDI；你自己的 WMS 和 ERP、和电商平台之间对接，你就用 API。这个坑我见过三次——每次客户都想"用现代的 API 替换掉老古董 EDI"，最后都被零售商的合规包教做人。
为什么这么说？因为对接零售商从来不是技术选型问题，是权力结构问题。零售商一天要处理几千家供应商的单据，不可能为你单独开一套接口。EDI 就是他们定的"普通话"：采购订单用 850 发给你，发货前你用 856 告诉他箱子里装了什么，货到了你用 810 开票。这套流程在北美叫 ANSI X12，在欧洲叫 EDIFACT，名字不一样，逻辑一样。
一张表看懂 API vs EDI：成本、周期、维护全对照
选之前先把这张表看完，这是我每次给客户做选型汇报的第一页：
| 维度 | EDI | API |
|---|---|---|
| 首年成本 | 中高：伙伴开通费 + 月租 + VAN 按量费 | 低：主要是开发人天 |
| 上线周期 | 4～12 周（含联调） | 几天～2 周 |
| 数据格式 | X12 / EDIFACT，零售商定死 | JSON / REST，双方可谈 |
| 实时性 | 批量（分钟～小时级） | 实时 |
| 谁定规则 | 零售商，合规包说了算 | 双方协商 |
| 维护负担 | 零售商改一次 spec，你改一次 map | 接口升级按版本号来 |
| 典型内容 | 850 采购订单、856 发货通知、810 发票 | 订单、库存、物流轨迹 |
| 纠纷证据 | VAN 邮箱有送达时间戳，打官司用得上 | 靠自己的日志 |
成本这栏细说一下。某 EDI 服务商的公开费率表长这样：单个零售商开通费约 600 美金起，基础月费约 149 美金起，VAN 按量约 0.16 美金/KB——具体以官网最新政策为准。看起来不贵，真正的成本在后面：每个零售商的报文 spec 都不一样，map 要一个一个做；零售商一升级版本（比如切到 X12 5010），你就得跟着改。
案例一：那家 3PL 的 856 翻车实录
2024 年秋天，洛杉矶一家 3PL 找到我。他们刚签下一个大零售商客户，EDI 的 850/810 都联调通过了，856 发货通知却连续被退回来。零售商的 EDI 台直接甩过来一封邮件：HL 层级结构错误，整票货按"未预约到货"处理。
根因查了三天才定位：他们的 WMS 里根本没有 carton 级装箱数据。pack 台只扫产品条码，不扫箱唛，856 里要填的"每个箱子装了什么、箱唛号是多少"全是编的。救回来的做法分三步：
- pack 台加一道扫箱唛动作：每个箱子打 GS1-128 箱唛，扫码绑定箱内明细；
- WMS 的 940 出库指令加 carton 维度，856 的 map 重做；
- 发测试 856 给零售商 EDI 台联调，连续三票全绿才敢切生产。
这个坑我见过三次，每次都栽在同一个地方：大家都觉得 EDI 难在"报文格式"，其实难在你的仓库作业根本产不出报文要的数据。856 是整套 EDI 里最难啃的一块——它要的是 carton 级的装箱真相，而很多仓库的 pack 流程还停留在"数个数"阶段。
案例二：API 对接，一周打通的另一面
同一年，另一家客户做 DTC 电商，对接某电商平台的开放 API 查库存、推订单。从拿到 key 到生产上线，5 个工作日。实时、JSON、文档清晰，开发体验好到让人想哭。
但别急着下结论"API 完胜"。半年后这家客户想进一家线下连锁零售商，供应商合规包第一页就写着：EDI 850/856/810，走 SPS Commerce 或同等服务商。API 再先进，零售商不认，等于零。这就是 trade-off：API 赢在效率，EDI 赢在"入场券"。
反常识：API vs EDI 之争，EDI 凭什么是硬通货
很多人觉得 EDI 是上世纪的老古董，早该被 API 取代了。我做了 30 多个上线项目，结论恰恰相反：EDI 在零售圈的生命力，来自它解决了 API 解决不了的三个问题。
第一，证据链。VAN 是个带邮箱的私有网络，你发的每份报文都有送达时间戳，独立于对方系统有没有读。chargeback 纠纷里，这句"我们按时发了"和"证明你按时发了"，差的可能就是几万美金。API 的日志是你自己的，VAN 的时间戳是第三方的。
第二，标准化暴力。850 就是采购订单，856 就是发货通知，810 就是发票，全行业一个意思。API 再标准，每个平台的字段名、分页、限流都不一样。零售商要管几千家供应商，它赌不起"每家 API 都不一样"的运维成本。
第三，合规即门槛。做不到 EDI 合规，你连给大零售商供货的资格都没有。SPS Commerce 一家就连着 4500 多家采购方、上百万条连接——这不是技术选择，这是生态现实。
所以我的反常识判断是：未来十年，零售对接依然是 EDI 的天下；API 会吃掉你内部系统之间、和电商平台之间的对接，但吃不掉零售商的供应商合规包。
上线前夜 checklist：五步定选型
别再纠结技术优劣了，按这五步走，30 分钟出结论：
- 翻合规包：写了 EDI 就没得选，直接定 EDI 方案。没写 EDI 再谈 API。
- 查数据家底：你的 WMS 能不能产出 carton 级装箱数据？不能的话，EDI 项目的第一步不是买服务，是改 pack 流程。
- 算三年 TCO：开通费 × 零售商数量 ＋ 月租 × 36 ＋ VAN 按量费 ＋ 每次 spec 变更的 map 维护费。别只看第一年。
- 盘团队：有没有懂 X12 的人？没有就买托管型 EDI 服务，别自己搭。
- 定混合架构：对外（零售商）走 EDI，对内（WMS/ERP/电商平台）走 API。两套并存，各干各的活。
常见翻车点：这三条我每年都要讲
- 只买了 EDI 服务，没人盯 997 回执。997 是"我收到了"的确认函，没收到 997 就等于报文石沉大海。必须做监控，997 缺失超过 2 小时就报警。
- 856 的层级结构抄了别家零售商的模板。每家零售商的 HL 层级、必填段都不一样，抄模板等于抄作业抄错卷子。
- 以为上线就完事。零售商升级报文版本（比如切到 5010）经常只提前 60 天通知，map 来不及改，旺季直接断流。每年 Q4 前把各零售商的 spec 变更通知翻一遍。
一句话收尾：选 EDI 还是 API，先问"对方认什么"，再问"我有什么"，最后问"我付得起什么"。顺序错了，项目必翻。
作者：林晓｜WMS 实施顾问
