A-to-Z 索赔没有单独的 SP-API 接口，要分情况取：

1. 金额和订单：用 Finances API 的 listFinancialEvents，返回里的 GuaranteeClaimEventList 就是 A-to-Z 索赔，拒付在 ChargebackEventList。新版 listTransactions（2024-06-19）也能拉，不过得自己按交易类型筛。注意财务事件可能不包含最近 48 小时的订单。
2. 对账：拉 Settlement 报告 GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2。旧的 XML 和 Flat File 版本 11 月 11 日下线，别再用了。
3. 索赔率、索赔订单数：走 Data Kiosk 的 seller analytics 数据集，字段是 accountHealthAtozClaimOrderCount 和 accountHealthAtozGuaranteeClaimRate（只统计自配送订单）。也可以用账户健康报告 accountHealthReport。
4. 索赔原因、买家陈述、申诉状态：目前 API 取不到，只能在卖家后台 Customer Service Performance 里看或下载。

目前 SP-API 没有任何接口可以读取买家发起的站内信（Buyer-Seller Messaging）。**

亚马逊官方的 Messaging API 只能用于卖家向买家发送消息，并且只能按订单、使用固定的消息模板发送；它不提供收件箱、消息列表或消息详情等读取接口。Notifications API 也没有“买家来信”这类通知事件。

所以您现在的做法，也就是把站内信转发到店铺邮箱、收邮件后再回复，就是目前的标准方案。直接回复那封转发邮件，亚马逊会把回复作为站内信送达买家，并计入 24 小时响应时效。注意发件邮箱需要是在卖家后台登记过的授权发件地址，否则邮件会被退回。

相关接口一览（中文文档）

Messaging API（卖家 → 买家，仅发送）

其他容易混淆的接口（同样不能读取买家站内信）

调用 Messaging API 需要在开发者资料中申请 Buyer Communication（买家沟通） 角色。

可以检查邮箱垃圾箱有没有相关的邮件，
如果确实没有再次提交一下表单看看。

具体请求信息给一下看看。

在 Fulfillment Inbound API v2024-03-20 里，shippingMode 只出现在两个 schema 里，全都是响应：

• TransportationOption.shippingMode — listTransportationOptions 返回的
• ShippingConfiguration.shippingMode — listPackingOptions 返回的

整个 API 里没有任何一个请求体接受 shippingMode / SHIPPING_MODE。所以你前后端传得再顺畅，这个值也只是在你自己系统里打转，亚马逊那边压根没收到 → 后台运输方式当然是空的。

正确的写入方式：选 ID，不是传 mode

运输方式是通过选中一个 transportationOptionId 隐式确定的，三步：

generateTransportationOptions (POST, 异步)
↓
listTransportationOptions (GET) → 拿到一堆 option，每个带 shippingMode + shippingSolution
↓ 在这里用你前端传来的 SHIPPING_MODE 做【筛选】
confirmTransportationOptions (POST, 异步) → 只提交 shipmentId + transportationOptionId

confirmTransportationOptions 的请求体只有这几个字段，没别的：

{
"transportationSelections": [

{
  "shipmentId": "sh1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "transportationOptionId": "to1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "contactInformation": { "name": "xxx", "phoneNumber": "1234567890" }
}

]
}

所以代码改法是：前端传的 SHIPPING_MODE 拿去 filter 列表，而不是塞进请求体。

这个现在没有。 亚马逊暂时没开放这个，暂时看没有开放的可能。毕竟爬虫都要登录的买家账号才可以。

唯一沾边的是 Customer Feedback API v2024-06-01

GET /customerFeedback/2024-06-01/items/{asin}/reviews/topics
GET /customerFeedback/2024-06-01/items/{asin}/reviews/trends
GET /customerFeedback/2024-06-01/items/{asin}/browseNode
GET /customerFeedback/2024-06-01/browseNodes/{browseNodeId}/reviews/topics|trends
GET /customerFeedback/2024-06-01/browseNodes/{browseNodeId}/returns/topics|trends

它是 Seller Central「商机探测器（Product Opportunity Explorer）」的 API 版本，返回的是评论话题洞察，不是评分数据：

• getItemReviewTopics 响应字段只有：asin / itemName / marketplaceId / countryCode / dateRange / topics（最正面和最负面各 10 个话题）
• 每个话题下的 ItemReviewTopicMetrics 有 occurrencePercentage（提及该话题的评论百分比）和 starRatingImpact

1 SP-API 的开发者注册不在 developer.amazon.com

developer.amazon.com 是 Alexa / Appstore / Login with Amazon 那一套，跟 SP-API 不是一个体系。SP-API 的开发者档案就在 SPP（solutionproviderportal.amazon.com）里填，或者从卖家后台 Apps and Services → Develop Apps 进去，两个入口通向同一个东西。所以不存在"1 个 SPP 账号 + 1 个开发者账号"，它本来就是一个。

