API i integracje PrestaShop: Webservice, ERP, Zapier i Make

Co byśmy zrobili

Zaczęlibyśmy od ręcznego zadania lub błędu, który możesz zmierzyć, a następnie sprawdzilibyśmy, czy istniejąca integracja już potrafi go obsłużyć. Przy stałej wymianie zacznij od zaplanowanego zadania przyrostowego, jeśli firma może zaakceptować opóźnienie. Wybierz utrzymywany konektor, jeśli obejmuje cały proces; zleć proces roboczy lub moduł, gdy brakujące reguły biznesowe uzasadniają utrzymywanie własnego kodu.

Sposób działania zależy od zainstalowanych wersji PrestaShop i PHP, modułów, innych integracji, dostosowań motywu i finalizacji zakupu, jakości danych, kombinacji i konfiguracji multistore. Uwzględnij obsługiwane rynki, waluty i przypadki podatkowe, możliwości systemu odbierającego oraz zespół dostępny do obsługi. Przećwicz zmianę na kopii testowej z reprezentatywnymi danymi i taką samą istotną konfiguracją, odizolowanej od rzeczywistej poczty klientów, wysyłek magazynowych i zapisów produkcyjnych w innych systemach. Zaplanuj przełączenie i wycofanie przed włączeniem zapisu na produkcji.

Jeśli potrzebujesz konektora zbudowanego według tych zasad, usługa PrestaShop Custom Module Development Service zaczyna się od pisemnej specyfikacji i kryteriów odbioru uzgodnionych połączeń.

Wybierz najmniejsze rozwiązanie spełniające wymaganie

Wybierz API i określ kontrakt integracji

Starszy Webservice jest częścią rdzenia. Zapewnia dostęp HTTP do zasobów, żądania XML oraz odpowiedzi XML lub JSON w PrestaShop 1.7.8 i 9.1. PrestaShop 9 ma też Admin API z OAuth2 i JSON. Te API różnią się uwierzytelnianiem, ścieżkami i zakresem funkcji.

Przed wyborem wypisz dokładne operacje, których potrzebujesz: tworzenie produktów, mapowanie kombinacji, aktualizacje stanów, eksport zamówień, zwroty, śledzenie przesyłek lub dokumenty księgowe. Sprawdź listę zasobów zainstalowanego sklepu i wygenerowaną dokumentację. Nie zakładaj, że którekolwiek API obejmuje każdą operację w każdej wersji. Dla każdej operacji zapisz źródło, cel, kontekst sklepu, wymagane pola, oczekiwane skutki biznesowe i odpowiedź potwierdzającą przyjęcie. Konektor odczytujący zamówienie może nadal nie obsługiwać korekt lub śledzenia przesyłek potrzebnych w Twoim procesie.

Do regularnego zapisu wybierz API lub wspieraną usługę aplikacji. Bezpośredni SQL omija walidację aplikacji, hooki i inne przetwarzanie. Specjalistyczna migracja musi jawnie obsłużyć powiązania, indeksowanie, stany, multimedia i unieważnianie pamięci podręcznej; samo jej wyczyszczenie nie wystarczy. Nie ma uniwersalnego progu wielkości katalogu, od którego bezpośredni SQL staje się właściwym wyborem.

Ten poradnik zaczyna się od mechanizmów Webservice, a następnie omawia projektowanie ERP i platformy automatyzacji. Zobacz oficjalną dokumentację Webservice, aby poznać szczegóły zainstalowanej wersji.

Włącz dostęp i sprawdź routing

1. Otwórz Parametry zaawansowane, Usługi internetowe. Włącz Webservice.
2. Utwórz osobny aktywny klucz dla każdej integracji.
3. Przyznaj tylko wymagane zasoby i metody we właściwym kontekście sklepu.
4. Przechowuj klucz w magazynie sekretów lub chronionym pliku poświadczeń poza kontrolą wersji.
5. Przetestuj dostęp przez HTTPS z rzeczywistego środowiska uruchamiającego integrację.

W uwierzytelnianiu HTTP Basic klucz jest nazwą użytkownika, a hasło pozostaje puste. Dispatcher przyjmuje też ws_key w ciągu zapytania, ale unikaj tego sposobu przesyłania, ponieważ adresy URL mogą trafiać do logów, historii i analityki.

Przykłady używają prywatnego pliku konfiguracji curl wskazanego przez WS_CURL_CONFIG. W Bash podaj rzeczywisty bazowy adres HTTPS sklepu, w tym ewentualny podkatalog instalacji, oraz klucz integracji. Tymczasowy plik poświadczeń zostanie usunięty po zamknięciu tej powłoki. Pozostaw tę samą powłokę otwartą do kolejnych przykładów curl.

umask 077
read -r -p 'Shop HTTPS base URL: ' SHOP_URL
read -r -s -p 'Webservice key: ' WS_KEY
printf '\n'
WS_CURL_CONFIG="$(mktemp)"
trap 'rm -f "$WS_CURL_CONFIG"' EXIT
printf 'user = "%s:"\n' "$WS_KEY" > "$WS_CURL_CONFIG"
unset WS_KEY
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/?output_format=JSON"

Ścieżka API i dispatcher

/api jest zwykle ścieżką wirtualną. Wygenerowane reguły Apache kierują ją do webservice/dispatcher.php z parametrem url. Ta reguła API jest generowana niezależnie od ustawienia przyjaznych adresów URL sklepu.

W Nginx zachowaj ścieżkę zasobu i oryginalne argumenty. Standardowa postać reguły przepisywania w oficjalnej konfiguracji to:

rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;

W przypadku sklepu zainstalowanego w /shop/ dostosuj obie strony:

rewrite ^/shop/api/?(.*)$ /shop/webservice/dispatcher.php?url=$1 last;

