Zapier i Make dla PrestaShop: automatyzacja pracy sklepu

Ostatnia weryfikacja: czerwiec 2026. Ceny i interwały odpytywania na obu platformach często się zmieniają, traktuj podane wartości orientacyjnie i przed decyzją sprawdź aktualne pakiety. Ścieżki w panelu administracyjnym zweryfikowano dla PrestaShop 1.7, 8.x i 9.x.

Każdy sklep PrestaShop traci czas w tym samym miejscu: na drobnych zadaniach operacyjnych, które pojedynczo zajmują dwie minuty, ale razem potrafią zabrać całe popołudnie w tygodniu. Nowe zamówienie trzeba przekazać do magazynu. Status "Wysłane" powinien uruchamiać SMS, a nie tylko e-mail. Nowy klient powinien trafić do CRM. Żadne z tych zadań nie jest trudne. Są po prostu nieustanne. Zapier i Make (dawniej Integromat) istnieją właśnie po to, aby wykonywać za Ciebie taką pracę łączącą systemy: spinać dane z PrestaShop z dziesiątkami innych narzędzi, z których już korzysta Twoja firma. Prawdziwe pytanie nie brzmi, czy automatyzować, tylko którym silnikiem to robić, i równie często: kiedy platforma automatyzacji jest zupełnie niewłaściwym narzędziem, a jej miejsce powinien zająć natywny moduł.

Ten poradnik pomaga podjąć tę decyzję. Porównamy Zapier i Make bezpośrednio, konkretnie z perspektywy sklepu PrestaShop, pokażemy trzy realne sposoby podłączenia PrestaShop do obu platform (z dokładnymi ścieżkami w panelu administracyjnym) i damy Ci ramy decyzyjne: kiedy zewnętrzna platforma zasługuje na miesięczną opłatę, a kiedy po cichu staje się obciążeniem. Jeśli szukasz łagodnego przewodnika krok po kroku po zbudowaniu pierwszego przepływu pracy bez kodowania, to osobny temat, zobacz PrestaShop i Zapier: automatyzacja przepływów pracy bez pisania kodu. Ten tekst jest o wyborze platformy i jej sensownym utrzymaniu.

Zapier kontra Make: uczciwe porównanie dla PrestaShop

Obie platformy robią zasadniczo to samo, obserwują zdarzenie w jednej aplikacji, a potem wykonują akcję w drugiej. Zapier nazywa przepływ pracy Zap; Make nazywa go Scenariuszem. Różnice, które naprawdę mają znaczenie dla właściciela sklepu PrestaShop, to głębokość integracji, model cenowy i sposób naliczania użycia platformy.

Co to oznacza w praktyce? Dla większości sklepów PrestaShop lepszym domyślnym wyborem jest Make, przede wszystkim ze względu na natywny konektor PrestaShop (aplikację Make, nieutrzymywaną przez PrestaShop SA). Usuwa on najbardziej podatny na błędy etap całej konfiguracji, czyli ręczne spinanie webhooków i Webservice, a rozliczanie za operacje lepiej skaluje się wraz ze wzrostem liczby zamówień. Po Zapier sięgnij wtedy, gdy priorytetem są inne aplikacje w Twoim przepływie pracy i akurat mają mocniejszy konektor Zapier, albo gdy chcesz najkrótszej drogi od pomysłu do działającej automatyzacji i i tak łączysz PrestaShop przez prosty webhook. Cenniki obu platform się zmieniają, więc potraktuj powyższe kwoty jako orientacyjne i sprawdź aktualne pakiety przed decyzją. Trwała jest różnica strukturalna (rozliczanie za zadania kontra za operacje, oficjalna aplikacja kontra jej brak).

Trzy sposoby podłączenia PrestaShop, i który wybrać

Niezależnie od wybranej platformy PrestaShop musi dostarczyć jej dane. W automatyzacjach w stylu Zapier/Make najczęściej stosuje się trzy ścieżki, które różnią się nakładem konfiguracji i tym, jak blisko czasu rzeczywistego działa efekt. (Prawdziwe sklepy korzystają też z dedykowanych modułów marketplace, konektorów ERP/księgowości i middleware/iPaaS, bezpośredniej wymiany bazodanowej lub plikowej w starszych ERP oraz modułów niestandardowych, ale trzy poniższe ścieżki to te, które realnie podepniesz do Zapier albo Make.)

Ścieżka 1: wbudowany Webservice (API podobne do REST)