developer.amazon.com 唯一用得上的地方是广告 API，广告的 client 是个 LwA 应用，那个确实要在这里建。

1. "为每个卖家账号创建独立应用"没有意义

同一个开发者档案下建五个 app，在亚马逊眼里还是同一个开发者。app 分不开，开发者档案才是主体单位。

3 Private 应用只支持 self-authorization，不支持 OAuth，而且定义上就是"仅限本组织内部使用"。你多主体去 self-authorize 同一个私有应用，等于是自己跟亚马逊报备这几个主体是一家。目前没有公开案例说这条被拿来判关联，但从安全性上讲，多公司主体授权不建议这么做。

该走的是 public，也就是商用 SPP 开发者，赛狐、领星这些都是这个形态。逻辑上它就是"服务商 + 客户 OAuth 授权"的标准模型，你的各个店铺是这个服务商的客户，这在亚马逊侧是完全正常的关系，全世界的 ERP 都长这样，没有关联含义。

试试订单接口。 注意：税务相关的需要有PII，税务相关的受限权限

GET /orders/2026-01-01/orders/{orderId}?includedData=TAX → 取 Order.tax.taxRegistrations[]，过滤 entityType == "BUYER"：

• taxRegistrationNumber ← 对应 v0 的 TaxClassifications[].Value（就是身份证/税号本身）
• taxRegistrationType ← 对应 TaxClassifications[].Name
• legalName ← 对应 CompanyLegalName

大概率token用错了，看看是不是用成 refresh_token来调用接口了。 或者检查一下token是不是复制错了

问题太不清晰了。 你看的是什么时候的文档？

如果只是调用SP-API已经不需要IAM这些了。

如果需要对接通知，那就是另外一个问题了，可以参考：https://sp-api.net/ask/question/208673.html

如果遇到申请问题需要协助可以随时联系我： 微信 sfgoods

这个需求可以通过两个 API 来实现：

如果是批量统计，用 Reports API 里的 GET_FLAT_FILE_RETURNS_DATA_BY_RETURN_DATE 这个报告类型，里面直接有 Return Reason（退货原因）、Return quantity（数量）、Refunded Amount（退款金额）、Return request date（申请日期）这些字段，拿到数据之后按日期字段自己做分组统计就行了，单次最多支持查 60 天的数据。

如果只是查某一笔订单的退款，用 Finances API 的 listFinancialEventsByOrderId，传订单号进去就能拿到对应的财务事件，包括退款金额。

一般是先用 Reports API 拉一段时间的平铺文件做统计分析，单笔核查的时候再用 Finances API 补充确认，两个配合着用比较方便。

另外需要注意申请 Inventory and Order Tracking 这个角色权限，没有这个权限的话 Returns 报告是拉不到的。

最近太忙了，没注意到还有这个提问

打印箱子标签用的是 getLabels：

**GET /fba/inbound/v0/shipments/{shipmentId}/labels
**
注意 shipmentId 要传的是 shipmentConfirmationId，就是那个 FBA15G7C2CZQ 这种格式的，不是 v2024 流程里 createInboundPlan 返回的那个 shipmentId

PageType 传 PackageLabel_Plain_Paper 就行，你截图里选的 99x105 A4 纸每页6个，对应的就是这个。

文档地址： https://developer-docs.amazon.com/sp-api/reference/getlabels

API调试地址：

ERP 系统是可以直接通过 SP-API 的 FBA Inbound v2024-03-20 来实现自动分仓的，不过新版 API 的流程和以前 createInboundShipmentPlan 不一样，需要按新的流程调用。

一般 ERP 对接的流程大致是：

createInboundPlan
提交发货地址、SKU 和数量，创建 inbound plan。

generatePackingOptions / listPackingOptions
生成并获取装箱方案。

generatePlacementOptions / listPlacementOptions
生成分仓方案，Amazon 会返回系统计算好的仓库分配结果。

confirmPlacementOption
确认分仓方案后会生成对应的 shipment。

setPackingInformation
上传箱规、重量、SKU数量等装箱信息。

简单理解就是：
ERP提交SKU数量 → Amazon返回分仓结果 → ERP按分仓结果装箱并创建货件。

现在很多系统都是用 Pack Later（先分仓再装箱） 的方式来实现自动分仓，这也是新版 API 推荐的流程。

可以的，你在aws队列页面，点击Send and receive messages，就可以看到消息

这里注意，需要提前给你的SQS加一个让SP-API的AWS ID可以写入数据的权限。不然会收不到消息