Te reguły należy umieścić na poprawnie skonfigurowanym serwerze z istniejącą obsługą PHP. Na przykład /shop/api/products?limit=5 musi dotrzeć do dispatchera z url=products oraz limit=5. Przy tej postaci reguły Nginx dołącza oryginalne argumenty. Po przeładowaniu przetestuj faktyczną konfigurację serwera i obie ścieżki.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/webservice/dispatcher.php?url=products&limit=1"

Jeśli bezpośredni dostęp do dispatchera działa, a ścieżka API nie, sprawdź przepisywanie adresów, ścieżkę bazową i routing proxy. Zastosuj ograniczenia IP i limity żądań zarówno do przyjaznej ścieżki, jak i do rzeczywistego dispatchera. Plik .htaccess w nieistniejącym katalogu /api/ nie zabezpiecza punktu końcowego PHP. Sprawdź ograniczenia po każdym wewnętrznym przepisaniu adresu.

Poznaj zasoby, schematy i formaty odpowiedzi

Główny adres API pokazuje zasoby dostępne dla uwierzytelnionego klucza. Typowe grupy obejmują produkty, kategorie, kombinacje, atrybuty, klientów, adresy, zamówienia, szczegóły zamówień, historie zamówień, przewoźników i dostępność magazynową. Zdjęcia mają osobne ścieżki zarządzania.

Nie kopiuj uniwersalnej listy zasobów z innej wersji. Na przykład supply_orders występuje na liście zasobów PrestaShop 1.7.8, a nie ma go na liście 9.1.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,reference,active]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/products"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,id_product,id_product_attribute,quantity]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/stock_availables"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products?schema=synopsis"

Bez wyboru zakresu wyświetlania kolekcje zasobów zwykle zwracają identyfikatory i linki. Używaj wybranych pól dla list, display=full, gdy potrzebujesz całego kontekstu dostępnego do zapisu, lub pobieraj pojedyncze zasoby. Sprawdź rzeczywistą odpowiedź przed zmapowaniem jej do innego systemu. W edytorze automatyzacji sprawdź, czy odpowiedź jest kolekcją i jak przekształca się w pojedyncze działania docelowe. Mapowanie wyłącznie pierwszego zwróconego obiektu może przejść test jednego zamówienia, pomijając resztę strony.

schema=blank udostępnia szablon zasobu. schema=synopsis dodaje oznaczenia wymaganych pól, formaty walidacji, długości i informacje o polach tylko do odczytu. Nie jest deklaracją wszystkich filtrów przyjmowanych przez API.

Nawiasy kwadratowe należą do składni zapytań Webservice. Ujęcie adresu URL w cudzysłowy chroni go przed powłoką, ale nie wyłącza rozwijania wzorców URL przez curl. Użyj --globoff, zakoduj nawiasy lub buduj zapytania za pomocą --get --data-urlencode. Zobacz podręcznik curl.

Filtruj, sortuj i stronicuj bez utraty zmian

W przypadku filtrów date_add lub date_upd dodaj date=1. Bez tego PrestaShop 1.7.8 i 9.1 usuwają te pola z listy dozwolonych filtrów, więc żądanie może zwrócić HTTP 400.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'date=1' \
  --data-urlencode 'filter[date_upd]=[2026-10-01 00:00:00,2026-10-02 00:00:00]' \
  --data-urlencode 'sort=[date_upd_ASC,id_ASC]' \
  --data-urlencode 'display=[id,reference,current_state,date_upd]' \
  --data-urlencode 'limit=0,100' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/orders"

Kompletne cykliczne pobieranie nowych zamówień

1. Zapisuj identyfikator ostatniego poprawnie przetworzonego zamówienia, osobno dla każdego sklepu lub źródła.
2. Pobieraj zamówienia z identyfikatorem większym od tego punktu kontrolnego w kolejności rosnącej. Ograniczony zakres, taki jak filter[id]=[next_id,upper_id], może wyznaczać jeden przebieg.
3. Przeglądaj kolejne strony, aż przetworzysz wszystkie pasujące zamówienia. Próbka pięciu najnowszych nie stanowi kompletnego pobrania.
4. Zapewnij idempotentność działania docelowego i zapisuj powodzenie.
5. Przesuwaj punkt kontrolny tylko poza poprawnie ukończone operacje albo trwale zapisuj nieudane elementy przed przejściem dalej.

Do aktualizacji istniejących zamówień używaj ograniczonego okna czasu modyfikacji i stabilnego dodatkowego klucza sortowania, np. ID. Zachowuj nakładanie się okien i usuwaj duplikaty, ponieważ znaczniki czasu mogą się powtarzać, a równoczesne zmiany mogą przenosić wiersze między stronami. Zapisuj okno dopiero po jego ukończeniu. Powiązane rekordy wymagają osobnej obsługi zmian: aktualizacja numeru przesyłki w rekordzie przewoźnika zamówienia nie musi aktualizować znacznika czasu nadrzędnego zamówienia. Uzgadniaj powiązane dane zamiast polegać wyłącznie na pobieraniu zamówień.

Dobieraj odstępy na podstawie zmierzonych opóźnień, tempa zmian stanów i obciążenia API. Cogodzinne zadanie katalogu i często działający proces stanów magazynowych mają inne wymagania. Nie ma jednego najlepszego odstępu dla każdego sklepu.

Twórz i aktualizuj kompletne zasoby dostępne do zapisu

Do tworzenia używaj pustego schematu, wypełnij wymagane pola i sprawdź identyfikatory w sklepie docelowym. Nie zakładaj, że kategoria 2, język 1 lub grupa podatkowa 1 mają zamierzone znaczenie. W przypadku produktu sprawdź nazwę i przyjazny URL dla każdego języka, domyślną kategorię, powiązania z kategoriami, cenę, konfigurację podatków, znacznik aktywności i stan publikacji.

