Jak połączyć PrestaShop z Allegro? Zakres, konfiguracja i testy

Aby połączyć PrestaShop z Allegro, najpierw ustal, co ma przepływać między systemami. Import produktów do sklepu, powiązanie istniejących ofert, aktualizacja stanów, pobieranie zamówień i nadawanie przesyłek to różne zadania. Hasło „pełna integracja” nie potwierdza żadnego z nich bez opisu kierunku danych i testu.

Ten poradnik pomaga przygotować konfigurację oraz odbiór. Nazwy ekranów i możliwości opisuje dokumentacja konkretnego produktu i jego wersji. Uzgodniona mapa przepływów pozwala sprawdzić, czy ustawienia panelu pokrywają cały wymagany proces.

Zakres wykonania i wycenę znajdziesz na stronie integracji Allegro z PrestaShop. Poniżej wyjaśniamy, jak rozpoznać potrzebny zakres i sprawdzić jego działanie.

Pięć przepływów: co dokładnie ma robić integracja?

Przykład praktyczny: masz aktywne oferty na Allegro, ale pusty sklep PrestaShop. Potrzebujesz importu katalogu, porządkowania danych oraz późniejszego połączenia produktów z ofertami. Jeśli sklep ma już produkty, drugi import może stworzyć duplikaty — wówczas pierwszym zadaniem jest mapowanie. To dwie różne wyceny i dwa różne zestawy testów.

Nie jest to wyłącznie teoretyczna różnica: producent modułu Allegro x13 w opisie odczytanym 3 września 2026 r. oddziela integrację od importu produktów z Allegro do PrestaShop. Sprawdź dokumentację kupowanej wersji zamiast przenosić zakres jednego dodatku na wszystkie integratory.

Moduł bezpośredni, hub czy własna integracja?

Poproś o potwierdzenie zgodności z dokładną wersją PrestaShop i PHP, licencję, zakres aktualizacji i sposób obsługi awarii. Cena licencji nie jest kosztem całego procesu. Porównaj konfigurację, porządkowanie katalogu, testy, abonament, utrzymanie oraz ewentualne opłaty za dodatkowe funkcje. Nie traktuj niepodanej ceny jako zera.

Autoryzacja Allegro: użytkownik integratora to nie autor aplikacji

W gotowym module lub hubie sprzedawca powinien autoryzować dostęp w przepływie OAuth dostawcy. Aktualna dokumentacja Allegro wskazuje, że aplikacje nie mogą żądać od użytkowników ich Client_ID i Client_Secret; powinny posługiwać się własnymi danymi aplikacji. Nie wklejaj sekretów do przypadkowego formularza na podstawie starego poradnika.

Rejestracja aplikacji dotyczy jej autora, np. przy tworzeniu własnego połączenia. Wtedy należy wdrożyć odpowiedni przepływ autoryzacji, zakresy uprawnień i obsługę tokenów zgodnie z dokumentacją. Sam przepływ client_credentials nie daje dostępu do prywatnych zamówień sprzedawcy.

Źródło: uwierzytelnianie i autoryzacja w Allegro REST API, stan sprawdzony 3 września 2026 r.

• Przed zgodą zweryfikuj nazwę aplikacji, właściwe konto sprzedawcy i zakres żądanych uprawnień. Zapisz osobę odpowiedzialną za dostęp.
• Nie zapisuj sekretów ani pełnych tokenów w zgłoszeniach, publicznym repozytorium czy logach dostępnych dla klienta. Materiały diagnostyczne powinny być zanonimizowane.
• Oddziel autoryzację testową od produkcyjnej. W odbiorze uwzględnij utratę uprawnień, odświeżenie dostępu i alert do osoby, która może ponownie udzielić zgody.

Produkty i istniejące oferty: najpierw mapa identyfikatorów

