Selling Partner API

亚马逊官方提供的基于 REST 架构的编程接口,帮助第三方卖家和供应商以编程方式访问店铺数据

In-depth Report

  • Selling Partner API(简称 SP-API)是亚马逊官方提供的基于 REST 架构的编程接口,旨在帮助第三方卖家和供应商以编程方式访问其店铺数据,包括订单、库存、付款、广告等核心业务信息。该 API 是亚马逊在 2020 年推出的 MWS(Amazon Marketplace Web Service)继任者,标志着亚马逊对第三方开发者的支持进入了新阶段。目前超过四分之三的亚马逊卖家使用第三方软件来处理销售相关事宜,SP-API 已成为电商自动化工具生态系统的技术基础设施。

  • Selling Partner API 由亚马逊官方开发并维护,属于亚马逊开发者服务的一部分。该 API 的推出是为了替代此前被广泛使用的 MWS(Marketplace Web Service),后者已于 2024 年 9 月 30 日正式停用。SP-API 基于现代 RESTful 设计原则构建,支持 JSON 格式的数据交换,并提供了 SDK 套件供开发者使用,包括 C#、Java 等主流编程语言的客户端库。 从市场定位来看,SP-API 主要面向三类用户群体:首先是亚马逊第三方卖家,他们需要自动化管理店铺运营流程;其次是亚马逊供应商(Vendor),用于采购订单和库存管理;第三是解决方案提供商(Solution Providers),即围绕亚马逊卖家需求开发 ERP、工具软件的第三方技术公司。亚马逊官方建立了卖家平台合作伙伴网络(Amazon Partner Network),允许经过认证的合作伙伴发布利用 SP-API 构建的应用程序。 在技术架构层面,SP-API 采用了 OAuth 2.0 授权模型,开发者需要先注册 AWS 账户、申请开发者资料,然后在 Seller Central 创建应用程序并获取授权。整个接入流程在 2024 年经过优化,新注册的开发人员无需再单独申请 AWS 开发者账号,只需完成Seller Central 的应用注册即可。

  • SP-API 提供了覆盖亚马逊卖家业务全流程的接口能力。根据官方文档,该 API 包含数十个细分端点,主要功能模块包括以下几个维度。 在订单管理方面,Orders API 允许开发者获取订单列表、订单详情、订单商品信息以及订单地址数据,支持按时间范围、订单状态等条件进行筛选。Shipment API 则用于管理货件信息,包括创建货件、查询货件状态等。对于使用亚马逊物流(FBA)的卖家,Inventory API 提供了实时库存查询和库存管理能力。 商品目录管理方面,Catalog Items API 和 Listings API 分别用于查询商品目录信息和管理商品列表。Product Pricing API 则提供产品定价查询功能,支持竞争对手价格监控和动态定价策略的实施。 报表和数据获取是 SP-API 的核心能力之一。Reports API 支持生成多种类型的报表,包括库存报表、销售报表、广告报表、财务对账报表等,开发者可以定时获取报表数据用于数据分析。Feeds API 则用于批量上传数据,如批量更新商品信息、价格库存等。 财务对账方面,Finances API 提供详细的财务数据,包括销售收入、平台费用、广告支出、退款金额等,为卖家的财务核算提供数据支撑。此外,Shipment Invoicing API 用于处理发货发票,Messaging API 支持向买家发送通知消息。 对于品牌卖家,A+ Content API 允许通过程序化方式管理品牌内容,提升商品详情页的展示效果。Easy Ship API 和 Merchant Fulfillment API 则分别支持 Easy Ship 配送服务和卖家自配送场景。 从使用体验角度,SP-API 相比此前的 MWS 实现了显著升级。首先是数据时效性,订单等关键数据采用推送机制而非定时拉取,确保了信息的实时性。其次是接口稳定性,SP-API 提供了完善的版本管理和变更通知机制。再次是安全性,OAuth 2.0 授权模式相比旧的 MWS 密钥认证更加安全灵活。 然而,SP-API 的使用也存在一定门槛。开发者需要具备编程能力,且对接流程涉及多个环节,包括 AWS 注册、开发者申请、应用创建、权限获取等。此外,不同 API 端点有不同的使用限制(Rate Limit),大规模数据处理需要合理设计调用策略。

  • 根据公开信息,亚马逊在 2025 年 11 月宣布了 SP-API 的定价结构,并于 2026 年 2 月 11 日推出高级套餐。定价结构的调整引发了解决方案提供商的反馈,他们表示这种费用结构给业务规划和预测带来了复杂性。 对于大多数中小卖家而言,通过第三方软件使用 SP-API 是更经济的选择。市场上存在大量基于 SP-API 构建的第三方工具,如 ERP 系统、库存管理软件、定价工具等,这些软件通常采用订阅制收费模式。卖家只需按月支付软件费用,即可通过这些工具间接使用 SP-API 的能力,无需自行开发对接。 根据行业调研,超过四分之三的亚马逊卖家使用第三方软件来处理销售相关事宜,包括商品信息管理、自动定价、配送管理和数据分析等。这说明 SP-API 的价值主要通过第三方软件生态传递给终端卖家。

  • 从行业反馈来看,SP-API 在卖家群体中获得了较高认可。作为亚马逊官方提供的接口,SP-API 相比第三方数据抓取方式具有明显优势:数据来源合法合规,不存在账号关联风险;数据准确性高,直接来自亚马逊官方数据库;数据时效性好,支持实时推送而非定时拉取。 使用 SP-API 的典型应用场景包括:多店铺统一管理,卖家可以通过第三方 ERP 同时管理多个亚马逊店铺;运营自动化,如自动调价、自动索评、自动发货通知等;财务对账自动化,实时同步销售数据用于财务核算;广告管理,程序化调整广告投放策略。 对于负面反馈,主要集中在几个方面:一是接入门槛较高,需要技术开发能力;二是部分 API 端点的调用配额有限制,大卖家可能需要申请更高配额;三是定价结构调整后,第三方软件提供商的成本可能转嫁给终端用户。

  • 从行业观察角度来看,SP-API 的推出对亚马逊卖家服务生态系统产生了深远影响。它推动了卖家工具从分散化向平台化演进,催生了一批专业的电商 SaaS 公司。 在技术趋势方面,随着 AI 技术的发展,SP-API 正在与生成式 AI 结合。AWS 官方发布了相关规范性指导,介绍如何利用大语言模型能力增强 SP-API 应用,例如智能分析订单数据、生成运营洞察等。2026 年 4 月的最新更新显示,亚马逊正在推动 SP-API 与 AI 能力的深度整合。 竞争对手方面,SP-API 的主要替代方案包括其他电商平台的 API(如 Shopify API、eBay API)以及通用的电商数据聚合服务。然而,对于专注于亚马逊平台的卖家和开发者而言,SP-API 是最权威和可靠的数据来源。

  • 在数据合规方面,随着全球各地数据保护法规(如 GDPR、中国《个人信息保护法》)的日益严格,第三方软件通过 SP-API 获取卖家数据的合规性受到关注。开发者和卖家需要确保数据处理流程符合相关法规要求。 在技术风险方面,API 的变更可能影响现有应用的稳定性。虽然亚马逊提供了版本管理和变更通知机制,但开发者仍需持续关注 API 更新并及时调整代码。2022 年 1 月之前的历史版本变更记录需参考 GitHub 仓库中的公告。 在商业风险方面,亚马逊作为平台方拥有对 API 的完全控制权。如果未来调整 API 访问策略或定价,可能对依赖 SP-API 的第三方软件生态产生重大影响。2025 年底的定价结构调整已经引发了行业讨论。

  • Selling Partner API 适合以下用户群体:日均订单量较大的专业卖家,他们需要自动化运营流程以提升效率;电商代运营公司,需要同时管理多个客户店铺;电商工具开发者,计划构建基于亚马逊数据的 SaaS 产品;需要将亚马逊数据与内部系统(如 ERP、财务系统)集成的企业。 对于普通个人卖家,直接使用第三方软件通常是更务实的选择。市场上已有成熟的工具可选,如卖家精灵、数跨境、易仓等,这些工具已经完成了与 SP-API 的对接,卖家只需按月订阅即可使用。 对于有技术能力的开发者,建议首先仔细阅读亚马逊官方文档,了解完整的接入流程和接口规范。AWS 官方博客在 2024 年 8 月发布了最新对接流程指南,是非常有价值的参考资料。此外,GitHub 上的 amzn/selling-partner-api-models 仓库提供了 Swagger 模型文件,可用于快速生成客户端代码。

  • Selling Partner API 是亚马逊官方提供的核心数据接口,已成为亚马逊卖家服务生态系统的技术基础设施。它为卖家和开发者提供了合法、高效、稳定的程序化访问能力,是电商自动化和数据分析的重要基石。随着 AI 技术的融合,SP-API 的应用场景有望进一步扩展。对于有技术能力的用户,建议深入研究官方文档并尝试对接;对于普通卖家,选择成熟的第三方工具是更实际的路径。