Przy PUT pobierz zasób, porównaj go z jego synopsis, usuń pola niedostępne do zapisu i zachowaj wymagane pola zapisywalne oraz powiązania. Zmień zamierzone wartości i prześlij XML z poprawnym Content-Type. Odpowiedź GET produktu może zawierać pole niedostępne do zapisu, np. manufacturer_name; odesłanie niezmienionej odpowiedzi przez PUT może się nie powieść.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products/42" -o product.xml

# Edit and validate product.xml, removing read-only fields first.
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --request PUT --header 'Content-Type: application/xml' \
  --data-binary @product.xml "$SHOP_URL/api/products/42"

W przykładach zapisu używaj wyłącznie jednorazowych rekordów w środowisku testowym. W Webservice PrestaShop 9.1 PATCH obsługuje częściowe aktualizacje. Przed jego wyborem sprawdź zainstalowaną wersję, uprawnienia klucza i zasób; PrestaShop 1.7.8 nie obsługuje PATCH.

Dla rekordu magazynowego PrestaShop 9.1, którego ID zostało sprawdzone, częściowa treść żądania zawiera identyfikator zasobu:

<prestashop>
  <stock_available>
    <id>89</id>
    <quantity>100</quantity>
  </stock_available>
</prestashop>

Prześlij ją metodą PATCH do /api/stock_availables/89, a nie jako skrócone PUT. Jeśli PATCH jest niedostępne, pobierz rekord magazynowy przez GET i zachowaj wszystkie wymagane wartości dostępne do zapisu w PUT. W obu przypadkach sprawdź produkt, kombinację i sklep przed zapisem, a następnie ponownie odczytaj ilość.

Dla każdego elementu partii sprawdzaj błędy transportu, status HTTP i treść odpowiedzi. Przejściowe błędy odczytu ponawiaj z rosnącym odstępem, maksymalnym opóźnieniem i limitem prób lub czasu, uwzględniając odpowiedzi ograniczające tempo żądań. Zachowuj możliwość ponownego przetworzenia elementów po wyczerpaniu prób i alarmuj operatora. Po niepewnym zapisie uzgodnij rzeczywisty wynik przed ponowieniem. Ślepe powtórzenie żądania utworzenia lub zmiany stanu może powielić jego skutek. Utrzymuj trwałe mapowanie identyfikatorów zewnętrznych na lokalne i zapisuj nierozwiązane elementy do odzyskania.

Używaj serializatora XML do kodowania znaków specjalnych w tekście. CDATA może zawierać znaczniki, ale musi poprawnie obsługiwać własny terminator. Wysyłaj UTF-8 i element główny prestashop.

Usuwanie

DELETE jest operacją destrukcyjną i nie ma ogólnego kosza. Wybierz wyłączenie elementu, jeśli spełnia potrzebę biznesową. Tylko dla jednorazowych rekordów usuwanie zbiorcze korzysta z identyfikatorów oddzielonych przecinkami, np. ?id=[42,43,44], z wyłączonym rozwijaniem wzorców curl. Pionowe kreski należą do składni filtrów, a nie do tej listy usuwania.

Obsługuj zdjęcia, kombinacje i kontekst stanów magazynowych

Zdjęcia

Przesyłanie zdjęć używa danych multipart zamiast XML produktu. Sprawdź typy zdjęć i limity przetwarzania w sklepie docelowym.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --form 'image=@photo.jpg;type=image/jpeg' \
  "$SHOP_URL/api/images/products/42"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/images/products/42"

Ścieżka konkretnego zdjęcia i typu może wyglądać tak: /api/images/products/42/15/large_default, jeśli ten typ istnieje. Usuwanie zdjęć korzysta ze ścieżki zasobu zdjęcia i DELETE. Przetestuj wymiary, format, limity przesyłania, pamięć i generowanie miniatur na reprezentatywnych plikach. Nie ma uniwersalnej granicy awarii wynoszącej 2048 pikseli lub 5 MB.

Kombinacje

1. Utwórz lub zmapuj grupę atrybutów, np. Rozmiar, przez product_options.
2. Utwórz lub zmapuj jej wartości, np. M, przez product_option_values.
3. Utwórz kombinację dla produktu nadrzędnego i powiąż właściwe identyfikatory wartości.
4. Zapisz stabilne mapowanie zewnętrzne i unikatowy indeks pozycji przeznaczonej do sprzedaży.

Cena kombinacji jest wpływem na cenę bazową produktu, a nie jego końcową ceną sprzedaży. Jeśli źródło podaje końcową cenę obejmującą bazę i wpływ, oblicz wpływ we właściwej walucie i na właściwej podstawie podatkowej. Ustaw pozostałe wymagane wartości, np. minimalną ilość, zgodnie ze schematem i wymaganiami biznesowymi.

Dostępność magazynowa

Wyszukuj stock_availables według ID produktu, ID kombinacji oraz właściwego kontekstu sklepu lub współdzielonych sklepów. Produkty bez kombinacji używają ID atrybutu równego zero. Dla produktów z kombinacjami aktualizuj właściwe rekordy kombinacji; nie nadpisuj zbiorczego stanu na poziomie produktu tak, jakby reprezentował konkretny rozmiar lub kolor.

Zachowaj ustawienia braku towaru i zależności magazynowych. Ustal, czy wartości są bezwzględnymi migawkami, czy zmianami, kto odpowiada za rezerwacje i jak uwzględniane są zamówienia w drodze do ERP. Opóźniona miarodajna migawka może nadal nadpisać nowsze lokalne pomniejszenie, jeśli ten kontrakt jest błędny.

Eksportuj zamówienia i kontroluj skutki zmian statusu, śledzenia przesyłek i wysyłania e-maili

Odczytaj zamówienie z /api/orders/1234, a powiązane z nim wiersze z order_details filtrowanych po id_order. Sprawdź adresy, waluty, sumy podatków, rabaty, informacje o płatności, faktury i korekty wymagane przez system odbierający.