PrestaShop ma wbudowany Webservice: HTTP API podobne do REST, domyślnie w XML, z wyjściem JSON dostępnym w obsługiwanych wersjach. To najbardziej elastyczne połączenie, bo udostępnia prawie każdy zasób, zamówienia, klientów, produkty, stany magazynowe, koszyki, adresy, ale działa w modelu pull: platforma automatyzacji musi odpytywać je według harmonogramu. Aby je włączyć:

• Przejdź do Parametry zaawansowane → Webservice w panelu administracyjnym.
• Przełącz Włącz Webservice PrestaShop na Tak (ustawia to flagę konfiguracyjną PS_WEBSERVICE).
• Kliknij Dodaj nowy klucz Webservice, a następnie nadaj uprawnienia dla poszczególnych zasobów, zaznacz tylko te zasoby, których potrzebuje automatyzacja (np. GET dla orders i customers, nic więcej).
• Skopiuj wygenerowany klucz do Make albo Zapier jako dane uwierzytelniające. Uwierzytelnianie to HTTP Basic z kluczem jako nazwą użytkownika i pustym hasłem, przez HTTPS.

Odpytywanie "pobierz nowe zamówienia" w tej ścieżce to pojedynczy GET. Poniższy przykład zwraca pięć najnowszych zamówień, z pełnymi polami, jako JSON:

GET https://yourstore.com/api/orders?display=full&output_format=JSON&sort=[id_DESC]&limit=5

# Auth: HTTP Basic – username = your Webservice key, password = blank
curl -u "YOUR_WEBSERVICE_KEY:" \
  "https://yourstore.com/api/orders?display=full&output_format=JSON&sort=[id_DESC]&limit=5"

Parametr display=full jest tym, o którym ludzie zapominają, bez niego Webservice zwraca tylko listę ID zasobów, a nie pola zamówienia, które faktycznie chcesz zmapować w swoim Zapie albo Scenariuszu. output_format=JSON jest honorowany tylko w wersjach, które go obsługują; domyślnym formatem wyjścia jest XML. W platformie zapisuj najwyższe ID zamówienia, które już przetworzyłeś, i działaj tylko na wierszach powyżej tej wartości, bo inaczej przy każdym odpytywaniu ponownie przetworzysz te same zamówienia.

Dwie rzeczy są tu nienegocjowalne: zawsze udostępniaj API przez HTTPS (klucz podróżuje w żądaniu) i ogranicz uprawnienia do minimum. Wyciek klucza z prawem zapisu do orders może pozwolić na nadpisanie historii sprzedaży. Jeśli Twoja platforma oferuje statyczne wychodzące adresy IP, dodaj je do listy dozwolonych na poziomie serwera albo firewalla, aby tylko Twoja automatyzacja mogła sięgnąć do endpointu.

Ścieżka 2: webhooki (push, czas rzeczywisty)

Webhooki odwracają kierunek: zamiast pytać platformę "czy jest coś nowego?" co kilka minut, PrestaShop wysyła zdarzenie natychmiast, gdy ono nastąpi. To właściwy model dla wszystkiego, gdzie liczy się czas, powiadomienie na Slacku w chwili pojawienia się zamówienia, kontrola antyfraudowa uruchomiona przy finalizacji zamówienia. Jest jednak haczyk: rdzeń PrestaShop nie ma wbudowanego nadawcy webhooków. Coś musi nasłuchiwać na odpowiednim hooku (actionValidateOrder dla nowego zamówienia, actionOrderStatusPostUpdate dla zmiany statusu, actionObjectCustomerAddAfter dla nowego klienta) i wysłać dane metodą POST na URL Twojego scenariusza. Tym "czymś" jest mały moduł, z marketplace albo kilka linijek kodu podpiętych pod te hooki. Nagrodą jest prawdziwe działanie w czasie rzeczywistym, bez kosztu odpytywania i bez zużywania mierzonego zadania na puste sprawdzenia.

Ścieżka 3: natywny konektor PrestaShop w Make

Jeśli wybierasz Make, jego natywny konektor PrestaShop (aplikacja Make, nieutrzymywana przez PrestaShop SA) jest ścieżką najmniejszego oporu. Obsługuje za Ciebie uwierzytelnianie Webservice i udostępnia gotowe wyzwalacze do obserwowania nowych i zaktualizowanych zamówień, produktów oraz klientów, więc wskazujesz URL sklepu i klucz, a potem zaczynasz budować. Pod spodem to nadal odpytywanie (czyli dziedziczy opóźnienia opisane niżej), ale pomijasz każdy ręczny krok ze Ścieżki 1. Właśnie dlatego "użyj Make" i "użyj jego natywnego konektora" zwykle oznaczają tę samą rekomendację dla typowego sklepu.