Zbuduj tabelę połączeń: identyfikator oferty Allegro → identyfikator produktu PS → identyfikator kombinacji → identyfikator w systemie nadrzędnym. SKU i EAN mogą pomagać w dopasowaniu, lecz trzeba sprawdzić ich kompletność i jednoznaczność. Brakujący lub powielony kod powinien trafić do kolejki wyjaśnień, nie do automatycznej publikacji.

• Dla importu katalogu wybierz próbkę obejmującą prosty produkt, wariant, brak kodu, obraz i produkt już obecny w sklepie. Ustal, które pola wolno tworzyć, a których nie wolno nadpisywać.
• Dla istniejącej oferty potwierdź powiązanie i wynik na próbce przed włączeniem masowej synchronizacji. Sprawdź także nieaktywne oferty oraz sytuację, gdy jeden produkt występuje w kilku ofertach.
• Rozdziel treść sklepu od treści marketplace. Import nie powinien bez uzgodnienia nadpisywać ręcznie opracowanych opisów, title, zdjęć i adresów produktów.

Właściciel każdego pola: jak uniknąć zapisu w pętli

Właściciel danych to system, który rozstrzyga wartość danego pola. Integrator może ją przekazywać, ale nie powinien jednocześnie konkurować o zapis z innym modułem. Uzgodnij regułę osobno dla stanów, rezerwacji, cen, opisów i realizacji. Poniższy wariant jest autorską demonstracją architektury, nie uniwersalną konfiguracją każdego sklepu.

Taka mapa zapobiega nieporozumieniu „włączmy synchronizację w obie strony”. Dla konkretnego wdrożenia dopisz, co dzieje się przy braku stanu, opóźnieniu, ręcznej korekcie, anulowaniu i zwrocie. Nie wyłączaj globalnie zmniejszania magazynu jako pierwszej reakcji na duplikat — najpierw ustal, który system wykonał ruch i dlaczego.

Zamówienia: zdarzenie, płatność i realizacja to różne rzeczy

W dzienniku Allegro /order/events BOUGHT oraz READY_FOR_PROCESSING są typami zdarzeń, a nie nazwami statusów zamówienia w PrestaShop. BOUGHT nie potwierdza opłacenia. READY_FOR_PROCESSING może obejmować również pobranie lub odpowiedni odbiór osobisty, więc nie należy utożsamiać go automatycznie z wpłatą.

Stan płatności, status zamówienia i fulfillment.status opisują różne aspekty. Mapowanie do PrestaShop musi uwzględniać metodę płatności i ustalony proces realizacji. Zdarzenia mogą się powtarzać lub docierać w innej kolejności; to samo checkoutForm.id nie powinno tworzyć kolejnego zamówienia przy każdym odbiorze.

Podstawę tych rozróżnień i obsługi powtórzeń opisuje oficjalny poradnik obsługi zamówień Allegro. Sprawdź mapowanie w dokumentacji konkretnego integratora, nie tylko podobieństwo nazw statusów.

Przed uruchomieniem przygotuj listę: jakie zdarzenie rozpoczyna import, kiedy powstaje rezerwacja, co zatwierdza płatność, kto tworzy dokument i kto decyduje o wysyłce. Stan po anulowaniu lub zwrocie zależy od etapu obsługi; nie przywracaj ilości bez sprawdzenia, czy towar został wysłany i czy inny system już wykonał korektę.

Wysyłam z Allegro: etykieta to osobny proces odbioru

Dla Wysyłam z Allegro sprawdź obsługę wyboru usługi, utworzenia przesyłki, pobrania etykiety oraz ewentualnego zamówienia podjazdu. Przetestuj właściwą metodę dostawy i dane odbiorcy. Numer listu przewozowego w zamówieniu nie jest sam w sobie dowodem poprawnego utworzenia i obsługi przesyłki.

Istotne dla utrzymania na przełomie 2026/2027: dokumentacja Allegro zapowiada wyłączenie GET /shipment-management/delivery-services w I kwartale 2027 r. i opisuje pobieranie propozycji dostawy przez /shipment-management/delivery-proposals/{orderId}. Zapytaj dostawcę, jakiej ścieżki używa Twoja wersja integracji; nie traktuj endpointu jako już wyłączonego we wrześniu 2026 r.