Odczytaj order_states z rzeczywistego sklepu. Nie wpisuj na stałe popularnych domyślnych identyfikatorów liczbowych. Znaczniki statusu mogą wpływać na obsługę stanów, faktur lub dostaw oraz na powiadomienia.

Aby świadomie przeprowadzić zmianę etapu procesu, wyślij rekord order_history metodą POST. Jeśli chcesz wysłać e-mail, zażądaj tego jawnie przez sendemail=1; znaczenie mają też konfiguracja e-maila dla statusu i poprawny szablon.

<prestashop>
  <order_history>
    <id_order>1234</id_order>
    <id_order_state>4</id_order_state>
  </order_history>
</prestashop>

To przykład dla środowiska testowego z przykładowymi identyfikatorami. Jego punkt końcowy żądający e-maila to /api/order_histories?sendemail=1. Bez tego znacznika OrderHistory::addWs() zmienia status i zapisuje historię bez samodzielnego żądania wysłania e-maila o statusie. Inne moduły nasłuchujące zmian statusu mogą wywoływać odrębne skutki. Nie zmieniaj statusów tylko po to, by ponownie wysłać wiadomość.

Numery przesyłek są reprezentowane przez order_carriers. Pobierz właściwy rekord przewoźnika, zachowaj pola dostępne do zapisu i zaktualizuj numer przesyłki. Sprawdź wynikowe zachowanie e-maili i linków przewoźnika w swojej wersji; nie zakładaj, że każdy zapis API ma takie same skutki uboczne jak każde polecenie panelu administracyjnego.

Tworzenie zamówień

Metoda tworzenia zamówień Webservice wywołuje validateOrder() wskazanego modułu płatności. Nie omija po prostu walidacji zamówienia, przetwarzania stanów i hooków. Potrzebujesz poprawnego koszyka, kontekstu klienta, zgodnego modułu płatności i konfiguracji statusu płatności Webservice, w tym PS_OS_WS_PAYMENT.

Zweryfikuj kwoty, podatki, dostawę, walutę, znaczenie płatności i ochronę przed duplikatami w środowisku testowym. Zaimportowana płatność z marketplace nie jest nowym obciążeniem karty. Sprawdź wszystkie e-maile i skutki magazynowe generowane przez wybraną ścieżkę. Użyj wspieranego konektora lub własnej operacji aplikacji, gdy potrzebujesz jawnej kontroli nad bardziej złożoną transakcją.

Używaj klienta PHP i świadomie udostępniaj dane modułu

Oficjalny klient PHP Webservice udostępnia narzędzia XML do obsługi żądań HTTP. Wybierz wersję biblioteki zgodną ze środowiskiem uruchomieniowym, wyłącz debugowanie na produkcji i nie zapisuj poświadczeń ani pełnych odpowiedzi z danymi klientów w logach.

composer require prestashop/prestashop-webservice-lib

Przy zapytaniu przyrostowym opcje klienta muszą zawierać także flagę daty. Ten przykład zakłada, że klient i poświadczenia zostały już zainicjalizowane:

$options = [
    'resource' => 'orders',
    'date' => 1,
    'filter[date_upd]' => '[2026-10-01 00:00:00,2026-10-02 00:00:00]',
    'display' => '[id,reference,current_state,date_upd]',
    'sort' => '[date_upd_ASC,id_ASC]',
    'limit' => '0,100',
];
$xml = $ws->get($options);

To jedna strona ograniczonego zapytania, a nie pełna pętla synchronizacji. Zastosuj opisany wcześniej punkt kontrolny, stronicowanie i obsługę błędów. Przy aktualizacji stanów odrzucaj brak wyników lub wyniki niejednoznaczne przed edycją jakiegokolwiek zwróconego rekordu.

Moduł może udostępniać własny ObjectModel przez addWebserviceResources. Na przykład zasób artykułów może wskazywać klasę Article modułu i zabraniać DELETE. Zdefiniuj strukturę danych przez $webserviceParameters, ogranicz udostępniane pola i sprawdź uprawnienia oraz wynik synopsis. Klasa i jej walidacja muszą rzeczywiście istnieć; sama deklaracja zasobu nie implementuje modelu biznesowego punktu końcowego.

Podczas implementowania tej warstwy korzystaj z dokumentacji własnych zasobów oraz oficjalnego kodu źródłowego klienta PHP.

Oceń osobno Admin API w PrestaShop 9

Admin API używa poświadczeń klienta OAuth2, autoryzacji o określonych zakresach oraz JSON w implementacji Symfony/API Platform. Dostępne operacje i zakresy sprawdź w zainstalowanym /admin-api/docs oraz dokumentacji Admin API.

Ścieżka tokenu to /admin-api/access_token. Podaj skonfigurowane poświadczenia klienta i wymagane zakresy, a następnie użyj zwróconego tokenu dostępu jako tokenu Bearer. Odczytaj termin ważności z odpowiedzi zamiast wpisywać na stałe jedną godzinę. Przy poświadczeniach klienta żądaj kolejnego tokenu w razie potrzeby; nie zakładaj przepływu z tokenem odświeżania.

Utwórz osobnego klienta dla integracji i przyznaj mu udokumentowane zakresy. Nie używaj ponownie klucza starszego Webservice ani nie zakładaj, że podobnie nazwany zasób używa tej samej ścieżki lub treści żądania. Przetestuj cały wymagany proces przed wyborem Admin API lub połączeniem obu API.

Diagnozuj odpowiedzi i zabezpiecz obie ścieżki dostępu do API

