Alex
Alex
10年跨境老兵(微信:sfgoods),熟悉主流平台(Amazon Ebay 速卖通 Shopee Lazada),欢迎交流~

注册于 1年前

回答
82
文章
5
关注者
2

目前API里确实没有注意到从AWD调拨到FBA的接口,这个我在帮你开Case了,等待亚马逊回复后我会在这里回复你

问题 1:这个报告会展示哪些 listing/FNSKU?

  • 报告类型是 FBA “Manage Inventory Health Report”(接口 reportType = GET_FBA_INVENTORY_PLANNING_DATA)
  • 报告内容包括库存健康/规划层面的指标:7/30/60/90 天销售、入库状态(working/received/shipped)、预计存储与长期仓储费用、滞销/超量库存、系统建议动作等。
  • 覆盖范围主要是 FBA 要约(不是 MFN),按市场(marketplaceId)生成。
  • 实操理解:报告里的每一行基本对应某市场下一条 FBA 要约(MSKU/FNSKU/ASIN 组合),只要这个要约在亚马逊的“库存健康/规划”体系里有产出指标,就会出现在报告里;纯 MFN或已归档的老要约一般不在该报告里。

问题 2:数据变更有没有规律?逻辑大概怎样?

  • 官方并没明确说明报告是“实时”或“每日整点刷新”,所以你观察到“上午有、晚上消失、第二天又回来”的情况是可能的。
  • 指标来源于多个子模块(销售窗口、入库状态、费用估算、超龄/超量等),这些模块可能异步重算、先后完成,从而导致中间时段行或字段暂时缺失。
  • 市场维度影响较大:一些用户反馈,如果同时请求多个 marketplaceId,可能只返回其中一个市场的数据;因此建议按单一市场拉取并比对。
  • 本报告不同于“实时库存”报告——你若想确认“此 FNSKU 现在是否还在库”,应当交叉查询实时库存报告;该规划报告里的“缺行”并不必然意味着库存为零。
这份报告是“周期性汇总 + 异步重算”,报告的行集(哪些 FNSKU)会随着要约状态(在售/抑制/归档)、市场维度、以及内部重算完成状况而波动;不要将它当做“当前库存存在性”的权威来源。

问题 3:报告的建议使用方式

原则:把它当“运营/规划层”的快照,用于判断健康状况,而非当作底账。

  1. 固定时间点拉取,做好日常快照
    每日固定在某个时刻(如每日 08:05)请求并入库,避免因为当天不同时间点数据波动造成误判。
  2. 与实时库存/入库报告交叉验证

    • 使用实时库存报告验证该 FNSKU 是否在库/数量近实时。
    • 将该规划报告中的销售窗口、费用预估、超龄/超量指标,作为“优先级或动作建议”的输入。
    • 如果规划报告提示滞销风险、仓储费上涨、超量,就可以触发价格调整、广告集中、移除或补货策略。
  3. 按市场分别生成与比对
    建议每个 marketplace 单独请求并落库,避免多市场合并导致的数据行缺失或覆盖问题。
  4. 做好“缺行容错”和“延迟回填”机制
    如果某条 FNSKU 在报告中一度缺失,且实时库存显示仍在库/在售,可将该条数据从昨天继承到今天,并标记“待重算”。次日若恢复,则覆盖更新。这样既不会误判,也能保证运营报表稳定。
  5. 结合费用周期做运营动作
    因为报告中含预计存储费/长期仓储费等指标,可以结合库龄、销售窗口,将“超龄/超量”与“次月仓储费暴涨风险”关联,用于驱动调价、促销、移除或补货等运营动作。

对你所观察现象的解释

你看到的情形(T-1 天有 → T+0 8:00 有 → T+0 20:00 无 → T+1 又有):

  • 很可能是报告在当天内部重算过程中,某个模块(比如入库状态、销售窗口、费用预估)尚未完全就绪,导致该条 FNSKU 暂被过滤或延迟更新。
  • 若实时库存报告仍显示该 FNSKU 在库/在售,则可判断为“规划报告暂时缺失”而非真正下架或销毁。
  • 建议你不要将“晚上缺失”视为“库存问题”或“列表消失”,而是视为 “报告侧数据刷新延迟”,按照上述方法做好容错即可。

并非所有字段都在前端展示,也并非所有属性都是必填的。 要按照json schema语法来解析

部分字段是联动的

建议做刊登可以参考赛狐的刊登界面来设计

接口查到发票状态是 PROCESSING,但 VC 里显示 Non-submitted,大概率是发票还没真正进入 AP 系统。