Źródło i aktualizacje: zarządzanie przesyłkami przez Wysyłam z Allegro.

Wypełniona próba po awarii: zamówienie nie może wykonać się dwa razy

Poniżej znajduje się demonstracyjny scenariusz odbioru, nie raport z wykonanych testów ani opis klienta. Syntetyczny produkt DEMO-M ma 5 sztuk dostępnych. W tym przykładzie ERP jest jedynym właścicielem rezerwacji, a jedno zamówienie DEMO-01 rezerwuje 1 sztukę. Założenia trzeba zastąpić własnymi regułami przed rzeczywistą próbą.

Przetestuj również niepewny wynik nadania przesyłki: po przerwaniu połączenia sprawdź wynik istniejącej operacji zgodnie z możliwościami API, zanim utworzysz kolejną. Mechanizm rozpoznawania ponowień dla zamówień nie oznacza automatycznie, że identycznie działa on dla etykiet, płatności lub każdego innego zapisu.

Plan uruchomienia: próbka, ograniczony zakres, pełne włączenie

• Przed startem zapisz istniejące mapowania, konfigurację i punkt rozpoczęcia importu zamówień. Ustal, czy starsze zamówienia mają być pomijane, pobrane wyłącznie do podglądu czy obsługiwane.
• Na próbce obejmij produkt prosty, wariant, brak mapowania, zmianę ceny, stan zero, ponowione zamówienie, płatność i wysyłkę. Wykonuj operacje testowe w uzgodnionym środowisku.
• Włącz uzgodnione przepływy dla ograniczonego zakresu i porównaj wynik. Dopiero po odbiorze rozszerz synchronizację; nie rozpoczynaj od masowego nadpisania całego katalogu.
• Wyznacz warunki zatrzymania zapisów: nieznane mapowanie, rozbieżne stany, duplikat skutku finansowego lub brak możliwości uzgodnienia zamówień. Ustal osobę, która podejmuje decyzję.
• Powrót do poprzedniej konfiguracji nie cofa automatycznie zmian wykonanych w Allegro lub ERP. Zapisz sposób uzgodnienia takich skutków i zachowaj log zmian.

Co monitorować po uruchomieniu?

Raport techniczny powinien pokazywać opóźnienie kolejki, ostatni poprawny przebieg, liczbę błędów, nierozpoznane mapowania oraz rozbieżności stanów i zamówień. Każdy alert musi mieć właściciela. Harmonogram sprawdzeń i dopuszczalne opóźnienie uzgodnij z procesem sprzedaży; sam zielony status zadania nie potwierdza poprawnych danych.

Efekt biznesowy mierz osobno: czas obsługi, anulowania z powodu braku towaru, koszty narzędzi, rozliczone opłaty i marżę zamówień danego kanału. Techniczna integracja nie gwarantuje nowych klientów, określonej marży ani wzrostu widoczności sklepu w Google.

Jeżeli równolegle modernizujesz silnik, wykorzystaj plan aktualizacji PrestaShop 1.7 do 8/9. Zasady prezentowania obniżek wymagają osobnej oceny — zobacz poradnik Omnibus w PrestaShop. Nie utożsamiaj synchronizacji ceny z automatyczną zgodnością prawną.

Brief do wyceny integracji

Wyślij wersje sklepu i dodatków, nazwę obecnego huba lub ERP, informację o istniejących ofertach i produktach, liczbę kont oraz listę pięciu przepływów, które mają działać. Dodaj przykłady problematycznych wariantów i opis właściciela stanów. Wskaż wymagany proces nadania, zakres monitoringu i osobę odpowiedzialną za odbiór.

Taki brief pozwala rozdzielić konfigurację od importu i prac niestandardowych. Przejdź do zakresu integracji Allegro z PrestaShop bez przesyłania haseł ani sekretów przez formularz.