Porównaj ścieżkę API z bezpośrednim dispatcherem przy użyciu tego samego klucza i żądania. Przykłady używają opcji curl --fail, która ukrywa treści błędów HTTP: do diagnozy użyj --fail-with-body, jeśli Twoja wersja curl ją obsługuje, sprawdź status i treść odpowiedzi oraz usuń dane wrażliwe przed ich udostępnieniem. Sprawdź przekazywanie nagłówka Authorization, kontekst sklepu, uprawnienia metod, dokładne nazwy zasobów i zakodowane parametry zapytania.

Używaj osobnych poświadczeń, minimalnych uprawnień, HTTPS oraz udokumentowanego procesu rotacji i unieważniania. Gdzie to możliwe, ogranicz dostęp do znanych serwerów wywołujących. Obejmij dispatcher i przepisany URL odpowiednimi kontrolami dostępu i limitami żądań.

Loguj identyfikatory operacji, źródło, kierunek, czasy, status, ponowienia i przydatny błąd po usunięciu danych wrażliwych. W miarę możliwości używaj skrótów treści żądań lub ograniczonych danych diagnostycznych. Nigdy nie loguj kluczy, nagłówków Authorization ani zbędnych danych osobowych. Określ dostęp i czas przechowywania. Audyt API jest przydatnym zabezpieczeniem, a nie uniwersalnym prawnym nakazem zapisywania każdego odczytu zasobu.

Zaprojektuj odpowiedzialność za dane ERP, ponowienia i uzgadnianie danych

Zacznij od jednego systemu odpowiedzialnego za każde pole. Możliwy podział to dane produktów, cen i stanów zarządzane przez ERP, a zamówienia i zmiany danych klientów pochodzące z PrestaShop wysyłane na zewnątrz. Inna firma może powierzyć część tej roli PIM lub WMS. Udokumentuj to jawnie zamiast zakładać, że ERP zawsze ma pierwszeństwo.

Przechowuj stabilne zewnętrzne ID razem z lokalnymi ID. Nazwy nie są identyfikatorami, a indeksy można edytować lub powielać, jeśli nie wymusisz ich stabilności. Mapuj produkty i kombinacje osobno.

Używaj klucza idempotencji identyfikującego źródło, encję, operację oraz stabilne zdarzenie lub wersję. Ponowienie nie może powielać faktury ani pomniejszenia stanu, a późniejsza poprawna aktualizacja nadal musi zostać przetworzona. Oznaczaj powodzenie dopiero po ukończeniu i zachowuj błędy, które można obsłużyć ponownie.

Standardowe hooki PrestaShop to zdarzenia lokalne, a nie ogólna trwała usługa wychodzących webhooków. Używaj actionValidateOrder do zdarzenia utworzenia zamówienia przez moduł płatności. Używaj actionOrderStatusPostUpdate do jawnych zmian statusu z deduplikacją, a nie jako zamiennego wyzwalacza nowego zamówienia.

W przypadku actionProductUpdate niektóre wywołania zawierają tylko id_product. Pobierz i zweryfikuj Product, gdy nie przekazano obiektu, oraz uwzględnij właściwy kontekst sklepu i języka. Zdarzenia magazynowe wymagają identyfikatorów kombinacji i sklepu. Kolejkuj dostarczenie zamiast blokować zapis w panelu administracyjnym lub finalizację zakupu zdalnym żądaniem HTTP.

Podpisuj lub inaczej uwierzytelniaj zdarzenia wychodzące, używaj limitów czasu i ponowień oraz uwzględniaj dostarczanie duplikatów i zdarzeń poza kolejnością. Regularnie uzgadniaj stany i zamówienia. Raportuj rozbieżności i wprowadzaj korekty tylko zgodnie z udokumentowaną polityką odpowiedzialności za dane i rezerwacji.

Przykład: zamówienie dociera do magazynu, lecz odpowiedź ginie

Załóżmy, że system magazynowy odpowiada za stan dostępny do sprzedaży i dane wysyłki, a PrestaShop tworzy zamówienie klienta. Magazyn przyjmuje zamówienia do realizacji dopiero na uzgodnionym etapie płatności lub zatwierdzenia. Nowe zamówienie i zamówienie gotowe do realizacji to różne zdarzenia; zapisz regułę kwalifikacji, zamiast przekazywać każde utworzone zamówienie do kompletacji.

1. Proces roboczy odczytuje kwalifikujące się zamówienie, ustala mapowania kombinacji i przesyła zlecenie do magazynu ze stałym kluczem zamówienia źródłowego.
2. Magazyn je przyjmuje, ale połączenie przekracza limit czasu, zanim proces otrzyma identyfikator przyjęcia. Zachowaj element jako nierozwiązany; przekroczenie czasu nie dowodzi odrzucenia przez magazyn.
3. Wyszukaj klucz zamówienia źródłowego w magazynie. Jeśli istnieje, zapisz jego identyfikator przyjęcia. Jeśli odbiorca obsługuje bezpieczne ponawianie z tym kluczem, użyj udokumentowanego mechanizmu. W przeciwnym razie wymagaj uzgodnienia przed ponownym zgłoszeniem.
4. Po zapisaniu przyjęcia ponowne przetworzenie nie może tworzyć kolejnej kompletacji. Późniejsze anulowanie lub zmiana wymaga własnej operacji i potwierdzenia, zamiast zostać pominięte jako duplikat zamówienia.
5. Porównuj kwalifikujące się zamówienia źródłowe z przyjętymi zleceniami magazynowymi i wskazuj niedopasowane rekordy. Po otrzymaniu danych śledzenia dopasuj je niezależnie od pierwotnego cyklicznego pobierania zamówień.

Rozważ teraz migawkę stanów przygotowaną, zanim zamówienie dotarło do magazynu. Jeśli nadal zawiera sztukę odjętą przez sklep, zastosowanie jej bez zmian może ponownie udostępnić tę sztukę do sprzedaży. Ustalenia muszą określać oczekujące rezerwacje i kolejność migawek. Przetestuj to nakładanie z opóźnionym eksportem przed dopuszczeniem automatycznych korekt stanów.

