Automatyzacja sprzedaży internetowej: Vinted, OLX i własny sklep (n8n) 

Sprzedajesz w trzech miejscach naraz: na marketplace, na portalu ogłoszeniowym i we własnym sklepie. Każde z tych miejsc ma własną logikę, własne API albo jego brak i własne problemy. Efekt jest jeden - ceny, stany magazynowe i zamówienia rozjeżdżają się w trzech miejscach, a Ty gasz pożar ręcznie. Artykuł pokazuje, co z tego da się naprawdę zautomatyzować, a gdzie granica leży wcześniej, niż wydasz na to pieniądze.

Trzy kanały sprzedaży, trzy różne problemy

Vinted, OLX i własny sklep to nie trzy warianty jednego procesu. To trzy różne modele, z których każdy ma inne ograniczenia techniczne i inne koszty ukryte. Zanim napiszesz pierwszy przepływ w n8n, warto wiedzieć, czym się różnią - bo to decyduje o tym, ile pracy faktycznie da się odzyskać.

Zacznę od najprostszego faktu, który najczęściej psuje plany: nie wszystkie trzy kanały dają Ci API. Jedno ma je, drugie ma je z zastrzeżeniami, trzeciego nie ma w ogóle. Ta asymetria wygląda drobno na etapie pomysłu i robi się bolesna przy pierwszym wdrożeniu.

Vinted: sprzedajesz przez aplikację, a nie przez API

Vinted to platforma sprzedaży peer-to-peer założona w 2008 roku w Wilnie. Działa w ponad 26 rynkach europejskich, a w 2025 roku obieg towaru na platformie doszedł do 10,8 mld euro, przy przychodzie 1,1 mld euro i zysku netto 62 mln euro. W Wielkiej Brytanii liczba użytkowników wzrosła z 1,2 mln w 2021 roku do 8 mln w 2023 roku. Skala jest realna.

Model sprzedaży jest prosty i opłaca się sprzedawcy. Platforma nie pobiera prowizji od sprzedaży - sprzedawca zostawia sobie całą kwotę, a koszt wysyłki ponosi kupujący, który dostaje przedpłaconą etykietę i wybiera między punktem nadania a odbiorem z domu. Cenę ustala sprzedawca. To uczciwe warunki i właśnie dlatego Vinted ma ruch.

Natomiast z punktu widzenia automatyzacji wszystko działa inaczej. Vinted nie udostępnia publicznego API dla sprzedawców. Przeszedłem przez materiały źródłowe przygotowane do tego artykułu i nie znalazłem tam ani jednego śladu takiego interfejsu - żadnej dokumentacji, żadnego endpointu, żadnej wzmianki o dostępie dla sprzedawców. To nie jest brak mojej pomysłowości, tylko brak takiego produktu po stronie platformy.

Praktyczna konsekwencja jest taka, że nie napiszesz przepływu, który sam wystawia ogłoszenia na Vinted masowo. Nie dlatego, że jest to trudne technicznie, tylko dlatego, że nie ma przez co się połączyć. Każdy, kto obiecuje Ci taką automatyzację za pieniądze, obiecuje coś, czego platforma nie umożliwia.

Co da się zautomatyzować przy Vinted

To, co da się zrobić, dotyczy strony sprzedawcy, a nie samego procesu wystawiania. I to często wystarczy, bo właśnie po stronie sprzedawcy ginie najwięcej czasu.

Po pierwsze, przygotowanie danych wejściowych. Zdjęcia, opisy, ceny i rozmiary wprowadzasz ręcznie, ale sam tekst opisu możesz przygotować wcześniej w arkuszu albo w rekordzie bazy, a następnie kopiować. To nie jest automatyzacja Vinteda - to jest odzyskanie czasu z Twojej strony.

Po drugie, raportowanie. Sprzedajesz na kilku kontach albo w kilku kategoriach, robisz to przez tygodnie i nikt nie wie, ile faktycznie zarobiłeś. Zbieranie tych danych w jeden arkusz zawsze w jednej formie jest zadaniem, które da się zamknąć przepływem, nawet bez dostępu do platformy.

Po trzecie, powiadomienia o tym, co się dzieje wokół sprzedaży - odpowiedzi kupujących, prośby o obniżkę, przypomnienie o nadaniu paczki. To jest strona, na której zysk z automatyzacji jest największy, a ryzyko najmniejsze, bo nie dotykasz regulaminu platformy.

I jeszcze jedno, o czym mówię każdemu, kto zaczyna: przy Vinted nie ma sensu budować czegoś, co skaluje sprzedaż za Ciebie. Jest sens zbudować coś, co nie pozwala Ci zapomnieć o tym, co się dzieje na Twoim koncie, gdy prowadzisz jednocześnie sklep i dwie inne kanały.

