亚马逊 SP-API 9 月 28 日起强制新 Listing 属性：新增必填字段与枚举值，JSON 提要未改即报错
一次 API 文档的小更新，能让多少商品页面同时失联？亚马逊给出的答案是：凡是通过接口写listing的人，从 2026 年 9 月 28 日开始，少传一个字段，整条请求就可能被直接拒绝。
亚马逊在 Selling Partner API 更新日志中挂出《九月更新至商品发布属性用法和枚举值》的变更说明，称自 2026 年 9 月 28 日起，将更新多个站点、多种商品类型的属性用法与枚举值。受影响的对象说得很具体：使用 Listings Items API v2021-08-01 与 JSON_LISTINGS_FEED 提要类型，去创建或编辑「带有要约（offer）的商品」listing 的私人和公共开发者。纯商品 listing、XSD 提要上传、传统 XML 提要上传三类场景不在本次变更范围内。
真正让卖家头疼的不是「要不要填」，而是「什么时候发现自己没填」。这类接口变更通常不发邮件、不弹窗，改 Kitchenware 的一个必填属性，坏的可能是一整个类目的上新队列。亚马逊长期以来的方向是逐步淘汰 XML 与扁平文件、全面转向 JSON_LISTINGS_FEED，这次的豁免是临时的，不是长期的。
一、改了什么，改在哪两个口子上
先把边界划清楚，因为这次最容易写反的就是边界。
受影响的只有两个入口：Listings Items API v2021-08-01，以及 feedType 为 JSON_LISTINGS_FEED 的提要通道。判断标准不是「你用什么传」，而是「你传的是什么」——只有当被操作的listing是带报价（offer）的商品时才适用。也就是说，纯商品信息（product-only listing）不在其中；走 XSD 提要的、走传统 XML 提要的，本次也不在其中。
需要做的动作有三层：第一层，新增的属性里标注为必填（required usage）的，在创建或编辑时必须提交值；第二层，标注为可选（optional usage）的，可以自主决定要不要填；第三层，属性值里有枚举下拉的，如果新枚举比旧选项更贴合商品，应当从更新后的下拉列表里选取新值。
亚马逊没有在公告里逐条列出具体属性名和站点，而是把这部分指向了单独的「SP-API 商品元数据变更」清单。这意味着真正的核对工作量，是一次逐商品类型的对照，而不是改一处配置就能收工。
二、失效的样子，通常是静默的
EcomWatch 在报道这次变更时用了比较直白的说法：API 已经从一根「数据管道」变成了一台「校验机器」。这个判断有道理。
失败的表现形式不是报错弹窗，而是业务侧的异常。负责自动改价的工具忽然不调价了，库存同步卡在旧数字上，批量上新队列里的几十条记录停在 pending 状态。商品不会立刻消失，但一旦因属性不完整被判定为不合规，就有可能掉出搜索结果、失去购物车资格。
排查成本的归属更要命。亚马逊返回的是一条被拒的请求，具体是哪个商品类型、哪个属性触发的，需要自己去庞大又分散的元数据文档里翻。据 EcomWatch 的分析，亚马逊把目录标准化的成本外部化了：平台得到一个更干净、更好搜的数据库，而开发工时与软件维护费由卖家和服务商承担。
有一个细节值得警惕：同一套账号可能同时存在多条提交链路。ERP 走 API，老产品线还留着 XML 提要，海外 studio 用第三方工具另行上传。别因为「我们是走 XML 的，不受影响」就松口气——只要其中一条链路是 JSON 提要，那部分商品照样在生效范围内。
三、四条链路先自查
与其全员扑到属性清单上，不如先按链路排优先级。最容易先断的四条是：
一是上新链路。凡是通过 Listings Items API 或 JSON_LISTINGS_FEED 创建listing的流程，优先级最高，因为新建请求要一次性满足全部必填项。
二是编辑链路。这条最容易被忽略。很多团队只在走 JSON_LISTINGS_FEED 时想起来做校验，但「改进对listing商品的编辑」同样触发本次变更。改个标题、换个主图，都可能因为同一 SKU 缺新的必填属性而被拒绝。
三是自动化整改链路。自动调价、库存预留调整、后台 sellable-to-catalog 修复，这类流程通常以 PATCH 形式写入接口，一旦被拒，表面看是「价格没变」，实际是接口已经不认这笔数据了。
四是 ERP 与服务商的模板缓存。多数 ERP 会在本地缓存一段时间的商品类型 schema，缓存过期没刷新，就会继续按旧的必填集组装数据。先确认服务商有没有在 9 月 28 日前拉取新版 product type definitions。
自查的收尾动作建议做一次真实演练：挑 3 个不同类目的代表 SKU，在生产环境里各跑一次新建和一次编辑，把返回体完整存档。能通过不代表全局没问题，通不过则能立刻定位到具体商品类型。
四、一次全量属性体检怎么排
核对工作量大，靠人肉扫不现实。可以按下面五步压缩。
第一步拉清单。把自己在售的 SKU 按「站点 + 商品类型（product type）」分组，输出一张二维表。同一款商品在美国站和欧洲站的商品类型可能不同，需要分别核对。
第二步对齐元数据。用 Product Type Definitions API 拉取每个商品类型的最新 schema，导出必填属性列表，和本地实际情况做差分。差分结果落到三条：缺值、值不在枚举范围内、值存在但不够贴合。
第三步分开处理「必须」和「可选」。必填项进紧急修复队列，且在 9 月 28 日前最好全部清完；可选项和枚举优化另建一个低优先级任务，不要和紧急队列混在一起，否则没人说得清到底还剩多少硬性缺口。
第四步回到商品本身。枚举值不是「选一个看起来顺眼的」，而是「选一个与实际一致的」。tmark.pro 在给卖家的操作建议里反复强调一件事：一个类目拉伸强度、防水等级这类描述选项，应该拿货的规格书去比对，而不是为了让listing看起来更丰满就往上填。填错的和漏填的，代价不一样——前者可能构成商品不符。
第五步留证据。改完的记录、对应的规格来源、谁签的字，一并存档。欧洲站的合规审查越来越看重「你如何证明这个值是真的」，这套材料日后用得上。
五、XML 存量卖家的窗口还剩多久
XML 提要上传、XSD 提要上传这次被明确排除在外，但这不该被读成「不用动」。
亚马逊过去数年一直在压缩 XML 与扁平文件的生存空间，处理速度更快、错误反馈更细的 JSON_LISTINGS_FEED 才是它想要的终局。这次的豁免更像是为了避免一次性把大量存量集成打崩而设的缓冲带。
对还在跑 XML 的团队，合理的做法是把迁移排进计划而不是拖到被逼。迁移动作本身不复杂：提要类型换掉、字段结构改成 JSON、错误回落逻辑重写。真正耗时的是历史数据的清洗——老 XML 里那些被容忍多年的「脏值」，到了 JSON 提要上大概率会变成硬错误。
留给大家的时间，取决于亚马逊下一次把豁免写在哪条公告里。用渐进的方式先把高频商品类型迁过去，比一次性切换更稳。
站远一点看，这次变更本身没有新收费，也没有新增惩罚条款，但它改变的是责任归属：listing 数据质量的锅，以前亚马逊和卖家一起背，现在更明确地压在了集成这一侧。平台用外部化的方式拿到了一个更干净的目录，卖家为自己的接口依赖买单。
9 月 28 日之后，第一批被拒的请求会集中在哪一类 SKU？答案大概率不在更新日志里，而在你自己那份还没做完的属性差分表里。
六、参考资料
- Amazon Developer（SP-API 更新日志）：《September Updates to Listing Attribute Usage and Enumeration Values》
- Amazon Developer（中文版更新日志）：《九月更新至商品发布属性用法和枚举值》
- Amazon Developer 文档：《SP-API product metadata changes / Listings Items API v2021-08-01》
- EcomWatch：《Amazon Forces API Overhaul As New Listing Attributes Go Live For Sellers》
- TMark：《Prepare Your Amazon Listing Data for September 28》