Nie ma uniwersalnego adresu URL cron w rdzeniu. Wskaż rzeczywiste polecenie lub obsługiwany punkt końcowy modułu, mechanizm uruchamiania i alarm awarii. Cron Manager udostępnia zarządzanie obsługiwanymi zadaniami, zgodnie ze stroną pomocy; zaplanowanie zadania nie tworzy konektora ERP, mapowania ani logiki uzgadniania.

Oceń, czy potrzebujesz ERP, czy wystarczy mniejszy eksport

Szukaj powtarzalnego przepisywania zamówień, niewiarygodnych stanów, powolnego uzgadniania na koniec miesiąca, wielu kanałów sprzedaży i niejasnej odpowiedzialności za realizację. To objawy do zmierzenia, a nie próg liczby zamówień lub wielkości zespołu dowodzący, że potrzebujesz ERP.

1. Zapisz czas poświęcony na przepisywanie zamówień, faktur, adresów, stanów i numerów przesyłek w reprezentatywnym tygodniu.
2. Pomnóż te godziny przez pełny koszt pracy osób wykonujących zadania.
3. Zapisz rzeczywiste koszty korekt: zwroty towarów, podwójne faktury, zwroty środków, sprzedaż ponad stan i uzgadnianie danych.
4. Sprawdź, czy proces poradzi sobie z prawdopodobnym wzrostem, np. o 50% więcej zamówień. To scenariusz planistyczny, a nie próg branżowy.
5. Porównaj powtarzalne obciążenie z kosztami wdrożenia, licencji, hostingu, utrzymania, wsparcia i odzyskiwania po awarii.

Przetestuj eksport zamówień do księgowości przed zakupem ERP

Załóżmy, że zespół przepisuje pozycje zamówień do księgowości, a osobno dane dostawy do narzędzia magazynowego. Przetestuj eksport księgowy na pliku, który księgowy rzeczywiście może zaimportować. Jeśli usuwa wprowadzanie danych do księgowości, ale pozostawia wprowadzanie do magazynu i kontrolę zwrotów, policz tylko pracę, którą usuwa. Nie przypisuj eksportowi oszczędności wymagających późniejszej integracji.

Przed porównaniem przelicz miesięczne koszty błędów i subskrypcji na ten sam okres co tygodniowy rejestr czasu. Jeśli stałe oszczędności są dodatnie, lecz nie zwrócą kosztu wdrożenia w okresie planowania, zawęź zakres lub zachowaj powtarzalny proces ręczny. Jeśli w kosztach dominują powtarzające się błędy stanów, sam eksport księgowy nie rozwiąże głównego problemu. Przy mapowaniu dokumentów skorzystaj z poradnika księgowości i faktur.

Powtarzalny ręczny eksport plików może rozwiązać jedno wąskie gardło. Zaplanowana wymiana wymaga rzeczywistego wspieranego mechanizmu uruchamiania. Nie ma stałej granicy 100 zamówień dziennie między plikami, automatyzacją i ERP.

Orders CSV List Exporter zapewnia uwierzytelnione eksporty z panelu administracyjnego oraz zaplanowane dostarczanie e-mailem lub na serwer; zanim oprzesz się na eksportach bez nadzoru, potwierdź opcje harmonogramu zainstalowanej wersji, wymagany mechanizm uruchamiania i odbiorców.

Możliwości eksportu specyficzne dla faktur opisuje strona pomocy Invoice CSV List Exporter.

Nadaj priorytet zmierzonemu problemowi. Przekazywanie zamówień do księgowości, aktualizacje stanów, śledzenie przesyłek i rekordy klientów mają różne mapowania i ryzyka. Wyznacz osobę odpowiedzialną za monitorowanie integracji po uruchomieniu. Jedno źródło decydujące o stanach poprawia przejrzystość, ale samo nie eliminuje sprzedaży ponad stan.

Porównaj Zapier, Make i bezpośrednią integrację

Użyj platformy automatyzacji, jeśli dostępne aplikacje i obsługa błędów pasują do procesu. Sprawdź aktualny katalog aplikacji, obsługiwane operacje i wersję PrestaShop, zamiast zakładać, że oficjalny konektor istnieje lub nie może istnieć, bo sklep działa na własnym hostingu. Porównaj też aplikację docelową: Make może udostępniać potrzebną operację sklepu, podczas gdy Zapier lepiej obsługuje drugie narzędzie, albo odwrotnie. W Zapier proces nazywa się Zap, a w Make scenariusz. Przetestuj cały łańcuch na przykładowych danych, zamiast wybierać według liczby aplikacji.

Make udostępnia aplikację PrestaShop. Nie traktuj modułu Watch jak natychmiastowego webhooka bez sprawdzenia typu wyzwalacza. Ogólny dostęp HTTP jest alternatywą, gdy aplikacja nie udostępnia potrzebnego zasobu.

Zapier rozlicza zadania zgodnie z zasadami planu. Make używa obecnie kredytów: zwykłe operacje bez AI zazwyczaj zużywają jeden kredyt, a niektóre funkcje mają inne zasady rozliczania. Porównaj reprezentatywny przebieg obejmujący wyszukiwania, pętle, puste sprawdzenia, ponowienia i dalsze działania. Nie używaj starych cenników opartych na operacjach jako aktualnych cen.

Przy przykładowym obciążeniu 200 zamówień dziennie pomnożone przez pięć działań i przez 30 dni daje 30 000 wykonań działań. Nie oznacza to automatycznie 30 000 jednostek rozliczeniowych w żadnej z usług; zastosuj aktualne zasady rozliczania. Moduł natywny nadal wiąże się z kosztami hostingu, utrzymania i ewentualnych usług zewnętrznych.

