PrestaShop 9 ma teraz dwa różne API do wyboru przy budowie architektury headless. Stare API Webservice, dostępne od dawna, oparte o klucz API i format XML. Oraz nowe Admin API, zbudowane na frameworku API Platform, z autoryzacją OAuth 2.0, zaprojektowane od podstaw pod integracje headless. Wybór między nimi nie jest kosmetyczny — wpływa na bezpieczeństwo, wydajność i to, jak łatwo utrzymacie frontend w Next.js w dłuższej perspektywie. Poniżej pokazujemy, kiedy użyć którego i jak zbudować na tym solidną architekturę.
Stare API Webservice — sprawdzone, ale ograniczone
API Webservice działa w PrestaShop od wielu lat i wciąż jest w pełni funkcjonalne w wersji 9, ze względu na kompatybilność wsteczną. Żeby z niego skorzystać, trzeba najpierw włączyć je w panelu administracyjnym, w sekcji Parametry Zaawansowane → Webservice. Bez tego kroku każde zapytanie zwróci błąd.
Domyślnie API zwraca dane w formacie XML. Żeby dostać JSON, wygodniejszy do pracy z Next.js, trzeba dodać parametr output_format=JSON do zapytania albo wysłać nagłówek Accept: application/json. Autoryzacja opiera się na statycznym kluczu API, generowanym w panelu — prostym w konfiguracji, ale trudniejszym w bezpiecznym zarządzaniu niż nowoczesne tokeny.
To API sprawdza się dobrze przy zadaniach związanych głównie z danymi — migracjach, integracjach księgowych, eksportach produktów i zamówień. Dla pełnoprawnego, wydajnego frontendu headless bywa jednak ograniczające.
Nowe Admin API — zaprojektowane pod headless commerce
PrestaShop 9 wprowadził osobne, nowoczesne Admin API, zbudowane na API Platform — frameworku PHP dedykowanym do budowy nowoczesnych API REST. Kluczowa różnica: autoryzacja przez OAuth 2.0 zamiast statycznego klucza. To standard bezpieczniejszy i bardziej elastyczny — pozwala na precyzyjne nadawanie uprawnień (scope’ów) zamiast dawania pełnego dostępu jednym kluczem.
Nowe API zostało pomyślane wprost pod scenariusze, które interesują firmy budujące architekturę headless: własne frontendy w React, Vue czy Next.js, aplikacje mobilne połączone z tym samym sklepem, integracje z ERP i CRM, oraz własne dashboardy analityczne (np. w Power BI, Metabase czy Grafanie), budowane na danych ze sklepu bez polegania wyłącznie na wbudowanych statystykach PrestaShop.
Które API wybrać do nowego projektu
- Istniejąca integracja, która już działa na starym API Webservice — nie trzeba migrować natychmiast. Stare API pozostaje wspierane w PS9.
- Nowy frontend headless budowany od zera — warto zacząć od razu od nowego Admin API. Lepsza autoryzacja, nowocześniejsza architektura, i to na nim będzie się opierał dalszy rozwój platformy.
- Proste, jednorazowe zadania związane z danymi (eksport, migracja, integracja księgowa) — stare API Webservice nadal wystarcza i jest prostsze do szybkiego wdrożenia.
Architektura frontendu w Next.js — czego nie da się pominąć
Sam dostęp do API to dopiero połowa pracy. Żeby headless commerce na PrestaShop działał szybko i dobrze indeksował się w wyszukiwarkach, warto zaplanować strategię renderowania świadomie, nie domyślnie:
- ISR (Incremental Static Regeneration) dla stron produktowych — strony generują się statycznie, ale odświeżają automatycznie po określonym czasie, bez potrzeby przebudowy całej strony przy każdej zmianie ceny czy dostępności.
- SSG (Static Site Generation) dla treści statycznych — strony kategorii, CMS, regulaminy — renderowane raz, serwowane błyskawicznie.
- Mechanizm rewalidacji po zmianie danych w PrestaShop — jeśli cena produktu zmienia się w panelu administracyjnym, frontend potrzebuje sposobu, żeby się o tym dowiedzieć i odświeżyć stronę, zamiast pokazywać nieaktualne dane aż do końca cyklu ISR.
To dokładnie ten sam mechanizm wydajnościowy, o którym pisaliśmy przy okazji artykułu o kosztach sklepu B2B w architekturze headless — tu pokazujemy, jak wygląda w praktyce konkretnie na PrestaShop.
Bezpieczeństwo — na co zwrócić uwagę przy integracji
Klucz API czy token OAuth nigdy nie powinien trafić do kodu frontendowego widocznego w przeglądarce — musi zostać po stronie serwera, w warstwie pośredniej między Next.js a PrestaShop. To ten sam problem, o którym pisaliśmy w artykule o audycie vibe codingu — wyeksponowane klucze dostępowe to jeden z najczęstszych, najkosztowniejszych błędów w aplikacjach budowanych szybko, bez odpowiedniej warstwy zabezpieczeń.
Przy starym API Webservice warto regularnie rotować klucz i ograniczać jego uprawnienia tylko do zasobów faktycznie potrzebnych integracji. Przy nowym Admin API warto korzystać z precyzyjnych scope’ów OAuth, zamiast nadawać pełny dostęp administracyjny tam, gdzie wystarczy odczyt danych produktowych.
Przykład z praktyki (Klient P, dystrybutor artykułów technicznych — przykład poglądowy, dane uśrednione dla tej skali projektu)
Firma miała działający sklep na PrestaShop 8, zintegrowany ze starym API Webservice do synchronizacji z ERP. Przy migracji frontendu na architekturę headless w Next.js zdecydowano się zachować istniejącą integrację ERP opartą na starym API (bo działała stabilnie), a nową warstwę frontendową połączyć z nowym Admin API — korzystając z OAuth do bezpiecznej autoryzacji i precyzyjnych uprawnień dla samego frontendu, oddzielnych od uprawnień integracji ERP.
Taki podział — stare API dla istniejącej, stabilnej integracji, nowe API dla nowego frontendu — pozwolił uniknąć ryzykownej, jednoczesnej migracji wszystkiego naraz, przy pełnym wykorzystaniu korzyści nowej architektury tam, gdzie miało to największe znaczenie.
FAQ
Czy stare API Webservice w PrestaShop 9 zostanie wycofane? Nie ma takiej zapowiedzi na dziś — pozostaje funkcjonalne ze względu na kompatybilność wsteczną. Nowe integracje warto jednak budować na nowym Admin API, które jest kierunkiem rozwoju platformy.
Czym różni się autoryzacja OAuth 2.0 od klucza API? Klucz API to pojedynczy, statyczny sekret dający dostęp do zasobów. OAuth 2.0 pozwala na precyzyjne nadawanie uprawnień (scope’ów) konkretnej integracji oraz łatwiejsze odwoływanie dostępu bez wpływu na inne integracje korzystające z tego samego systemu.
Czy trzeba migrować istniejącą integrację ze starego API na nowe Admin API? Nie natychmiast. Stare API działa w PS9 bez zmian. Migracja ma sens, gdy planujecie większą przebudowę integracji albo budujecie coś nowego od zera.
Jak PrestaShop headless wpływa na SEO w porównaniu do klasycznego motywu? Sama architektura headless nie gwarantuje lepszego SEO automatycznie — to świadoma implementacja (ISR, SSG, poprawne metadane) realnie poprawia szybkość i widoczność, dokładnie tak jak pisaliśmy przy okazji porównania Next.js i Nuxt.js.
Czy można zbudować headless PrestaShop bez dodatkowych modułów z Marketplace? Tak, natywne API (stare i nowe) wystarczają do podstawowej integracji. Dodatkowe moduły z Marketplace (np. dedykowane rozszerzenia REST API) upraszczają pracę i dodają gotowe funkcje, ale nie są niezbędne do samego połączenia frontendu z backendem.
Planujecie migrację istniejącego sklepu PrestaShop na architekturę headless albo budowę nowego frontendu w Next.js? Sprawdźcie naszą ofertę wdrożeń e-commerce — jako certyfikowany PrestaShop Expert pomożemy zaprojektować integrację opartą na właściwym API dla Waszego konkretnego przypadku.
