结论先行：90% 的成长型品牌和卖家，对接 3PL 仓库该先走 API，不是 EDI。 这就是典型的"EDI 还是 API"选型问题。这事分两面——EDI 是给大零售商合规交作业的，API 是给你自己干活提效的。你的订单还没到撑起 EDI 固定成本的量级，就先交 EDI 的税，纯属自己给自己加戏。
这不是我拍脑袋的结论。行业数据摆在那儿：EDI 上线通常要 4 到 12 周，光报文映射、联调和合规测试就得 2 到 8 周；而 API 的沙箱密钥通常当天就能拿到，对接顺利的话几周内就能跑通。时间差是按月计的，钱差呢？云 EDI 的公开报价区间，一年通常在几千到两三万美元，VAN 按报文收费一笔几美分到几毛钱，按月包也要几百到几千美元一个月，外加每个新合作伙伴几百到两千美元的开通费。API 的账就简单多了：3PL 的 API 接口多数是随服务给的，调用按量计费或者直接包含在仓储服务里。
说白了，选 EDI 还是 API 不是技术问题，是算账问题。你的单量是多少，决定你该用哪种对接方式。
我见过的一个坑：订单还没影，先交了三年 EDI 税
2019 年，洛杉矶一家做家居小件的 DTC 品牌，老板意气风发，一年计划做到 800 万美元营收，找我做仓库选址咨询。他们选了 3PL，3PL 顺手推荐了合作的 EDI 服务商，理由是"一步到位，以后进大零售商不用再折腾"。
听着很对吧？结果呢：EDI 上线花了整整 11 周，映射开发、报文联调、合规测试，一样没少。第一年 VAN 账单加映射维护，一共花了小 3 万美元。问题是，他们那年实际只发了不到 3 万单，月均 EDI 成本摊到每单超过 1 美元——而他们当时每单的仓储操作费才几美元。更扎心的是，所谓"以后进大零售商"三年都没发生，那套 850/856 的报文能力一次都没用上，全用来传 940（出库指令）和 945（出库回执），而这两件事用 API 传更快、更便宜、还实时。
我见过太多这样的了：小卖家一上来就搞 EDI，等于给还没影的订单提前交税。 税交了，货还没影。
反过来说，走 API 的都是什么下场？我 2023 年在安大略（Ontario, CA）看过一个做宠物用品的卖家，年单量 40 万单。他们对接 3PL 只用了一套 REST API 加 webhook：940 订单指令照样批量下，库存查询走实时 API，包裹轨迹事件走 webhook 推送。从拿到沙箱密钥到黑五前跑通，一共 4 周，几乎零额外成本。黑五那周单日 6,000 单，靠实时库存 API，他们自己的 Shopify 店和亚马逊店都没超卖——要是走 EDI 的 846 库存快照（定时批量发），那 6,000 单里至少得有一部分是"卖了没货"的乌龙。
EDI 还是 API？先把两笔成本账拆开看
把账拆开看，你就知道为什么规模决定选型。
EDI 的钱花在三处： 一是开通费，每个合作伙伴几百到两千美元（公开报价常见区间）；二是 VAN 费用，按报文、按流量或按合作伙伴收，月包几百到几千美元；三是映射和维护费，每次对方改报文规范，你都得重新映射、重新测试——这笔钱是持续的，不是交一次就完事。特点是：固定成本高，边际成本低。单量越大，摊到每单越便宜。
API 的钱花在一处： 开发对接的人力。3PL 的 API 文档现在都做得不错，标准接口（下单、查库存、查轨迹、对账）都有现成的。特点是：前期投入低，灵活。单量小的时候几乎不心疼；单量大了，调用量费用才慢慢起来。
所以这笔账的 trade-off 很清楚：EDI 是"先交固定成本、再享受规模红利"，API 是"先低成本跑起来、量大了再考虑升级"。哪个对你划算，全看你的单量在哪个区间。
EDI vs API 对照表：什么规模用什么，一目了然
| 维度 | EDI | API |
|---|---|---|
| 上线周期 | 4～12 周（含映射、联调、合规测试） | 2～6 周（沙箱当天可用） |
| 首年成本 | 几千到数万美元（含 VAN、映射、开通费） | 主要是开发人力，接口多随服务提供 |
| 成本结构 | 固定成本高、边际成本低，越大量越划算 | 前期低、随调用量增长，小单量无压力 |
| 数据实时性 | 批量为主（定时收发），实时性弱 | 实时查询 + webhook 事件推送，天然实时 |
| 适用场景 | 大零售商强制合规（850/856/810）、大批量 940/945 | 订单下发、实时库存、轨迹查询、对账 |
| 灵活性 | 对方改规范你就得重新映射测试，改动成本高 | 字段增减快，迭代成本低 |
| 门槛 | 需要 EDI 实施经验或外包服务商 | 会调 REST 接口的开发就能做 |
看完这张表，选型逻辑就剩一句话：有没有人逼你用 EDI？ 你的大客户（沃尔玛、塔吉特、家得宝这种量级的零售商）要求你走 EDI 合规，那没得选，乖乖上 EDI。但如果只是你和 3PL 之间的对接——发指令、对库存、查轨迹、对账——API 又快又便宜，EDI 的批量报文在这种场景下纯属大炮打蚊子。
还有一个反常识的判断：很多人觉得 EDI 比 API "更正规、更可靠"，这话对了一半。 EDI 的可靠是"合规可靠"——报文格式标准化、传输有回执、有审计链，零售商的合规部门认这个。但论"业务可靠"——比如黑五爆单时库存准不准、丢件了能不能第一时间知道——实时 API 加 webhook 反而更可靠。定时批量发的 846 库存快照，天然就比实时查询慢半拍。别把"正规"和"好用"混为一谈。
"先 API 后补 EDI"：成长型卖家的混合路线
我给成长型品牌的标准答案，从来不是二选一，而是分阶段走：
第一阶段（年单量 50 万单以下）：纯 API。 订单指令走 API 批量下（效果等同 940），库存走实时查询（比 846 快照准），轨迹走 webhook 推送，对账走 API 拉数据。这套组合拳，2 到 6 周上线，成本主要是开发人力。
第二阶段（接到大零售商订单，被要求 EDI 合规）：补 EDI。 注意是"补"，不是"换"。API 那套照常跑日常运营，EDI 只用来应付零售商的合规报文（850 采购单、856 预发运通知、810 发票）。两边各干各的，互不耽误。
第三阶段（年单量过百万、合作伙伴众多）：再评估。 到这个量级，EDI 的固定成本摊薄了，批量处理的效率优势也出来了，可以考虑把部分高频批量场景迁到 EDI。但即便如此，实时库存查询和事件推送这类场景，API 依然是更好的工具——行业里管这叫"API 干查询、EDI 干单据"，各取所长。
这事分两面：EDI 不会死，API 也取代不了 EDI。零售、杂货、汽车这些行业，商业关系是建在 EDI 合约上的，合约不迁，技术再漂亮也白搭。但新合作、新场景，先上 API 永远是更低的激活成本。
最后说句忠告：别问我 EDI 好还是 API 好。先看你今年能发多少单，有没有大零售商逼你合规——答案在你的出货量里，不在我的文章里。
作者：老米｜供应链老兵（20年）