Make publikuje wychodzące adresy IP dla poszczególnych stref bez zakładanego ograniczenia do płatnego planu. Zapier dokumentuje obsługę statycznych IP w planie Professional i wyższych dla określonych aplikacji, w tym Webhooks. Używaj aktualnej listy dla rzeczywistej aplikacji i strefy.

Zachowaj precyzję księgową, rezerwacje magazynowe i złożone kombinacje w procesie, który poprawnie je implementuje. To, że narzędzie działa lokalnie lub używa hooka, nie gwarantuje natychmiastowego dostarczenia, niższych kosztów ani dostępności podczas awarii innego dostawcy.

Mailchimp Integration synchronizuje członkostwo w liście odbiorców po wyrażeniu zgody i ponawia nieudane synchronizacje kontaktów, zamiast synchronizować katalog, segmenty lub zamówienia, jak wyjaśnia strona pomocy modułu. Sprawdź obsługę zapisów i rezygnacji przed podłączeniem kolejnego źródła zapisującego odbiorców; samo istnienie konta klienta nie oznacza polecenia zapisania go na listę.

Zbuduj i obsługuj kompletną pierwszą automatyzację

Prosty pierwszy proces to powiadomienie o zamówieniu lub wiersz raportu. Przy próbie z arkuszem ustaw uwierzytelnianie Basic w polach poświadczeń platformy, używając klucza Webservice jako nazwy użytkownika i pustego hasła, pobierz wymagane pola zamówień, przetwórz każde zwrócone zamówienie i zmapuj sklep, ID zamówienia, numer referencyjny i bieżący status do działania tworzącego wiersz w arkuszu. Zastosuj poniższą listę kontroli odzyskiwania: oznaczenie elementu jako widzianego przez wyzwalacz cykliczny nie dowodzi ukończenia działania docelowego. Zachowaj tryb tylko do odczytu podczas weryfikacji poświadczeń, mapowania danych i obsługi błędów. Unikaj ujawniania pełnych danych klienta w wiadomości zespołowej, jeśli wystarczą numer zamówienia i bezpieczny link do panelu.

1. Wybierz obsługiwany wyzwalacz cyklicznego pobierania lub harmonogram. Schedule by Zapier dokumentuje wyzwalacze godzinowe i rzadsze; nie jest ogólnym wyzwalaczem co 15 minut.
2. W przypadku cyklicznego pobierania sprawdź Webhooks by Zapier Retrieve Poll i odstęp obsługiwany przez konto albo zaimplementuj ograniczone zapytanie według harmonogramu.
3. Odczytuj wszystkie zamówienia powyżej zapisanego punktu kontrolnego w kolejności rosnącej i przeglądaj kolejne strony. Mapuj wybrane pola albo jawnie pobrane pełne zasoby.
4. Przetwarzaj każde zamówienie ze stabilnym kluczem deduplikacji. Trwale zapisuj wynik docelowy i przesuwaj stan dopiero po bezpiecznym zarejestrowaniu działania.
5. Przetestuj liczbę zamówień większą niż jedna strona, zduplikowane zdarzenie, przekroczenie czasu i nieudane działanie docelowe.
6. Włącz alerty o błędach i zapisz osobę odpowiedzialną za proces, poświadczenia, harmonogram, mapowania i procedurę odzyskiwania.

Przy dostarczaniu push moduł musi wysłać właściwe zdarzenie do Catch Hook odbiornika lub równoważnego URL. Instalacja odbiornika nie sprawia, że PrestaShop emituje zdarzenia wychodzące. Rozróżniaj wiadomości o zmianie statusu i utworzeniu zamówienia.

W procesach zapisujących dane zwrotnie waliduj XML i używaj właściwego zasobu, kombinacji i sklepu. Formularzowy edytor automatyzacji nie zwalnia z rozumienia PUT, PATCH, podatków ani skutków dla zamówienia. Wychodząc poza odczyt, przechowuj poświadczenia zapisu osobno i udostępniaj je tylko procesowi, który ich potrzebuje. Jeśli edytor nie potrafi zachować zasobu dostępnego do zapisu lub bezpiecznie obsłużyć niepewnego zapisu, użyj w tym kroku utrzymywanego łącznika lub operacji aplikacji.

Regularnie sprawdzaj historię wykonań, również po aktualizacjach sklepu lub modułów. Testuj pocztę klientów przez zamierzony transport sklepu lub dostawcy, zamiast przypadkowo dodawać drugą ścieżkę potwierdzenia zamówienia. Uruchamiaj produkcyjnie po jednym procesie, z jasnym sposobem zatrzymania i bezpiecznego ponowienia pracy. Zachowaj przykładową poprawną odpowiedź i oczekiwany wynik docelowy do kontroli regresji po aktualizacjach. Zmiana struktury pola lub puste mapowanie może pozostawić żądanie HTTP poprawne, a mimo to utworzyć niepełny rekord docelowy. Kontrolę transportu poczty opisuje poradnik konfiguracji e-maili.

O co zapytać programistę lub agencję

Przekaż wykonawcy przykładowe rekordy ze sklepu i systemu odbierającego, opis obecnego procesu ręcznego oraz efekt, który ma widzieć zespół. Uwzględnij trudne przypadki z własnych danych: kombinacje, rabaty, różne ujęcia podatków, zwroty, zmienione adresy i dzieloną realizację, jeśli jest używana. Poproś o pisemne odpowiedzi na te pytania przed przyjęciem zakresu wdrożenia.

