用 SP-API 创建 FBA 货件（Inbound v2024-03-20）：接口按顺序走一遍，哪一步不可逆、哪一步开始扣钱
用 SP-API 创建 FBA 货件，Fulfillment Inbound API v2024-03-20 从 createInboundPlan 到打印标签要经过 10 多个接口，但官方文档明确写着不可撤销的只有 confirmPlacementOption 一步；confirmTransportationOptions 选了亚马逊合作承运人后，小包裹 24 小时、整车/零担 1 小时后就扣运费。本文把每个接口按「只读 / 可重做 / 不可逆 / 扣钱」分好类，写出 4 个人工确认点，并说明我们自营小店为什么到 2026-11-05 还在卖家后台手工确认货件、AI 只做只读核对。
用 SP-API 创建 FBA 货件（Inbound v2024-03-20），顺序是：createInboundPlan → 选装箱方案 → setPackingInformation 填箱内信息 → generatePlacementOptions 生成分仓方案 → 生成运输和送达窗口 → confirmPlacementOption 确认分仓 → confirmTransportationOptions 确认运输 → getLabels 打标签。官方文档写明不可撤销的是 confirmPlacementOption（生成标签上 FBA 开头的货件号）；确认合作承运人运输后，小包裹 24 小时、整车/零担 1 小时内可以作废，过了就扣运费。所以我们的做法是：AI 和脚本只读、只比方案，这两次确认留给人。2026-11-05 为止，我们自营小店的货件都是在后台 Send to Amazon 里人工确认的，代码里没有调用 Inbound 写接口的模块。
适用对象
官方写明不可撤销
1 步
confirmPlacementOption：选定分仓并生成标签上的 FBA 货件号，「cannot be reversed」
合作承运人运费作废期
24 小时 / 1 小时
小包裹 / 整车或零担；过期后扣运费（官方用例指南）
我们 13 条配置费记录
全部 $0.00
2026-09-17 至 10-12 入账；6–7 月 3 个计划每个都是 5 个相同的箱子
Inbound 沙箱类型
静态沙箱
只返回固定示例响应，算不出你自己 SKU 的分仓和费用
- 真正不能回头的是 confirmPlacementOption；confirmTransportationOptions 选合作承运人后，作废窗口只有 24 小时（小包裹）或 1 小时（整车/零担）。
- 从 setPackingInformation 起，填进去的箱内信息就决定了分仓和费用；改了箱子信息必须重新 generatePlacementOptions，想整体丢弃只能新建计划。
- 我们的写入闸门把 generate、set、confirm 这些 POST 全算写操作：没有一次性授权就发不出去，只放行 GET（listInboundPlans、getShipment 等）。
- 该先自动化的是确认前的比对表（目的地、配置费、运费、过期时间），不是确认本身。
v2024-03-20 建货件的接口顺序：一张表看哪一步能重做
这是官方「卖家事先知道箱内信息」的流程（小包裹和零担都适用）。新流程里所有 POST 都是异步的：调用后拿到 operationId，要用 getInboundOperationStatus 查到成功才算完成。v0 的 createInboundShipmentPlan、createInboundShipment 这些建货件接口已经被 v2024-03-20 取代，但打标签的 getLabels 和打提单的 getBillOfLading 仍然用 v0。
表里「性质」一列是我们按官方说明归的类：只读不改任何东西；可重做指可以重新生成或改了再来；不可逆指官方写明不能撤销；扣钱指官方写明会向账户收费。
| 顺序 | 接口 | 做什么 | 性质 | 官方提醒 |
|---|---|---|---|---|
| 1 | createInboundPlan | 建入库计划：发货地址、目标站点、每个 MSKU 的数量和预处理/贴标负责人 | 写入，可取消（cancelInboundPlan） | 美国站 labelOwner 不再接受 AMAZON；2026-01-01 起美国站不再提供预处理和贴标服务，要卖家自己做 |
| 2 | generatePackingOptions → listPackingOptions → listPackingGroupItems → confirmPackingOption | 确定哪些 SKU 能装在一起（装箱组） | 写入，选项有过期时间 | 危险品等不能和别的 SKU 同箱；每个选项可能带费用或折扣 |
| 3 | setPackingInformation | 按箱填：箱内 SKU 和数量、尺寸、重量、箱数 | 写入，可改但有代价 | 改了箱子信息要重新 generatePlacementOptions；想整体丢弃箱子信息不支持，只能新建计划；不填可能产生人工处理费 |
| 4 | generatePlacementOptions → listPlacementOptions → getShipment | 生成并查看分仓方案：去哪些运营中心、每个方案的费用/折扣和过期时间 | 生成是写入，查看是只读；可重新生成 | 费用由算法按当时情况给出，不是固定费率；过期了要重新生成 |
| 5 | generateTransportationOptions → listTransportationOptions | 按分仓方案和货件生成运输方案（承运人、方式、报价） | 生成是写入，查看是只读 | 要传分仓方案 ID、货件 ID、预计发货日、发货地址 |
| 6 | generateDeliveryWindowOptions → listDeliveryWindowOptions | 送达窗口（非合作承运人必填） | 生成是写入，查看是只读 | 每个窗口有 validUntil，过期要重新生成 |
| 7 | confirmPlacementOption | 选定分仓方案，生成标签上的 FBA 开头货件号（shipmentConfirmationId） | 不可逆 | 官方原话：This option cannot be reversed after it is selected；接口参考写「Once confirmed, it cannot be changed」 |
| 8 | confirmDeliveryWindowOptions、confirmTransportationOptions | 确认送达窗口和运输方案 | 扣钱 | 确认合作承运人等于同意按报价扣运费；确认后不能再生成或确认新的运输方案；小包裹 24 小时、整车/零担 1 小时内可作废 |
| 9 | listShipmentBoxes + v0 getLabels / getBillOfLading | 打箱标和提单 | 只读 | getLabels 要用 FBA 开头的确认货件号，不能用 v2024-03-20 计划里的内部货件号；用接口取标签不会把状态改成 ready_to_ship |
| 10 | updateShipmentTrackingDetails、getShipment、listShipmentItems | 回填物流单号、跟踪状态和到货数量 | 写入（回填单号）/ 只读 | — |
唯一不可逆的一步：confirmPlacementOption 之前要看清什么
confirmPlacementOption 只需要两个参数：计划 ID 和分仓方案 ID。参数越少，越容易被脚本或 AI 顺手调出去。按下去之后，这个计划的分仓就定了，标签上的货件号也生成了。
确认前要看的东西都在 listPlacementOptions 和 getShipment 里：这个方案拆成几票、每票去哪个运营中心、费用还是折扣、什么时候过期。官方说这些费用和折扣是算法在创建货件时按预计量、预约情况和配送速度给出的，不按固定费率算，所以每次都要重新看，不能拿上次的结论套。
我们自己的一个对照：2026 年 6–7 月我们有 3 个货件计划，每个都是 5 个完全相同的箱子，后台都拆成了 5 票、发往 5 个不同的运营中心。其中一个计划是 5 箱共 1,200 件，每箱 6 个 SKU 各 40 件、9.2 kg、50×40×40 cm，结果是 5 票各 1 箱。2026-09-17 至 10-12 入账的 13 条入库配置费记录，金额全部是 $0.00。当时选的是哪个选项我们没留截图，「亚马逊优化拆分」是按规则推断的（详见下方配置费那篇）。这说明两件事：分仓方案直接决定钱和去向；5 箱去 5 个地方也是正常结果，不是脚本出了错，没人看过的话很容易被当成异常重做。
第二个要人看的：确认运输后，作废窗口只有 24 小时或 1 小时
官方对 confirmTransportationOptions 的说明是：选择亚马逊合作承运人的方案，就表示你接受报价、同意亚马逊向你的账户收取运费，并请承运人来取货。确认之后，这个计划不能再生成或确认新的运输方案。
后悔的话可以用 cancelInboundPlan 撤掉运输请求，但小包裹要在确认后 24 小时内，整车/零担只有 1 小时，过了就扣运费。也就是说，这一步不是不可逆，而是有一个很短的作废期。对一个夜里自动跑的脚本来说，1 小时基本等于没有：等人早上看到，钱已经扣了。
我们把 generate 也算写操作，不只盯 confirm
很多人的直觉是：只要不调 confirm，随便试。我们不这么看。我们店铺代码里有一个写入闸门：凡是发往 SP-API（包括 sandbox 域名）和广告 API 的请求，GET、HEAD、OPTIONS 直接放行，另外只放行一小份白名单里的只读 POST（比如建报表、查费用预估、列表查询）；其余请求必须带一次性授权，否则在发出去之前就被拦下。Inbound API 的 generate、set、confirm 全是 POST，都不在白名单里。
原因有三个。第一，setPackingInformation 填进去的箱子信息不能整体丢弃，想推倒重来只能新建计划，旧计划要记得取消。第二，每次 generatePlacementOptions 都会产生一套新方案和新的过期时间，脚本重试几次，谁也说不清最后看的是哪一套。第三，官方说如果在确认前从 API 切到 Send to Amazon，后台会重新生成方案，之前的全部作废，人和脚本同时操作一个计划最容易出这种事。
这个闸门是我们自己的约定，不是安全边界：它防的是手滑、重复和没登记的写入，挡不住有意绕过。所以我们到现在还没让 AI 调 Inbound 的写接口，它能做的只有读。
4 个人工确认点：建货件交给 AI 时，这几处必须停下来
下面是我们给 agent 写的规则，前两个是钱和不可逆，后两个是我们吃过亏的地方。
第 4 条来自一次真实事故：2026-09-07 我们调查一款发错货投诉偏高的商品，发现这款按货件直接接收了 415 件，而申报和采购都只有 300 件。根因是入仓前同一箱里混装了不同款，被按整箱统一贴标。系统里的箱内信息写得再整齐，也替代不了有人打开箱子核对一次。
| 确认点 | 在哪一步 | 人要看什么 | AI 可以做什么 |
|---|---|---|---|
| 1. 分仓方案 | confirmPlacementOption 之前 | 拆几票、去哪些运营中心、配置费还是折扣、过期时间；和上一个同类计划比 | 把所有方案整理成一张对比表，标出最便宜和最少拆分的方案；不调用确认 |
| 2. 运输方案 | confirmTransportationOptions 之前 | 承运人、报价、预计到达日、作废窗口（24 小时 / 1 小时） | 列出报价和截止时间，提醒作废期；不调用确认 |
| 3. 箱内信息 | setPackingInformation 之前 | 每箱 SKU、数量、尺寸、重量和实物一致；混装箱要逐箱写清楚 | 用采购单和装箱单做数量核对，标出对不上的行 |
| 4. 实物贴标 | 打印标签之后、发货之前 | 抽箱打开核对：箱内款式和箱标一致，混装箱逐件贴 FNSKU | 生成抽检清单；到货后用 listShipmentItems 比对实收和申报 |
用沙箱能测到什么、测不到什么
官方表格里 Fulfillment Inbound API 的沙箱类型是「Static」，也就是静态沙箱：按文档里的示例请求返回固定的示例响应。它适合检查认证、签名、URL 和响应解析写得对不对，但算不出你自己 SKU 的分仓方案、配置费和运费，也没法验证 confirm 之后的真实状态变化。
我们的建议是分两层测：静态沙箱测代码能不能跑通；真实店铺只用 GET 类接口读已有计划（listInboundPlans、getInboundPlan、getShipment、listPlacementOptions、listTransportationOptions），拿来校验你的比对表。确认分仓和运输，留在后台或者留给有一次性授权的人工操作。
接到 9810 报关数据时要注意的两个货件号
v2024-03-20 里一票货件有两个号：createInboundPlan 和 generatePlacementOptions 阶段生成的内部 shipmentId，以及 confirmPlacementOption 之后才生成、印在标签上的 FBA 开头确认号。getShipment 两个都能查到。做 9810 出口要把报关单的项号对到 SKU 和 FBA 货件，用的必须是确认号；拿内部 ID 去打标签或对单，官方明确说不行。
这一段只讲货件数据的对应关系，不构成报关或税务建议；9810 的流程和单证见下方支柱页。
这套做法没解决什么，以及下一步资料
它不会让发货更便宜，也没有让我们少干多少活：人工确认那几步还是人在做。我们没统计省了多少工时，也没有「API 建货件前后」的费用对照，所以不写这类数字。它解决的是另一件事：最容易出钱、出错的几步，始终有人看过。
接下来这个专题会继续写 v0 到 v2024-03-20 的字段对照、常见报错和从货件到 9810 报关数据的串联。想先拿资料：¥199 亚马逊 AI 自动化接入包里有两条 API 申请 SOP、踩坑速查表、Agent 接管行为红线表和验收模板（不含代申请、代运营和真实凭据）；WorkBuddy 上也有一个 ¥9 的「亚马逊9810建货件模板包」，需要先安装 WorkBuddy 客户端才能购买，分享页不显示价格。
免费 · 留邮箱领速查表
亚马逊上架报错码速查表（Excel 可直接打开）
- 站上已核对的报错码一张表：8541、8007、5461、5665、90057、13013 等，新码上线会同步加进来
- 每个码：一句话含义、官方原文说明、出现场景、官方处理步骤摘要
- 附官方 PDF 出处和详细说明页，打印出来贴在运营工位就能用
觉得有用？转给正在做这件事的同事或朋友
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
SP-API 创建 FBA 货件哪一步不能撤销？
官方文档写明不能撤销的是 confirmPlacementOption：选定分仓方案并生成标签上的 FBA 货件号后就改不了。确认合作承运人运输后，小包裹 24 小时、整车/零担 1 小时内还能作废，过了就扣运费。
v0 的 createInboundShipmentPlan 还能用吗？
建货件已经要用 v2024-03-20，v0 的建计划、建货件接口被取代。v0 里仍保留的有 getLabels、getBillOfLading、getPrepInstructions、getShipments 等 6 个，打箱标和提单还要用 getLabels 和 getBillOfLading。
Inbound API 可以在沙箱里完整测一遍吗？
只能测一部分。Fulfillment Inbound API 是静态沙箱，按示例请求返回固定响应，适合测认证和解析，算不出你自己 SKU 的分仓和费用。我们用真实店铺的只读接口读已有计划来校验。
改了箱子信息要重新生成分仓方案吗？
要。官方说生成分仓方案后再用 setPackingInformation 改箱子信息，必须重新调用 generatePlacementOptions 才能确认；想整体丢弃箱子信息不支持，只能新建计划。
能让 AI 自动创建亚马逊货件吗？
我们不让 AI 调确认类接口。AI 负责读计划、整理分仓和运输方案对比表、核对箱内数量，确认分仓和运输由人来做。到 2026-11-05，我们自营小店的货件都是在后台人工确认的。
下一步
推荐动作
想让 agent 接手店铺 API 之前，先把申请流程、权限和红线定好：两条 API 申请 SOP、踩坑速查表、Agent 接管行为红线表和验收模板，不含代申请、代运营和真实凭据。想让我们帮你把只读核对这层搭起来，可登记首次诊断（¥999 起，只登记不预收）。