简单说下关键点:

  1. 跟 AP 团队的“连接”
    不需要额外去打通接口。只要账号是 Direct Fulfillment Vendor,并且 SP-API 应用授权了 Direct to Consumer Shipping (Restricted) 权限,就算接通了。
    真要跟 AP 沟通问题,走 Vendor Central → Support → Payments/Invoices 提交工单就行。
  2. PROCESSING 卡住的常见原因

    • 对应订单还没确认发货(必须“已发货”才能开发票)。
    • 发票里的 Bill-to 信息(partyId、公司名、税号、地址)跟亚马逊系统不一致。
    • 发票字段错误,比如 PO 号、金额、币种、付款条款有问题。
    • 调错区域接口或应用权限不对。
  3. 建议的排查顺序

    • GET /vendor/directFulfillment/transactions/.../{transactionId} 查每笔详细状态。
    • 确认订单都已发货。
    • 对照 Bill-to 信息和发票关键字段。
    • 重新提交一张最标准的发票测试。
    • 仍卡住就带上 transactionId 和截图,在 VC 开工单给 AP 团队处理。

json schema里找的
具体,通过getDefinitionsProductType获取schema,然后找到里面的varint_theme(这里拼写可能错误,你搜theme) 就能看到枚举
https://api.sp-api.net/zh/api-308929921
image.png

官方 SDK 并不强制你用 refresh_token 去换 token——如果你手里已经有一个仍然有效的 LWA access_token,只要把它放进请求头 x-amz-access-token 即可;这是官方文档现在推荐的做法(最近文档里甚至给了“不带签名、只带 header”的示例)

下面给你两条常见路径,按需选:

方案 A:直接用 HTTP(最省事)

curl "https://sellingpartnerapi-na.amazon.com/sellers/v1/marketplaceParticipations" \
  -H "x-amz-access-token: Atza|<你的token>" \
  -H "user-agent: MyApp/1.0 (Language=CLI)" \
  -H "x-amz-date: 20250101T120000Z"
官方“Connect to the SP-API”页面明确列出要加的头,示例也展示了不带签名、只带 x-amz-access-token 的请求。注意 token 有效期约 1 小时。

方案 B:仍然用官方 SDK,但给底层 HTTP 客户端统一加默认头

不同语言的官方 SDK 都是基于 OpenAPI 生成的客户端,底层一般都有“默认请求头/拦截器”的注入点。思路是:x-amz-access-token 当成普通自定义头塞进去即可。

Java(OkHttp 拦截器)

import okhttp3.*;
import com.amazon.spapi.client.*;   // 你的生成包名可能不同
import com.amazon.spapi.api.SellersApi;

String accessToken = "Atza|...";
ApiClient client = new ApiClient();
OkHttpClient http = client.getHttpClient().newBuilder()
  .addInterceptor(chain -> {
    Request req = chain.request().newBuilder()
      .header("x-amz-access-token", accessToken)
      .header("user-agent", "MyApp/1.0 (Language=Java)")
      .build();
    return chain.proceed(req);
  }).build();
client.setHttpClient(http);
client.setBasePath("https://sellingpartnerapi-na.amazon.com");

SellersApi api = new SellersApi(client);
var res = api.getMarketplaceParticipations();
官方 Java 教程默认演示用 refresh_token 让 SDK 自己换 token;但如果你已持有 access_token,也可以像上面这样直接注入 header 使用。(developer-docs.amazon.com)

C#(RestSharp/Configuration 默认头)

using Amazon.SellingPartnerAPIAA.Client; // 你的命名空间可能不同
using Amazon.SellingPartnerAPIAA.Api;

var cfg = new Configuration { BasePath = "https://sellingpartnerapi-na.amazon.com" };
cfg.AddDefaultHeader("x-amz-access-token", "Atza|...");
cfg.UserAgent = "MyApp/1.0 (Language=C#)";

var api = new SellersApi(cfg);
var res = api.GetMarketplaceParticipations();
C# 的生成客户端通常支持在 Configuration/RestClient 上添加默认头;把 token 放进 x-amz-access-token 即可。官方“生产调用”页面也列出必需的几个头部。

Python(ApiClient 默认头)

from spapi_client import Configuration, ApiClient, SellersApi  # 你的包名/类名可能不同

cfg = Configuration()
cfg.host = "https://sellingpartnerapi-na.amazon.com"
api_client = ApiClient(cfg)
api_client.set_default_header("x-amz-access-token", "Atza|...")
api_client.set_default_header("user-agent", "MyApp/1.0 (Language=Python)")