• Co już pasuje? Który zainstalowany konektor, natywny eksport lub obsługiwaną operację API można wykorzystać i jakie dokładnie wymaganie wymaga programowania?
• Jakie jest mapowanie? Które pola źródłowe stają się którymi polami docelowymi, z jaką walutą, podstawą podatkową, zaokrągleniami, językiem i kontekstem sklepu? Kto zatwierdza odrzucone lub niejednoznaczne dopasowanie?
• Kiedy zadanie kwalifikuje się do wykonania? Jakie zdarzenie płatności lub zamówienia upoważnia do eksportu, co oznacza przyjęcie i jak przedstawiane są późniejsze zmiany, zwroty oraz anulowania?
• Jaki jest wymagany czas dostarczenia? Określ dopuszczalne opóźnienie całego procesu, przewidywane obciążenie, zaległości po awarii i cel odzyskiwania. Mierz ukończenie w systemie docelowym, a nie sam harmonogram pobierania.
• Jak działa wsparcie? Kto odpowiada za poświadczenia, kod, mapowania i hosting, kto reaguje na awarie i kto ponawia testy po aktualizacji sklepu, modułu lub API odbiorcy? Uwzględnij dostęp do źródeł, instrukcji i zapisów odzyskiwania przy przekazaniu.

Uzgodnij dowody odbioru

Przećwicz zmianę i zaplanuj przełączenie produkcyjne

1. Przygotuj odizolowaną kopię. Zastąp skopiowane klucze produkcyjne i adresy URL odbiorców, wyłącz produkcyjne wysyłki według harmonogramu i skieruj pocztę do odbiorcy testowego. Przed tworzeniem zamówień próbnych sprawdź każdą ścieżkę wychodzącą, w tym istniejące moduły.
2. Ustal punkt odniesienia. Zapisz wersje, ustawienia, mapowania, bieżący postęp integracji i reprezentatywne wyniki stanów oraz zamówień. Potwierdź możliwość przywrócenia odpowiednich kopii zapasowych i zachowaj konfigurację potrzebną do powrotu do poprzedniego rozwiązania.
3. Wykonaj przypadki odbiorcze. Używaj jednorazowych rekordów testowych i kont testowych po stronie odbiorcy. Uwzględnij rzeczywistą finalizację zakupu, moduły płatności i działania zespołu, aby zdarzenia i skutki uboczne pochodziły ze ścieżki używanej na produkcji.
4. Wyznacz granicę przekazania. Przy wymianie integracji uzgodnij ostatni ukończony element lub okno należące do starego procesu oraz pierwsze należące do nowego. Przenieś oczekujące błędy i mapowania oraz zapobiegaj zapisowi tych samych pól przez oba procesy podczas przełączenia.
5. Przełącz w uzgodnionym terminie. Zapisz postęp, wstrzymaj poprzedni proces zapisujący, zastosuj sprawdzoną konfigurację i włącz nowy mechanizm uruchamiania. Sprawdzaj przyjęcie u odbiorcy i wiek kolejki, a także poprawne odpowiedzi HTTP. Wskaż osobę, która może zatrzymać zmianę, jeśli odbiór się nie powiedzie.
6. Prowadź rejestr odzyskiwania. Zachowuj żądania przyjęte po obu stronach granicy. Wycofanie może przywrócić kod lub ustawienia, lecz przyjęte faktury, kompletacje, e-maile i zmiany stanów wymagają własnego uzgodnienia. Wznawiaj poprzedni proces zapisujący wyłącznie od sprawdzonej granicy uwzględniającej już ukończoną pracę.

Po przełączeniu porównaj kwalifikującą się pracę źródłową, przyjęte rekordy docelowe i nierozwiązane błędy za ten sam okres. Sprawdzaj najstarszy nieprzetworzony element i ostatnie ukończone uzgodnienie, a nie tylko ostatni planowy start. Ustal, kto obsługuje alarm i kiedy go eskalować; sam zielony status harmonogramu nie dowodzi zakończenia wymiany biznesowej.

Pytania właścicieli sklepów

Czy muszę wymienić obecny ERP?

Najpierw sprawdź, czy może odbierać i zwracać dane określone w kontrakcie przez obsługiwany konektor, pliki lub API. Brak połączenia może uzasadniać mały łącznik; zmiana systemu zaplecza wymaga osobnego uzasadnienia biznesowego.

Czy mogę to zrobić bez programisty?

Okazjonalny eksport lub powiadomienie tylko do odczytu mogą być wykonalne przy użyciu obecnych narzędzi. Zanim powierzysz edytorowi zapis, sprawdź, czy potrafisz wyjaśnić i naprawić jego błędy. Użyj tabeli wyboru rozwiązania na początek i tabeli odbioru do oceny wyniku.

Czy zmiana motywu naprawi integrację?

Najpierw ustal przyczynę brakującego pola lub zdarzenia. Błąd mapowania API wymaga poprawienia danych. Dostosowana finalizacja zakupu zmieniająca tworzenie zamówień wymaga testów z integracją, więc zachowaj istotne zachowanie motywu i finalizacji zakupu na kopii próbnej.

Czy mogę testować, wysyłając prawdziwe zamówienie do magazynu?

Najpierw uzgodnij z odbiorcą konto testowe lub kontrolowaną procedurę. Skopiowane zamówienie może nadal spowodować rzeczywistą kompletację, fakturę lub wiadomość do klienta, jeśli nadawca testowy używa poświadczeń produkcyjnych.

Czy wyłączenie modułu cofa to, co wysłał?

Nie. Użyj rejestru odzyskiwania z listy kontrolnej przełączenia, aby wskazać przyjętą pracę i uzgodnić wymagane anulowanie lub korektę w odpowiedzialnym za nią systemie przed wznowieniem innego procesu zapisującego.

Co powinienem otrzymać przy przekazaniu?

Uzgodnione mapowania, przetestowane przypadki, instrukcje mechanizmu uruchamiania i poświadczeń, wskazanie odpowiedzialności za alarmy oraz zademonstrowaną procedurę zatrzymania i odzyskiwania. Osobno potwierdź odpowiedzialność za przyszłe prace nad zgodnością i ich koszt, oddzielając je od naprawiania wad w dostarczonym zakresie.