User Reviews

  • 头像
    THarris_88
    SP-API 的那个 AWS Signature Version 4 签名算法真的太复杂了,每次请求都要算一遍,第一次搞的时候各种签名不匹配,debug 了三天三夜。

  • 头像
    MirandaHughes
    Access Token 每个小时过期一次,忘了加自动刷新逻辑就得不停手动重连,Refresh Token 虽然一年有效但丢了只能重新授权。

  • 头像
    春雨280
    速率限制真的是温柔一刀,每个 API 配额和恢复速率都不一样,不及时做指数退避的话业务高峰期数据同步直接就崩了,得盯着 CloudWatch 看限流次数。

  • 头像
    SandyFreier
    回调 URL 必须配 HTTPS 否则亚马逊不认,而且域名还得提前备案,这个坑很多人第一轮就被绊住了。

  • 头像
    汪月睿
    做了六个月的 SP-API 开发,对500个SKU以下的卖家来说性价比真的不高,你投入的时间和开发成本够你买好几年第三方工具了,不要盲目自建。

  • 头像
    TAlar777
    如果是中小卖家,直接接 SP-API 其实不划算,开发成本太高了,请一个开发搞这套没个三四个月下不来,用现成的 SaaS 工具反而更省心省钱。

  • 头像
    Julie_Wood_20225
    SP-API 的 getCompetitivePricing 接口限流太狠了,每秒才 0.5 个请求,监控一万个 SKU 的竞品价格根本跑不过来,全部跑完要22小时以上,想做实时定价根本不可能。

  • 头像
    Daniel_Martin_99
    Feeds API 批量上传产品数据很方便,以前手动上传经常出编码问题和格式错误,现在全自动化了省心很多。

  • 头像
    TRobinsonK
    SP-API 的 Notifications API 确实实用,订单来了实时通知,不用再轮询了,API 调用量也省了不少,推荐每个接入 SP-API 的团队都用上。

  • 头像
    Ronald_Thompson_Plus
    为了拿到 SP-API 的正式授权,我们不得不把整个平台从 DigitalOcean 迁移到了 AWS,花了两周重构了 CI/CD、做了环境分离和全套监控系统。虽然过程痛苦,但亚马逊的安全审核确实能倒逼你把基础架构做好,后面运维反而轻松了很多。

  • 头像
    d1j6o
    最烦的是 SP-API 安全审核第一次被拒后没有任何具体反馈,你根本不知道到底哪里没过关,只能全面排查,感觉像是盲人摸象。

  • 头像
    realRadoslavaGerasim'yuk
    如果你做亚马逊 ERP 或者 WMS,SP-API 基本绕不开,订单、库存、财务数据全靠它来拉,接上之后整个运营效率能提升一大截,之前靠人工下载报表的日子一去不复返了。

  • 头像
    lazycat197
    说真的,SP-API 的文档质量比以前 MWS 好太多了,至少是标准的 REST 格式,Swagger 模型也能直接生成 SDK,不用像以前那样自己猜接口格式和参数。

  • 头像
    HHoward_2023
    SP-API 的 OAuth 授权流程整体设计得还算安全,但学习曲线确实陡峭,JWT 签名、STS 临时凭证这些概念对普通卖家来说门槛太高了,没有专职开发根本搞不定。

  • 头像
    Madison.Alvarez168
    沙箱环境对刚接触 SP-API 的团队很友好,可以在不影响真实数据的情况下测试 API 调用,不过要注意某些接口的沙箱行为跟生产环境不完全一致,上线前还是要做生产验证。

  • 头像
    Roy.GutierrezK
    Data Kiosk API 这个功能不错,可以用自定义 SQL 查销售数据,灵活度比预定义报表高多了,唯一的问题是设计查询需要一定的 SQL 功底,不是所有人都能上手就用。

  • 头像
    苏静妍
    SP-API 帮我们实现了多店铺统一管理,原来北美、欧洲、日本三个站点要分别登录 Seller Central 手动操作,现在全部在一个系统里搞定,每天早上看一眼概览就行。

  • 头像
    LisaPowell
    FBA 发货通过 SP-API 接入后整个物流流程都自动化了,订单进来自动推送仓库、生成面单、更新追踪号,拣货到出库的时间缩短了将近一半。

  • 头像
    Alexander_Green_75
    亚马逊之前推 SP-API 的时候要求所有第三方工具必须在截止日期前完成迁移,当时真是手忙脚乱,不过现在看来确实是好事,接口质量和安全性都上了一个台阶。

  • 头像
    ChainMjx
    用了 SP-API 接广告管理工具之后,广告出价调整从人工每天半小时变成了系统自动根据 ACOS 动态调整,ROAS 提升了20%左右,这效果还是挺明显的。

  • 头像
    DKelly_2021
    SP-API 对数据处理的安全性要求很高,加密方案、访问控制、审计日志都得有,不过换个角度看,这些规范倒逼我们把数据安全体系建起来了,对通过 ISO 认证也有帮助。

  • 头像
    GEjam
    电商代运营公司现在基本都用 SP-API 接客户店铺了,自动化程度越高利润空间也越大,靠人工操作的时代已经过去了,不会接 API 的代运营以后很难接到大客户。

  • 头像
    TheresaMendoza1683
    亚马逊终于取消 SP-API 的年费了,每年1400刀的订阅费之前压得小开发者喘不过气来,还好最后撤回了。

  • 头像
    CLbau
    之前部分工具商以 SP-API 收费为由涨了5-15%的价,结果费取消了价格却没降回去,做卖家的真该去把这几月的账单翻出来对对,该要求退差价就要求退差价。

  • 头像
    KAtur
    亚马逊开始收费了!4月30日起API调用要花钱,成本一下子上来了。

  • 头像
    BrianYoung
    用了半年SP-API,比之前的MWS稳定多了,数据实时性也更好,就是接入门槛有点高,需要技术背景。

  • 头像
    MJenkins_2020
    刚对接完,流程确实比想象中复杂,光是OAuth授权就搞了一整天,不过文档写得挺详细的。

  • 头像
    silverfrog759
    强烈推荐!对接后订单管理自动化,效率提升明显,每天能省2-3小时手动操作时间。

  • 头像
    DanielLopez_Pro
    用SP-API做了多店铺管理,同时控制5个亚马逊店铺毫无压力,数据同步很及时。

  • 头像
    x890p
    API文档是全英文的,看得我头皮发麻,建议亚马逊出中文版。