Skrót decyzyjny: potrzebujesz reakcji natychmiast (alerty, antyfraud, timing porzuconych koszyków)? Użyj webhooków (Ścieżka 2). Potrzebujesz szerokiego dostępu do odczytu katalogu/zamówień według harmonogramu i jesteś na Make? Użyj natywnego konektora (Ścieżka 3). Korzystasz z Zapier albo potrzebujesz zasobu, którego aplikacja nie obejmuje? Podepnij Webservice ręcznie (Ścieżka 1).

Podatek od opóźnień, dlaczego "zautomatyzowane" nie znaczy "natychmiastowe"

To najczęściej źle rozumiana rzecz w Zapier i Make, a jednocześnie coś, co decyduje, które automatyzacje w ogóle mają sens. Wyzwalacze oparte na odpytywaniu nie reagują w chwili zdarzenia, sprawdzają dane w określonym interwale. W zależności od planu Zapier odpytuje mniej więcej co 1–15 minut, a Make w płatnych planach nawet co minutę (w darmowym pakiecie rzadziej). Dla logu "nowe zamówienie do Google Sheets" kilka minut opóźnienia jest niewidoczne i bez znaczenia. Dla odzyskiwania porzuconych koszyków, gdzie optymalne okno mierzy się w dziesiątkach minut, takie opóźnienie odpytywania plus długi harmonogram scenariusza może sprawić, że całkowicie przegapisz moment. Własne hooki PrestaShop uruchamiają się synchronicznie, natychmiast, właśnie dlatego część zadań powinna działać w module na Twoim serwerze, a nie w chmurowej platformie po drugiej stronie internetu.

Kiedy platforma automatyzacji jest złym narzędziem

Zapier i Make są świetne w jednej rzeczy: łączeniu PrestaShop z niszowym narzędziem, którego używa Twoja firma i dla którego nigdy nie powstanie dedykowany moduł, konkretnym operatorem 3PL, wewnętrznym arkuszem Google, kanałem Discord, regionalną bramką SMS. Dla takiego długiego ogona jednorazowych połączeń trudno je pobić. Są jednak sytuacje, w których opieranie się na zewnętrznej platformie kosztuje więcej, niż oszczędza:

• Koszt przy skali. Sklep realizujący 200 zamówień dziennie i pięć automatyzacji na zamówienie generuje około 30 000 zadań/operacji miesięcznie. W modelu rozliczania Zapier za zadania szybko wypycha Cię to do wysokiego pakietu; w modelu Make za operacje jest taniej, ale natywny moduł kupujesz raz i potem wykonuje tę pracę bez dodatkowego licznika. Policz własny przypadek, zanim uznasz platformę za ekonomiczny wybór.
• Zadania czasu rzeczywistego. Wszystko, gdzie moment reakcji jest całym sensem. Odzyskiwanie porzuconych koszyków, alerty stanów magazynowych, które muszą wyprzedzić nadmierną sprzedaż, sygnały fraudowe, przegrywa z opisanym wyżej opóźnieniem odpytywania. Moduł działający na hooku wygrywa bezpośrednio.
• Model danych PrestaShop. Ceny specyficzne, kombinacje, reguły koszyka, multistore, reguły podatkowe, to naprawdę złożone obszary. Zewnętrzny scenariusz, który musi je odtwarzać przez wywołania API, staje się kruchy i bolesny w utrzymaniu; dobrze napisany natywny moduł może używać własnego modelu i usług PrestaShop zamiast rekonstruować te reguły na zewnątrz.
• Ryzyko zależności. Każda zewnętrzna platforma to kolejny element, który może mieć awarię. Gdy Zapier albo Make przestają działać, Twoje automatyzacje zatrzymują się razem z nimi. Kod działający na Twoim własnym serwerze nie ma tej zależności.