OLX: API istnieje, ale dwa z czterech kierunków są wyłączone z rozwoju

OLX jest pod tym względem w innym miejscu niż Vinted. Grupa OLX ma własne centrum deweloperskie i oferuje tam cztery API. Lista obejmuje nieruchomości (Otodom, Storia, Imovirtual), części samochodowe (Otomoto, Autovit, OLX.pl i OLX.ro), OLX Europe oraz OLX Motors (Otomoto, Autovit, Standvirtual).

Cztery API, cztery różne statusy. Dla nieruchomości i części samochodowych status to Active, dla OLX Europe i Motors - Stable. Te oznaczenia wyglądają na liście podobnie, ale obok nich są kolumny Technical Support i Maintenance. Dla OLX Europe i dla Motors obie mają wartość NO, a opis mówi wprost: „No new developments or maintenance is being provided”.

To jest najważniejsze zdanie w całej historii integracji z OLX. „Stable” znaczy tu dokładnie tyle, że interfejs działa dziś, ale nikt go już nie rozwija. Nie dostaniesz nowych funkcji, nie dostaniesz poprawek, a w razie problemu nie ma do kogo zadzwonić. Budowanie na tym długoterminowego procesu to ryzyko, które musisz wziąć na siebie świadomie.

Samo centrum deweloperskie przyznaje też drugą rzecz, która oszczędza godziny na etapie planowania: „Unfortunately, we could not yet provide all Technical Documentation and Application Managers in one simple Developer Center”. Dokumentacja jest rozproszona. Dodatkowo część funkcji po prostu nie działa na wszystkich marketplace'ach w grupie - „Some features still need to be available in some of the Marketplaces”. Zakładaj więc, że integracja napisana pod jeden portal nie przeniesie się bez poprawek na inny.

Co do samego procesu biznesowego, na OLX obowiązuje jedna liczba, która determinuje większość kłopotów: ogłoszenia wygasają co 30 dni. Przy katalogu liczonym w dziesiątkach sztuk to jest regularna, powtarzalna praca - dokładnie ten typ zadania, który warto zautomatyzować. Przy okazji, gdy akcję tę wykonuje się ręcznie, powstaje typowy błąd: sprzedaż przez kilka kanałów naraz prowadzi do sytuacji, w której ten sam towar jest wystawiony w trzech miejscach, a w dwóch z nich go już nie ma.

Własny sklep: najwięcej automatyzacji i największy koszt utrzymania

Własny sklep to najbardziej automatyzowalny z trzech kanałów, bo to Twoja infrastruktura i masz do niej pełny dostęp. Przy PrestaShop integracja zaczyna się od rzeczy bardzo prostej: wchodzisz do panelu, generujesz klucz Webservice i nadajesz mu odpowiednie uprawnienia. Ten klucz jest Twoim biletem do API sklepu - przez niego system zewnętrzny czyta katalog, stany i zamówienia.

Tu też jest jednak rachunek, którego nie widać na starcie. Każda wtyczka do PrestaShop to osobny moduł od innego wydawcy, kosztujący od 100 do 400 zł rocznie. Przy pięciu takich modułach to jest 500 do 2000 zł rocznie, zanim doliczysz osobne połączenia z marketplaceami, fakturowaniem, kurierami i magazynem. Każde z tych połączeń ma własny abonament i własne ryzyko, że po aktualizacji coś przestanie działać.

Druga rzecz, o której mówię w każdym wdrożeniu: sam PrestaShop nie prowadzi księgowości. Fakturę wystawiasz gdzie indziej. To znaczy, że sprzedaż w sklepie sama z siebie nie domyka procesu i zawsze zostawia za sobą ręczny krok na końcu - ten krok kosztuje tyle, ile trwa wystawienie dokumentu i jego wysłanie klientowi.

Jest też pułapka, o której rzadko mówi się głośno: najlepiej sprzedający się produkt wcale nie musi najwięcej zarabiać. Prowizje i zwroty potrafią zjeść zysk. Automatyzacja tego nie poprawi, ale przy okazji budowy raportów zobaczysz to szybciej niż dotąd, co jest powodem, żeby ją i tak zrobić.

n8n jako spoiwo między tymi kanałami

n8n to narzędzie, w którym buduje się przepływy łączące te systemy. Katalog integracji obejmuje ponad 2279 pozycji, a do tego ponad 10 tysięcy gotowych szablonów przepływów od społeczności. W praktyce oznacza to, że skoro Twój system potrafi wykonywać żądania HTTP, da się go podłączyć.

