Selling Partner API

• 1. 概要 （共 232 字）

  Selling Partner API（簡稱 SP-API）是亞馬遜官方提供的基於 REST 架構的程式設計介面，旨在幫助第三方賣家和供應商以程式設計方式訪問其店鋪資料，包括訂單、庫存、付款、廣告等核心業務資訊。該 API 是亞馬遜在 2020 年推出的 MWS（Amazon Marketplace Web Service）繼任者，標誌著亞馬遜對第三方開發者的支援進入了新階段。目前超過四分之三的亞馬遜賣家使用第三方軟體來處理銷售相關事宜，SP-API 已成為電商自動化工具生態系統的技術基礎設施。

• 2. 產品背景 （共 544 字）

  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 的應用註冊即可。

• 3. 產品功能與使用體驗 （共 930 字）

  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），大規模資料處理需要合理設計呼叫策略。

• 4. 定價與商業模式 （共 330 字）

  根據公開資訊，亞馬遜在 2025 年 11 月宣佈了 SP-API 的定價結構，並於 2026 年 2 月 11 日推出高階套餐。定價結構的調整引發瞭解決方案提供商的反饋，他們表示這種費用結構給業務規劃和預測帶來了複雜性。   對於大多數中小賣家而言，透過第三方軟體使用 SP-API 是更經濟的選擇。市場上存在大量基於 SP-API 構建的第三方工具，如 ERP 系統、庫存管理軟體、定價工具等，這些軟體通常採用訂閱制收費模式。賣家只需按月支付軟體費用，即可透過這些工具間接使用 SP-API 的能力，無需自行開發對接。   根據行業調研，超過四分之三的亞馬遜賣家使用第三方軟體來處理銷售相關事宜，包括商品資訊管理、自動定價、配送管理和資料分析等。這說明 SP-API 的價值主要透過第三方軟體生態傳遞給終端賣家。

• 5. 使用者評價 （共 337 字）

  從行業反饋來看，SP-API 在賣家群體中獲得了較高認可。作為亞馬遜官方提供的介面，SP-API 相比第三方資料抓取方式具有明顯優勢：資料來源合法合規，不存在賬號關聯風險；資料準確性高，直接來自亞馬遜官方資料庫；資料時效性好，支援實時推送而非定時拉取。   使用 SP-API 的典型應用場景包括：多店鋪統一管理，賣家可以透過第三方 ERP 同時管理多個亞馬遜店鋪；運營自動化，如自動調價、自動索評、自動發貨通知等；財務對賬自動化，實時同步銷售資料用於財務核算；廣告管理，程式化調整廣告投放策略。   對於負面反饋，主要集中在幾個方面：一是接入門檻較高，需要技術開發能力；二是部分 API 端點的呼叫配額有限制，大賣家可能需要申請更高配額；三是定價結構調整後，第三方軟體提供商的成本可能轉嫁給終端使用者。

• 6. 行業評價 （共 317 字）

  從行業觀察角度來看，SP-API 的推出對亞馬遜賣家服務生態系統產生了深遠影響。它推動了賣家工具從分散化向平臺化演進，催生了一批專業的電商 SaaS 公司。   在技術趨勢方面，隨著 AI 技術的發展，SP-API 正在與生成式 AI 結合。AWS 官方釋出了相關規範性指導，介紹如何利用大語言模型能力增強 SP-API 應用，例如智慧分析訂單資料、生成運營洞察等。2026 年 4 月的最新更新顯示，亞馬遜正在推動 SP-API 與 AI 能力的深度整合。   競爭對手方面，SP-API 的主要替代方案包括其他電商平臺的 API（如 Shopify API、eBay API）以及通用的電商資料聚合服務。然而，對於專注於亞馬遜平臺的賣家和開發者而言，SP-API 是最權威和可靠的資料來源。

• 7. 爭議與風險 （共 297 字）

  在資料合規方面，隨著全球各地資料保護法規（如 GDPR、中國《個人資訊保護法》）的日益嚴格，第三方軟體透過 SP-API 獲取賣家資料的合規性受到關注。開發者和賣家需要確保資料處理流程符合相關法規要求。   在技術風險方面，API 的變更可能影響現有應用的穩定性。雖然亞馬遜提供了版本管理和變更通知機制，但開發者仍需持續關注 API 更新並及時調整程式碼。2022 年 1 月之前的歷史版本變更記錄需參考 GitHub 倉庫中的公告。   在商業風險方面，亞馬遜作為平臺方擁有對 API 的完全控制權。如果未來調整 API 訪問策略或定價，可能對依賴 SP-API 的第三方軟體生態產生重大影響。2025 年底的定價結構調整已經引發了行業討論。

• 8. 適用人群與使用建議 （共 376 字）

  Selling Partner API 適合以下使用者群體：日均訂單量較大的專業賣家，他們需要自動化運營流程以提升效率；電商代運營公司，需要同時管理多個客戶店鋪；電商工具開發者，計劃構建基於亞馬遜資料的 SaaS 產品；需要將亞馬遜資料與內部系統（如 ERP、財務系統）整合的企業。   對於普通個人賣家，直接使用第三方軟體通常是更務實的選擇。市場上已有成熟的工具可選，如賣家精靈、數跨境、易倉等，這些工具已經完成了與 SP-API 的對接，賣家只需按月訂閱即可使用。   對於有技術能力的開發者，建議首先仔細閱讀亞馬遜官方文件，瞭解完整的接入流程和介面規範。AWS 官方部落格在 2024 年 8 月釋出了最新對接流程指南，是非常有價值的參考資料。此外，GitHub 上的 amzn/selling-partner-api-models 倉庫提供了 Swagger 模型檔案，可用於快速生成客戶端程式碼。

• 9. 總結 （共 181 字）

  Selling Partner API 是亞馬遜官方提供的核心資料介面，已成為亞馬遜賣家服務生態系統的技術基礎設施。它為賣家和開發者提供了合法、高效、穩定的程式化訪問能力，是電商自動化和資料分析的重要基石。隨著 AI 技術的融合，SP-API 的應用場景有望進一步擴充套件。對於有技術能力的使用者，建議深入研究官方文件並嘗試對接；對於普通賣家，選擇成熟的第三方工具是更實際的路徑。

暫無深度報告

• 

  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文件是全英文的，看得我頭皮發麻，建議亞馬遜出中文版。

暫無評論