你的集成提交了一次价格或库存更新，收到 ACCEPTED，然后把任务标记为完成。随后卖家反馈该商品仍然无法购买。缺失的一步是：把这次提交与之后对商品信息的一次实际观察进行对账。
Amazon 区分「接受进入处理」与「之后出现的处理问题」。写入响应无法报告事后才出现的问题；而随后的一次 getListingsItem 读取可以把它们暴露出来。保留回执，但不要把它当作已达到预期在售状态的证据。Amazon 的 Listings Items 概述解释了这条边界。
本运行手册面向已获授权的集成，用于检查自家卖家在单个 Amazon 站点中的独立 SKU 或可售子 SKU。库存示例使用卖家自配送和 DEFAULT 渠道。它不对账 FBA 库存、竞争对手的报价或 Featured Offer。变体父商品本身就是有意不可购买的，所以要把它排除在期望「可购买商品」的告警之外。Amazon 的工作流指南记录了这一例外。
保留四条记录，而不是一个成功标志
使用下面这个建议的记录结构，让每个结论都可以被检查：
| 记录 | 保留什么 | 它能证明什么 |
|---|---|---|
| 预期业务状态 | 卖家、SKU、站点、内部修订号、预期价格/币种、库存意图和销售状态 | 你的业务本来打算改成什么 |
| 提交回执 | 请求时间、操作、响应状态、提交标识符和返回的 issues | Amazon 是否最初接受了这次提交 |
| 卖家贡献数据 | 随后一次读取中请求到的 attributes 数据及其采集时间 | Amazon 返回的最新已贡献属性 |
| 观察到的商品状态 | 同一次读取中限定范围的 summary、offers、配送可用性和 issues | 这些返回数据集对该商品的报告内容 |
这是四条相互独立的记录，而不是一个原子事务。把响应和采集时间一并存下来，这样后续复核的人才能区分「字段比较」与「关于处理顺序的假设」。
Amazon 说明 attributes 代表卖家最近提供的数据，而 fulfillmentAvailability 等部分代表在售的实时商品数据。这两个数量在一笔销售之后可以合理地不一致。把已提交库存与实时库存当作必须永远相等来比较，会制造出错误的修复信号。Listings Items 注意事项给出了这个具体例子。
明确请求你打算核对的数据集
getListingsItem 默认只返回 summaries。一次省略了 offers 的成功请求，并没有检查在售报价。要为本次排查显式选择所需的数据集。操作参考列出了参数和默认值。
下面是给现有已授权 SP-API 客户端使用的请求形态，不是一条完整的带认证命令：
GET /listings/2021-08-01/items/{sellerId}/{sku}
marketplaceIds={marketplaceId}
includedData=summaries,attributes,issues,offers,fulfillmentAvailability使用客户端中已配置的区域端点和已授权卖家上下文，把 SKU 编码为路径片段，并把后两行作为查询参数发送。我们有意在每次排查中只检查一个站点，以简化归因。
匹配返回的 SKU 和目标站点的 summary。做价格检查时，选出属于该站点、预期 B2C 或 B2B 报价类型、适用受众（如果有）以及预期币种的那条报价。如果无法唯一确定预期报价，就让价格检查保持未定论。金额比较使用十进制数，而不是浮点近似值。
对于这个卖家自配送示例，检查 DEFAULT 配送渠道，Amazon 在其配送指南中将其定义为标准卖家自配送。不要换成其他渠道，也不要把缺失的数量当作零。官方响应模型把多个数据集定为可选，并且不要求一定有配送数量。在本运行手册中，数据缺失是一种独立的结果。
把每个观察结果转换为具体的下一步动作
下面的矩阵是从这些响应语义推导出来的操作策略，不是 Amazon 的完成保证。
| 观察结果 | 允许得出的结论 | 下一步动作 |
|---|---|---|
提交为 ACCEPTED；尚未做后续读取 | 已接受，在售结果未验证 | 排队一次限定范围的读取；保留回执 |
| 读取因授权、限流或服务错误而失败 | 当前商品状态未知 | 先解决读取失败；与商品状态分开处理 |
| 成功响应缺少必需的数据集或匹配的报价 | 该项检查为未知 | 确认请求的数据集和范围；不要用零或 false 填补缺失值 |
有效的目标 summary 缺少 BUYABLE，而该 SKU 预期在售 | 返回的状态为不可购买 | 检查请求到的 issues 和配送可用性；核对是否有意下架及库存意图 |
| issues 数据集为空 | 该数据集中没有报告任何问题 | 独立核对可购买状态；不要从空列表推断 |
| 目标商品报告了 issues | 这些报告的问题需要诊断 | 检查 code、severity、相关属性以及站点/执法细节（如有）；逐一排查适用的问题，同时独立核对可购买状态 |
| 返回的报价与预期价格和币种一致 | 这条观察到的报价匹配 | 记录匹配；单独评估库存和可购买状态 |
| 唯一确定的报价币种正确但价格不同 | 观察到价格不一致；需要关注 | 保留预期值/观察值，核实最新业务修订号和其他写入，然后继续有界的对账或升级处理；不要盲目重新提交 |
| 已贡献库存与实时库存不同 | 返回的是两种不同性质的数量 | 在任何写入之前，先查询当前库存权威来源和中间发生的变更 |
BUYABLE 和 DISCOVERABLE 描述的是不同状态。有效状态数组中缺少 BUYABLE，与 summary 缺失或读取失败是不同的情况。Amazon 还说明，没有已定义的 issues 也可能与其他商品问题并存。状态与 issues 通知定义描述了这些区别；检索指南把不可购买的诊断与 issues 和库存联系起来。
在请求层处理 HTTP 失败。参考文档区分了 403 授权失败、429 限流以及 500/503 服务错误。404 需要对商品和请求范围进行排查；它并不表示已验证的库存数量为零。在当前 API 用量计划下，酌情使用有界的读取重试，不要把每次失败的读取都变成一次新的商品写入。getListingsItem 响应提供了错误分类。
修复数量不一致之前先把它捋清楚
考虑一条纯属示意的追踪记录，而不是真实卖家测试。预期更新是：某个可售 SKU 的 B2C 价格为 24.90 美元，卖家自配送库存 5 件。提交被接受。之后一次范围正确的读取报告如下：
| 字段 | 示意观察值 | 解释 |
|---|---|---|
attributes 中的已提交库存 | 5 | 返回的最新贡献值 |
DEFAULT 实时数量 | 4 | 该渠道报告有 4 件可用 |
| 选中的报价 | 24.90 美元 | 观察到的价格与预期金额和币种一致 |
| summary 状态 | BUYABLE、DISCOVERABLE | 该商品同时报告了这两个状态 |
| 请求到的 issues | 空数组 | 那里没有报告任何问题 |
仅凭库存差异并不能证明更新失败。一笔销售是一种可能的解释，但这份响应并不能确定原因。在决定是否需要纠正之前，先与库存系统以及中间发生的订单或写入进行对账。盲目地把库存恢复为 5 件可能会撤销一次合理的库存变更。
反向的捷径同样不成立：价格匹配并不能证明是这次特定提交导致了观察到的值。另一个写入方可能提供了相同的金额。记录为「观察到匹配」，保留内部修订号和回执，不要声称因果关系。
如果这次读取只请求了 summaries，可购买状态或许可以观察到，而价格和数量检查仍然是未知。保留这个部分结果，而不是把整个任务提升为成功。
限定排查范围，并让迟到的通知仍然有用
按卖家、SKU、站点和内部修订号各维护一条对账记录。给每项必需检查单独的状态：待定、观察到匹配、需要关注或未知。更新的业务修订号应当取代旧的目标，而不是被旧任务的重试覆盖。
根据你的库存风险和 API 配额，选择合适的重试计划、最大尝试次数和排查截止时间。这些是你的运营选择；本运行手册不提供任何「超过多久已接受的更新就必须生效」的通用时限。到达截止时间时，带上保留的回执、范围、采集时间和相关响应字段，把未解决的检查升级处理。
利用适用的状态或 issues 通知来安排再一次限定范围的读取，并对仍在待定的任务做有界的对账巡检。保留通知的标识和时间以便诊断。迟到的通知应当触发排查，但不能仅仅因为它最后到达就取代更新的观察结果。Amazon 的 Listings APIs FAQ 承认通知可能滞后于直接读取。
summary 中的 lastUpdatedDate 是商品更新时间戳。模型并没有把它定义为每个价格或库存字段各自的截止时间戳。不要把它当作「所有返回部分描述的是同一个原子状态」或「你的提交已完全应用」的证据。
把传输层排障与商品决策分开
更换代理并不能解决目录问题，哪怕请求现在能完成了。如果请求在收到有用响应之前就失败，用代理超时指南诊断连接。一旦收到有效的商品响应，就用其中限定范围的字段和你的业务意图来决定下一步动作。
对于另一类公开页面采集工作流，检查 Amazon 的 HTTP 200 是否包含预期页面回答的是另一个问题。本卖家对账工作流使用已授权的 SP-API 数据，不从抓取的店面页面推断商品状态。
本文及其决策矩阵在 AI 辅助下依据 2026 年 9 月 12 日访问的 Amazon 一手文档编写，随后经过独立审阅。示例仅为说明；没有查询任何卖家账户，也没有更改任何商品。该矩阵是一种建议的操作方法，不是实测的恢复结果。
加入 ipvolt 候补名单，在代理访问开放时收到一封通知。访问尚未开放。开放时只发一封邮件，没有别的。