api = SellersApi(api_client)
res = api.get_marketplace_participations()
Python 的生成客户端一般提供 set_default_header 或可直接修改 default_headers 添加自定义头。

Node/JS(直接 fetch;或在 SDK 的请求钩子里加头)

const r = await fetch(
  "https://sellingpartnerapi-na.amazon.com/sellers/v1/marketplaceParticipations",
  {
    headers: {
      "x-amz-access-token": "Atza|...",
      "user-agent": "MyApp/1.0 (Language=Node)",
      "x-amz-date": "20250101T120000Z",
    },
  }
);
const data = await r.json();
官方文档与 Postman 教程都明确需要把 access_tokenx-amz-access-token 传入(有时文档里也能看到旧写法 x-amzn-access-token,本质一致)。

重要注意

  • RDT 场景:访问带 PII 的“受限接口”时,不用 LWA access_token,而是先用 Tokens API 换 RDT,然后仍然把 RDT 放在 x-amz-access-token 头里。
  • 有效期:LWA access_token 通常有效 1 小时,过期会 401;如果你有 refresh_token,让 SDK 代换会更省心。

使用SP-API刊登的,主要关注商品前台链接是否正常。以及 issue里是否有错误即可

如果前台链接可以购买,可以搜索,拿这些就可以忽略

使用getListingItem接口看看
https://api.sp-api.net/zh/api-308930030
image.png

技术可以实现的,大概涉及到下面的相关接口
Amazon Shipping API v2
Fulfillment Outbound API v2020-07-01
Orders API v0
Notifications API

emm,这个你可以发个帖子,报个价,或者在这里报价格,然后看看有哪个人愿意搞一下

绩效报告里有GET_V2_SELLER_PERFORMANCE_REPORT
https://developer-docs.amazon.com/sp-api/docs/report-type-values-performance

accountStatuses
marketplaceId
status
performanceMetrics
lateShipmentRate
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
orderCount
lateShipmentCount
rate
invoiceDefectRate
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
invoiceDefect
status
count
missingInvoice
status
count
lateInvoice
status
count
orderCount
rate
orderDefectRate
afn
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
orderWithDefects
status
count
claims
status
count
chargebacks
status
count
negativeFeedback
status
count
negativeFeedback
status
count
orderCount
rate
fulfillmentType
mfn
orderWithDefects
status
count
claims
status
count
chargebacks
status
count
negativeFeedback
status
count
negativeFeedback
status
count
orderCount
rate
fulfillmentType
onTimeDeliveryRate
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
shipmentCountWithValidTracking
onTimeDeliveryCount
rate
unitOnTimeDeliveryRate
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
unitOnTimeDeliveryCount
totalUnitCount
rate
validTrackingRate
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
shipmentCount
validTrackingCount
rate
preFulfillmentCancellationRate
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
orderCount
cancellationCount
rate
warningStates
accountHealthRating
ahrStatus
reportingDateRange
reportingDateFrom
reportingDateTo
listingPolicyViolations
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
productAuthenticityCustomerComplaints
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
productConditionCustomerComplaints
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
productSafetyCustomerComplaints
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
receivedIntellectualPropertyComplaints
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
restrictedProductPolicyViolations
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
suspectedIntellectualPropertyViolations
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
foodAndProductSafetyIssues
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
customerProductReviewsPolicyViolations
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount
otherPolicyViolations
reportingDateRange
reportingDateFrom
reportingDateTo
status
targetValue
targetCondition
defectsCount

涉及到评论的接口,只有这几个,参考文档地址:https://api.sp-api.net/zh/api-346686042

  • 商品:getItemReviewTopics
  • 分类节点:getItemBrowseNode

- 评论趋势 getItemReviewTrends 获取某个商品过去六个月的正面和负面评价趋势。
- ...等等

不过上面的并不是产品的所有评论,而是亚马逊分析之后的评论总结

image.png

这个是根据SP-API的邀请评论接口做的功能,createProductReviewAndSellerFeedbackSolicitation
接口地址:https://api.sp-api.net/zh/api-308930157
image.png

另外还有一个获取功能getSolicitationActionsForOrder
https://api.sp-api.net/zh/api-308930156

现在还不用,直接下一步,填写企业信息,联系人信息,然后上传证件就可以了。
他们会根据填写到资料看看是否需要提交一份视频

recommended_browse_nodes,你在schema搜一下这个属性相关的看看传了没

发布
问题

公众
平台

最新资讯发布