Konkretne zadania, które odradzalibyśmy przenosić na ogólną platformę: e-mail marketing i porzucone koszyki (dedykowany konektor PrestaShop dla Mailchimp, Brevo albo Klaviyo synchronizuje segmenty, historię zakupów i pełny katalog, oraz śledzi aktywność koszyka w czasie rzeczywistym zamiast walczyć z oknem odpytywania), księgowość (wystawianie faktur jest znacznie czystsze przez integrację zbudowaną do tego celu, omawiamy kompromisy w tekście łączenie PrestaShop z programem księgowym) oraz poważna synchronizacja stanów magazynowych lub zamówień między kanałami i systemami zaplecza, co poprawnie jest już zadaniem dla ERP.

Ten ostatni punkt zasługuje na osobną wzmiankę, bo właśnie tu sklepy najczęściej próbują zrobić z Zapier zbyt wiele: rozrastająca się plątanina Scenariuszy próbujących synchronizować stany, zamówienia i klientów między PrestaShop a systemem zaplecza to znak, że sklep wyrósł z prostego kleju i potrzebuje prawdziwego wzorca integracji. Opisujemy te wzorce w łączeniu PrestaShop z ERP, a sygnały przekroczenia tej granicy w tekście kiedy sklep wyrasta z pracy ręcznej.

Gdzie pasuje mypresta.rocks

Budujemy moduły PrestaShop, które obsługują ciężkie, krytyczne dla sklepu integracje natywnie, na Twoim serwerze, na hooku, bez miesięcznego licznika zadań i bez internetowej drogi w obie strony między zdarzeniem a reakcją. Co z tego wynika w praktyce? Zadania, które źle znoszą odpytywanie i rozliczanie za zadania, natychmiastowe powiadomienia o zamówieniach, synchronizacja stanów i kanałów w czasie rzeczywistym, timing porzuconych koszyków, głębokie połączenia z CRM i platformami e-mail. Działają szybciej i taniej jako kod, który posiadasz, niż jako wynajęte operacje. To nie jest argument przeciwko Zapier i Make; to podział ról. Zostaw platformy chmurowe dla naprawdę niestandardowych, niskowolumenowych połączeń z narzędziami, dla których nikt nigdy nie zbuduje modułu, a wysokonakładowe, wrażliwe czasowo operacje świadome PrestaShop przenieś do czegoś natywnego. Dla zadań harmonogramowanych, które mają zostać na Twoim serwerze, nocnego eksportu, cyklicznej synchronizacji, Cron Manager daje każdemu zadaniu rekord i widoczny ostatni przebieg, więc proces, który po cichu przestaje działać, sygnalizuje problem zamiast zniknąć niezauważony. A jeśli Twoje automatyzacje wypychają katalog albo segmenty do platformy e-mail, natywny konektor Mailchimp utrzymuje tę synchronizację na hooku zamiast na płatnym odpytywaniu. Korzyści sumują się z obu stron: mniej wydatków na mierzone zadania, mniej ruchomych części, które mogą zawieść, i operacje reagujące dokładnie wtedy, gdy reaguje Twój sklep.

Jak prowadzić automatyzacje, żeby się nie sparzyć

Niezależnie od tego, po której stronie granicy ląduje dany przepływ pracy, kilka nawyków operacyjnych chroni automatyzację przed zmianą w ciche zobowiązanie:

• Jeden przepływ pracy naraz. Doprowadź pojedynczy Zap albo Scenariusz do niezawodnego działania na zamówieniach testowych, zanim zbudujesz następny. Nietestowana automatyzacja na danych zamówień produkcyjnych to sposób, w jaki odkrywa się źle sformatowane dane dopiero po tym, jak trafiły już do systemu księgowego.
• Wypatruj cichych awarii. Zap, który po cichu przestaje działać, jest gorszy niż taki, który psuje się głośno, pominięte powiadomienia o zamówieniach i niewysłane SMS-y same się nie zgłoszą. Przeglądaj logi wykonań co tydzień i włącz alerty awarii platformy.
• Nazywaj i dokumentuj wszystko. Po przekroczeniu kilkunastu przepływów pracy "Kopia Scenariusza 7" to przyszły kryzys. Używaj pól opisu; zapisuj, czego każdy przepływ dotyka.
• Rotuj i zawężaj klucze. Wymieniaj klucz Webservice według harmonogramu i trzymaj jego uprawnienia do zasobów dokładnie przycięte do tego, co automatyzacja czyta albo zapisuje, nigdy nie nadawaj dostępu do całego API "na wszelki wypadek".
• Wysyłaj e-maile transakcyjne przez SMTP, nie przez platformę. Jeśli automatyzacje uruchamiają powiadomienia, niezawodność e-maili Twojego sklepu ma większe znaczenie niż kiedykolwiek, ustaw solidne podstawy dostarczalności w konfiguracji e-maili w PrestaShop: SMTP, Gmail i wiadomości transakcyjne.