Każdy przepływ zaczyna się od wyzwalacza - czyli zdarzenia, które go uruchamia. Nowe zamówienie w sklepie, nowe ogłoszenie, nowa wiadomość. W edytorze wygląda to jak klocki połączone strzałkami: dokładasz węzeł wyzwalający, za nim węzeł, który wykonuje żądanie HTTP, i na końcu węzeł, który zapisuje wynik. Programowanie nie jest tu konieczne, a całość buduje się w przeglądarce.

Procedura jest zawsze ta sama i warto ją znać na pamięć, bo stosuje się ją do każdego systemu. Po zalogowaniu tworzysz nowy przepływ i wybierasz węzeł startowy. Ustawiasz wyzwalacz na konkretne zdarzenie. Dodajesz węzeł HTTP Request i ustawiasz metodę na POST, a w adresie podajesz endpoint usługi. Kluczowe są nagłówki - tam trafia identyfikacja konta, np. nagłówek z ID konta i nagłówek z kodem dostępu, obok standardowego Content-Type ustawionego na application/json. W treści wybierasz surowy JSON i mapujesz pola na dane z poprzedniego węzła przez wyrażenia w nawiasach wstrząsowych. Uruchamiasz pojedynczy węzeł przyciskiem testowym, sprawdzasz odpowiedź po stronie odbiorcy i dopiero wtedy aktywujesz przepływ.

Tu jest pułapka, o którą potyka się każdy, kto zaczyna: przepływ istnieje, ale nic nie robi, dopóki go nie aktywujesz. Przycisk uruchomienia jednorazowego testu nie uruchamia go w tle. Druga pułapka jest bliższa: jeśli API, z którym rozmawiasz, chwilowo padnie, przepływ się posypie. Dlatego obsługę błędów ustawia się od początku, żeby dostać powiadomienie, zamiast odkrywać problem tydzień później po cichej awarii.

Klucze dostępu trzymaj w zmiennych środowiskowych, a nie we węzłach. Jeden klucz wtedy działa we wszystkich przepływach i zmieniasz go w jednym miejscu, zamiast w kilkunastu węzłach naraz. Przy testowaniu klikaj Test po każdym dodanym węźle - szukanie błędu w przepływie z trzema węzłami zajmuje chwilę, w przepływie z dwudziestoma zajmuje wieczór.

Gotowy moduł czy własny przepływ

Skoro przy OLX istnieje gotowe narzędzie z integracją, słuszne pytanie brzmi: po co budować własne? Bo obie ścieżki dają inne koszty i inną kontrolę.

Gotowe narzędzia sprzedawane są jako abonament. Przykładowo jedno z nich oferuje plan bezpłatny do 100 zamówień miesięcznie i do 1000 produktów w katalogu, a integracje są w cenie subskrypcji. Taka firma deklaruje integrację z ponad 1700 platformami, kurierami i hurtowniami, z których 3900 firm korzysta do zarządzania ogłoszeniami na OLX.

Własny przepływ w n8n kosztuje inaczej. Wersja self-hosted jest darmowa i - według materiałów, na których opieram to porównanie - bez limitu wykonań, bo płacisz tylko za serwer, czyli realnie 5 do 20 euro miesięcznie za VPS. Plan chmurowy wchodzi około 24 euro miesięcznie za 2500 wykonań, czyli 288 euro rocznie. Sama liczba integracji n8n w różnych zestawieniach rozjeżdża się wyraźnie: n8n.io podaje 2279, a polskie poradniki około 1100. To rozjazd liczenia, nie zmiana produktu - nie klej tych dwóch liczb w jedną.

Wybór sprowadza się do pytania, czy chcesz płacić za dostęp do cudzych integracji, czy za własny przepływ, który działa na Twoich warunkach. Pierwsza opcja jest szybsza na start. Druga jest tańsza w skali i daje kontrolę nad logiką, której gotowy moduł nigdy nie dopasuje dokładnie do Twojego procesu.

Jeżeli wybierasz n8n, warto porównać je jeszcze z dwiema innymi platformami automatyzacji - różnice w cenie i w podejściu do modeli językowych opisuję osobno w tekście o n8n, Make i Zapier.

Co realnie odzyskujesz, a co zostaje przy Tobie

Warto uczciwie oddzielić dwie rzeczy, które w rozmowach o automatyzacji sprzedaży regularnie się mieszają.

Odzyskujesz powtarzalną robotę - wznawianie ogłoszeń, przepisywanie stanów między kanałami, raporty, przypomnienia, rozliczenia z marketplace. Robota, którą robisz identycznie dwa razy w tygodniu przez pół roku, jest pierwszą rzeczą, którą warto oddać systemowi.

Nie odzyskujesz decyzji - co wystawić, w jakiej cenie, którą ofertę wycofać. Vinted i tak nie daje Ci API, a na OLX część funkcji po prostu nie działa na wszystkich portalach grupy. Automatyzacja porządkuje wykonanie, ale nie zastąpi oceny.

