Amazon odkłada opłaty za SP-API. Ulga dla sprzedawców i dostawców narzędzi?
10.03.2026
Amazon nie wycofał się definitywnie z pomysłu pobierania opłat za dostęp do Selling Partner API, ale mamy potwierdzenie: termin wdrożenia został odłożony. Dla wielu sprzedawców to różnica zasadnicza. Nie chodzi bowiem o drobną zmianę techniczną po stronie deweloperów, lecz o temat, który mógł uderzyć bezpośrednio w koszty prowadzenia sprzedaży na Amazon, także przez firmy z Polski. Warto jednak pamiętać, że w świecie Amazon zapowiedzi zmian nie zawsze oznaczają szybkie wdrożenie. Platforma wielokrotnie ogłaszała duże modyfikacje z dużym wyprzedzeniem, które później przez długi czas pozostawały w zawieszeniu lub były przesuwane.
Selling Partner API, w skrócie SP-API, to oficjalny interfejs Amazon, czyli techniczny most między platformą a zewnętrznym oprogramowaniem używanym przez sprzedawców. To właśnie przez niego działają systemy do obsługi zamówień, automatyzacji cen, analityki, reklam, synchronizacji ofert i integracji magazynowych. Dla wielu firm sprzedających na Amazon ten mechanizm jest dziś tak samo podstawowy jak konto sprzedawcy w Seller Central.
Dlatego reakcja rynku na planowane opłaty była tak silna. Gdy Amazon ogłosił jesienią 2025 roku nową strukturę rozliczeń, branża bardzo szybko policzyła, że formalnie rachunek miał trafić do dostawców oprogramowania, ale realnie zostałby przerzucony na sprzedawców. Innymi słowy, koszty nie zatrzymałyby się na poziomie firm technologicznych. Trafiłyby do cenników narzędzi, z których korzystają sprzedawcy w codziennej pracy.
To szczególnie ważne dla polskich firm rozwijających sprzedaż w Niemczech, Francji, Włoszech czy Hiszpanii. W ekspansji zagranicznej na marketplace’ach trudno dziś działać wyłącznie ręcznie. Kto sprzedaje na kilku rynkach, zarządza dużą liczbą ofert albo dynamicznie zmienia ceny, ten zwykle korzysta z całego zestawu narzędzi. I właśnie ten zestaw miałby podrożeć.
O jakie narzędzia chodzi i dlaczego temat nie dotyczy wyłącznie programistów
Dla sprzedawcy najważniejsze jest to, że SP-API nie jest abstrakcyjną infrastrukturą dla branży IT. To zaplecze technologiczne bardzo konkretnych rozwiązań, z którymi pracuje się każdego dnia. Jeśli firma używa systemu ERP, aby automatycznie pobierać zamówienia z Amazon, drukować dokumenty, synchronizować stany i łączyć sprzedaż marketplace z magazynem, to niemal na pewno korzysta pośrednio z SP-API. Jeśli korzysta z narzędzia do automatycznego dostosowywania cen do konkurencji, również. Jeśli analizuje widoczność produktów, pozycje fraz, jakość listingów albo dane o sprzedaży, sytuacja wygląda podobnie.
Na tej liście są zarówno systemy szeroko znane w Polsce, jak JTL, Base czy plentyOne, jak i rozwiązania używane przez sprzedawców rozwijających sprzedaż międzynarodową: Helium10, AMALYZE, integratory marketplace, oprogramowanie do zarządzania kampaniami reklamowymi czy narzędzia agencyjne obsługujące wiele kont jednocześnie. W praktyce mowa więc nie o jednym produkcie, ale o całym ekosystemie technologii wokół Amazon.
To właśnie dlatego temat stał się tak drażliwy. Sprzedawca nie musi znać technicznych szczegółów działania interfejsu, żeby odczuć skutki zmian. Wystarczy, że jego dostawca systemu ERP, narzędzia analitycznego albo oprogramowania do repricingu dostanie nowy rachunek od Amazon. Kolejny krok jest łatwy do przewidzenia: aktualizacja cennika, nowe limity, dopłaty za większy wolumen danych albo podział funkcji na droższe pakiety.
W tym sensie planowane opłaty za SP-API od początku były czymś więcej niż zmianą regulaminową dla partnerów technologicznych Amazon. To była potencjalna podwyżka kosztu infrastruktury sprzedaży na marketplace.
Jak miał wyglądać nowy model opłat i gdzie pojawił się największy problem
Amazon ogłosił 3 listopada 2025 roku nową strukturę opłat dla zewnętrznych dostawców aplikacji korzystających z SP-API. Model zakładał roczną opłatę podstawową w wysokości 1400 dolarów amerykańskich. Następnie, od 30 kwietnia 2026 roku, miały dojść opłaty za wykorzystanie części zapytań do API, liczone według wolumenu. Stawka bazowa wynosiła 0,40 dolara za każde 1000 zapytań ponad przewidziane limity w danym pakiecie.
Amazon przewidział kilka poziomów rozliczeń. W wariancie podstawowym roczna opłata 1400 dolarów obejmowała 2,5 mln tak zwanych rozliczanych zapytań miesięcznie. Wyższe progi były dostępne w płatnych planach miesięcznych. Poziom Pro oznaczał dodatkowo 1000 dolarów miesięcznie i 25 mln zapytań. Poziom Advanced kosztował 5000 dolarów miesięcznie przy limicie 125 mln zapytań. Poziom Plus to 10 000 dolarów miesięcznie i 250 mln zapytań. Amazon zapowiadał też wariant Enterprise ustalany indywidualnie.
Na papierze wyglądało to jak klasyczny model progresywny: mały dostawca płaci mniej, duży więcej. Problem polegał na tym, że w świecie narzędzi marketplace liczba zapytań nie zawsze rośnie liniowo i nie zawsze da się nią łatwo sterować. Wiele aplikacji musi regularnie odpytywać Amazon o dane produktowe, statusy ofert, parametry katalogu, informacje o zamówieniach czy aktualizacje cen. Im więcej kont i ofert obsługuje narzędzie, tym szybciej licznik rośnie.
To właśnie tu pojawił się największy zarzut ze strony rynku. Model był nie tylko kosztowny, ale też trudny do przewidzenia. Dla firm technologicznych to poważny problem, bo bez stabilnej prognozy trudno budować cennik dla klientów, planować marżę i podpisywać umowy na 12 miesięcy lub dłużej. Dla sprzedawcy oznacza to z kolei ryzyko, że dostawca oprogramowania zacznie przerzucać koszty nie od razu, lecz etapami, wraz ze wzrostem zużycia danych.
Dobrym przykładem są narzędzia pracujące na bardzo dużych katalogach produktów. Jeżeli aplikacja ma monitorować zmiany dla milionów ofert albo wielu marek na kilku rynkach, liczba wywołań interfejsu szybko idzie w miliony. W takich warunkach koszt przestaje być symboliczny, a zaczyna być pozycją budżetową, którą trzeba odzyskać z rynku.
Dlaczego sprzedawcy z Polski mieli zapłacić pośrednio więcej
Z perspektywy polskiego sprzedawcy najważniejsze jest nie to, kto formalnie widnieje na fakturze od Amazon, lecz kto ostatecznie pokrywa koszt. W przypadku SP-API odpowiedź od początku była dość oczywista. Dostawca systemu ERP, integratora czy narzędzia analitycznego nie jest organizacją charytatywną. Jeśli jego koszt rośnie o kilka, kilkanaście albo kilkadziesiąt tysięcy dolarów rocznie, musi to uwzględnić w swojej ofercie.
W praktyce skutki mogłyby wyglądać różnie. Jedni podnieśliby abonament. Inni ograniczyliby zakres danych w tańszych planach. Jeszcze inni wprowadziliby rozliczenie zależne od liczby kont, rynków albo wolumenu operacji. Dla sprzedawcy końcowy efekt byłby jednak podobny: wyższy koszt narzędzi potrzebnych do prowadzenia sprzedaży.
I tu pojawia się druga warstwa problemu. Amazon w ostatnim czasie komunikował również działania korzystne dla części sprzedawców, w tym obniżki niektórych opłat handlowych. Gdyby równolegle zdrożała infrastruktura technologiczna, część tej ulgi zostałaby w praktyce zneutralizowana. Sprzedawca być może zapłaciłby mniej w jednym miejscu, ale więcej w trzech innych: za ERP, za automatyzację cen i za analitykę.
Dla firm działających z Polski w modelu cross-border ma to szczególne znaczenie. Sprzedaż zagraniczna zwykle wymaga większej automatyzacji niż sprzedaż krajowa. Dochodzą różne magazyny, więcej rynków, wiele wersji ofert, odmienne stawki podatkowe, obsługa zwrotów, integracja z operatorami logistycznymi i konieczność szybkiego reagowania na zmiany cen konkurencji. Im bardziej zaawansowana operacyjnie sprzedaż, tym większa zależność od narzędzi opartych na SP-API.
W praktyce oznacza to, że najmocniej temat odczułyby niekoniecznie najmniejsze firmy, lecz te, które zbudowały skalę i działają profesjonalnie. A właśnie w tej grupie jest coraz więcej polskich sprzedawców rozwijających biznes na rynkach Europy Zachodniej.
Amazon odłożył termin, ale nie zamknął sprawy
Kluczowa wiadomość z 10 marca 2026 roku jest więc dobra, ale tylko częściowo. Amazon nie skasował całego pomysłu. Firma poinformowała partnerów technologicznych, że odkłada wdrożenie opłat i ma wrócić z nowym harmonogramem jesienią 2026 roku. Powodem ma być złożoność modelu z punktu widzenia planowania biznesowego i prognozowania kosztów przez dostawców rozwiązań.
To ważna korekta komunikatu. Nie ma tu definitywnego odwrotu, tylko przesunięcie terminu. Dla rynku oznacza to kilka dodatkowych miesięcy oddechu, ale nie pełne bezpieczeństwo. Temat monetyzacji dostępu do infrastruktury i danych w Amazon nie znika. Przeciwnie, wszystko wskazuje na to, że platforma nadal szuka modelu, który pozwoli jej pobierać opłaty, a jednocześnie nie wywoła tak silnego sprzeciwu branży.
Dla sprzedawcy z Polski najrozsądniejsze podejście jest dziś dość proste. Nie trzeba reagować nerwowo, ale nie warto też zakładać, że sprawa umarła. Kto korzysta z narzędzi takich jak Helium10, AMALYZE, Base, plentyOne, JTL czy rozwiązań agencyjnych obsługujących Amazon, powinien uważnie obserwować komunikaty swoich dostawców. To właśnie tam najwcześniej będzie widać, czy wraca temat zmian cenników, limitów lub nowych zasad rozliczeń.
W praktyce dobrze też sprawdzić, które procesy w firmie naprawdę wymagają ciągłego pobierania dużej liczby danych z Amazon, a które można uprościć. Nie chodzi o cięcie automatyzacji na zapas, ale o świadomość, gdzie sprzedaż opiera się na ciężkiej integracji i gdzie w przyszłości może pojawić się presja kosztowa.
Jednocześnie sama reakcja Amazon pokazuje, że głos rynku ma znaczenie. Jeżeli dostawcy technologii przekonali platformę do odłożenia terminu, to znaczy, że skala problemu była realna, a nie wyłącznie teoretyczna. To dla sprzedawców dobra wiadomość również dlatego, że ogranicza ryzyko nagłego i trudnego do skalkulowania wzrostu kosztów jeszcze przed sezonem jesienno-zimowym 2026 roku.
Na dziś najuczciwiej powiedzieć tak: Amazon odłożył wdrożenie opłat za SP-API, a więc sprzedawcy i dostawcy oprogramowania zyskali czas. Nie oznacza to jednak końca sporu o to, kto i ile powinien płacić za dostęp do danych oraz funkcji, bez których nowoczesna sprzedaż na marketplace po prostu się nie skaluje.
Branża marketplace zna już zresztą podobne sytuacje. Jednym z przykładów jest zapowiadana zmiana modelu rozliczeń wypłat dla sprzedawców, określana jako DD+7, czyli przesunięcie wypłat o dodatkowe siedem dni po doręczeniu również w starszych kontach Amazon. Zmianę marketplacm ogłosił kilka lat temu, jednak termin wdrożenia był wielokrotnie odkładany i do dziś nie została ona w pełni wprowadzona u wszystkich sprzedawców.
Podobnie wyglądała historia funkcji Shoppable Collections w stronach produktów marek na Amazon. Platforma zapowiedziała jej usunięcie po zakończeniu okresu testowego, jednak w praktyce funkcja zniknęła dopiero kilkanaście dni po deklarowanej dacie zakończenia wersji beta.
Dla sprzedawców to kolejny przykład, że zapowiedzi zmian w Amazon często wywołują w branży nerwowe przygotowania, które później okazują się przedwczesne, ponieważ rzeczywiste wdrożenia bywają przesuwane miesiącami, a czasem nawet latami. Dlatego również w przypadku opłat za SP-API część bardziej doświadczonych obserwatorów rynku zakłada, że temat może jeszcze długo pozostawać w fazie zapowiedzi i konsultacji, zanim pojawi się ostateczny model rozliczeń.