Najczęściej zadawane pytania

Czy Zapier albo Make mają oficjalną aplikację PrestaShop?

W Make dostępny jest natywny konektor PrestaShop, ale to aplikacja Make, nieutrzymywana przez PrestaShop SA. W Zapier nie ma żadnej oficjalnej aplikacji PrestaShop; łączysz się przez wbudowany Webservice API i ogólne kroki Webhooks w Zapier. Ta różnica jest głównym powodem, dla którego Make jest łatwiejszym wyborem domyślnym dla typowego sklepu.

Dlaczego mój "zautomatyzowany" przepływ pracy nie działa natychmiast?

Bo wyzwalacze oparte na odpytywaniu sprawdzają dane w interwale, zamiast reagować w chwili zdarzenia, mniej więcej co 1–15 minut w Zapier i nawet co minutę w płatnych planach Make. Przy logowaniu danych albo powiadomieniach takie opóźnienie jest niewidoczne; przy pracy krytycznej czasowo, takiej jak odzyskiwanie porzuconych koszyków albo zapobieganie nadmiernej sprzedaży, może sprawić, że przegapisz właściwe okno. Takie zadania powinny działać na hooku PrestaShop (który uruchamia się natychmiast) przez webhook albo natywny moduł, a nie na odpytywaniu.

Zapier czy Make dla sklepu PrestaShop?

Make jest lepszym domyślnym wyborem dla większości sklepów, głównie dzięki natywnemu konektorowi PrestaShop i tańszemu rozliczaniu za operacje wraz ze wzrostem wolumenu. Wybierz Zapier, gdy inne aplikacje w Twoim przepływie pracy mają mocniejszy konektor Zapier, albo gdy chcesz możliwie najkrótszej drogi do działającej automatyzacji i i tak podpinasz PrestaShop przez prosty webhook.

Kiedy użyć natywnego modułu zamiast platformy automatyzacji?

Gdy zadanie ma wysoki wolumen, jest wrażliwe czasowo albo głęboko osadzone w modelu danych PrestaShop, natychmiastowe powiadomienia o zamówieniach, synchronizacja stanów/kanałów w czasie rzeczywistym, timing porzuconych koszyków, księgowość oraz połączenia z CRM/platformami e-mail. Natywny moduł działa na Twoim serwerze, bez licznika zadań i bez internetowej drogi w obie strony. Zachowaj Zapier i Make dla niskowolumenowych, naprawdę niestandardowych połączeń z niszowymi narzędziami, dla których nikt nie zbuduje modułu.

Jak zabezpieczyć klucz Webservice, gdy trzyma go platforma chmurowa?

Ogranicz go dokładnie do zasobów, których dotyka automatyzacja (nigdy nie dawaj dostępu do całego API), zawsze udostępniaj API przez HTTPS, rotuj klucz według harmonogramu, a jeśli platforma oferuje statyczne wychodzące adresy IP, dodaj je do listy dozwolonych na serwerze albo firewallu, aby tylko Twoja automatyzacja mogła sięgnąć do endpointu. Wąsko ograniczony klucz oznacza, że zasięg ewentualnego wycieku obejmuje to, co zaznaczyłeś, nie całą bazę danych.

Powiązane artykuły

• PrestaShop i Zapier bez pisania kodu, praktyczne podłączenie, przepis po przepisie
• Łączenie PrestaShop z programem księgowym. Dlaczego księga jest jednym z zadań, których nie warto trzymać na ogólnej platformie
• Konfiguracja e-maili w PrestaShop, dopracuj dostarczalność wiadomości transakcyjnych, zanim oprzesz na niej automatyzacje

Automatyzacja nie polega na zastąpieniu rozsądku, polega na usunięciu powtarzalnych minut, które składają się na utracone godziny. Zapier i Make są właściwym narzędziem dla niestandardowych, niskowolumenowych obrzeży tej pracy; natywne moduły PrestaShop są właściwym narzędziem dla wysokonakładowego, krytycznego czasowo rdzenia. Umiejętność rozpoznania, co jest czym, i poprawnego podłączenia każdego elementu przez Webservice, webhook albo natywny hook, decyduje o różnicy między automatyzacją, która oszczędza czas, a plątaniną chmurowych scenariuszy, która staje się kolejną rzeczą do pilnowania.