Zanim zaczniesz, warto policzyć, ile godzin tygodniowo zjada dany proces i czy ta liczba w ogóle się broni. O tym, jak ułożyć taki rachunek, pisałem przy okazji prostym rachunku zwrotu z automatyzacji.

Pułapki, o których dowiesz się po wdrożeniu

Najczęściej kończy się tak, że proces działa poprawnie przez trzy miesiące, a potem cicho przestaje działać. Oto miejsca, w których to się łamie.

Po pierwsze, duplikaty transakcji. Gdy jeden webhook jest skonfigurowany w dwóch miejscach albo system wysyła zdarzenie dwa razy, zamówienie księguje się podwójnie. Zabezpieczenie jest proste: sprawdź, czy konto jest podpięte raz, i włącz ustawienia zapobiegające duplikatom. Używam tego przy każdej integracji, która dotyka pieniędzy.

Po drugie, próba na danych produkcyjnych. Pierwszy test integracji robisz na małej partii i na jednym użytkowniku, nie na pełnym katalogu. Wpis błędny powtarzany masowo daje efekt gorszy niż brak automatyzacji.

Po trzecie, wyłączony przepływ i nieudokumentowany limit po stronie API. Limitów n8n nie znajdziesz w dokumentacji, podobnie jak nie ma ich dla żadnej z integracji OLX. Jedynym zabezpieczeniem jest węzeł obsługi błędów, który powie Ci o problemie w chwili, gdy on wystąpi, a nie po miesiącu.

Po czwarte, rosnące koszty własnego sklepu. Każda kolejna integracja to kolejny moduł, kolejne 100 do 400 zł rocznie i kolejne miejsce, w którym aktualizacja może coś zerwać. Zanim dorzucisz czwarte połączenie, sprawdź, czy trzy istniejące faktycznie się używają.

Jest też pułapka z innej strony, o której mówię rzadziej: sprzedawca, który nie zna swojego procesu, nie zautomatyzuje go dobrze, tylko szybciej wykona te same błędy. Automatyzacja powtarza proces razem z jego wadami. Zanim zaczniesz budować przepływ, warto przejść go raz ręcznie i zobaczyć, które kroki są naprawdę powtarzalne - [mapa procesów w firmie](https://gdamian.pl/blog/mapa-procesow-w-firmie-jak-znalezc-zadania-do-automatyzacji-w-jeden-wieczor) powstaje zwykle w jeden wieczór, a potem widać w niej, gdzie leży naprawdę największy ból.

Od czego zacząć, kiedy dopiero zaczynasz

Kolejność ma znaczenie bardziej, niż sugerują poradniki. Nie zaczynaj od synchronizacji wszystkich kanałów naraz, bo przy pierwszym błędzie będziesz miał do czynienia z trzema problemami zamiast z jednym.

Krok pierwszy: wybierz jeden kanał i jeden proces, który dziś kosztuje Cię najwięcej godzin. W przypadku sprzedaży wielokanałowej najczęściej jest to wznawianie wygasających ogłoszeń albo ręczne przepisywanie stanów.

Krok drugi: zrób ten proces raz, ręcznie, od pierwszego do ostatniego kliknięcia. Wypisz, co jest wejściem, co wyjściem, gdzie padają wyjątki. Ten krok jest nudny i pomijany, a to on decyduje o tym, czy przepływ będzie działał.

Krok trzeci: zbuduj przepływ w n8n w wersji testowej i puść go na jednym, dwóch przypadkach, zanim włączysz go na stałe. Dopiero poprawny przepływ warto pokazać zespołowi i dopiero potem rozszerzać o kolejne kanały.

Krok czwarty: dopisz obsługę błędów i powiadomienie dla Ciebie. Bez tego pozostajesz w sytuacji, o której mówi każdy poradnik: system działa, dopóki nie przestanie.

Jeśli to pierwszy przepływ, w którym żyjesz, [zacznij od prostszego procesu w firmie](https://gdamian.pl/blog/7-procesow-w-firmie-ktore-warto-zautomatyzowac-jako-pierwsze) - takiego, gdzie wynik sprawdzisz gołymi oczami w kilka sekund. Sprzedaż wielokanałowa jest świetnym celem, ale dopiero po tym, jak znasz narzędzie.

Własny sklep dodaje do tego jeszcze jeden krok, którego nie ma przy marketplace'ach: faktura musi wyjść z systemu, bo sam PrestaShop jej nie wystawi. Warto zaplanować to razem z resztą, a nie dopiero wtedy, gdy klient dzwoni z pytaniem o fakturę.