PrestaShop-9-Admin-API: Praxisleitfaden für Entwickler
Die neue PrestaShop-9-Admin-API ist eine der wichtigsten architektonischen Neuerungen der PrestaShop-9-Generation.
Sie soll die ältere Webservice-API durch ein moderneres Sicherheitsmodell, geschäftsorientierte Operationen und eine durch Module erweiterbare Architektur verbessern.
Die neue API basiert auf:
- API Platform 3;
- OAuth2 Authentifizierung und Autorisierung;
- CQRS-Befehlen und -Abfragen;
- Berechtigungsbereichen;
- OpenAPI-/Swagger-Dokumentation;
- von Modulen definierten API-Ressourcen.
Daher ist sie besonders interessant für Entwickler, die Folgendes entwickeln:
- ERP-Integrationen;
- PIM-Integrationen;
- Bestandssynchronisierung;
- Lieferantenplattformen;
- SaaS-Anbindungen;
- Bestellverwaltungssysteme;
- Reporting-Dienste;
- Automatisierungswerkzeuge.
Dieser Leitfaden erklärt die Architektur, die Authentifizierung, das Anlegen von Clients und die Möglichkeiten für Modulentwickler, auf der API aufzubauen.
Versionshinweis: Dieser Artikel wurde am 22. September 2026 anhand der aktuellen PrestaShop-9-Entwicklerdokumentation überprüft. Die Admin-API entwickelt sich laufend weiter; prüfen Sie immer die generierte OpenAPI-Spezifikation der tatsächlich integrierten Shopversion.
Warum PrestaShop eine neue Admin-API entwickelt hat
Die ältere Webservice-API von PrestaShop ist eng mit bisherigen CRUD-Operationen nach dem ObjectModel-Muster verbunden.
Das PrestaShop-Projekt nennt mehrere Einschränkungen dieses älteren Ansatzes:
- eingeschränkte Berechtigungs- und Sicherheitsverwaltung;
- einfaches CRUD-Verhalten;
- ältere Architektur;
- schwierigere Wartung;
- enge Kopplung an ObjectModel.
Die neue Admin-API verfolgt andere Ziele.
Sie soll:
- sicherer;
- leichter prüfbar;
- stärker auf Geschäftsoperationen ausgerichtet;
- näher an modernen Standards;
- durch Module erweiterbar sein.
Das ist wichtig.
Eine moderne E-Commerce-API sollte nicht bloß Datenbankeinträge bereitstellen.
Sie sollte Operationen bereitstellen, die aus Geschäftssicht verständlich sind.
API Platform 3 als HTTP-/API-Grundlage
PrestaShop 9 verwendet API Platform 3 für die neue Admin-API.
API Platform bietet Infrastruktur für:
- Routen;
- API-Ressourcen;
- Serialisierung;
- Validierung;
- OpenAPI-Generierung;
- Swagger UI;
- Providern;
- Prozessoren.
PrestaShop integriert anschließend seine eigene Anwendungsarchitektur in dieses Framework.
Das Ergebnis ist nicht einfach das standardmäßige CRUD von API Platform.
Integrierte Endpunkte können CQRS-Abfragen und -Befehle von PrestaShop aufrufen.
CQRS: Lese- und Schreibvorgänge als Geschäftsoperationen
PrestaShop setzt seit der Symfony-Migration auf CQRS.
CQRS trennt Operationen, die:
Daten lesen
von Operationen, die:
Zustand ändern
Die Admin-API nutzt diese Arbeit erneut.
Gemäß der offiziellen Architektur:
- eine Leseoperation kann eine CQRS-Abfrage ausführen;
- eine Listenoperation kann eine Grid-Data-Factory verwenden;
- eine Schreiboperation kann einen CQRS-Befehl ausführen.
Das unterstützt ein einheitliches Verhalten zwischen Back Office und API.
Warum CQRS wichtig ist
Stellen Sie sich zwei Möglichkeiten vor, ein Produkt zu ändern.
Direkter Datenbankansatz
API-Anfrage
→ UPDATE ps_product ...
Dadurch können folgende Mechanismen umgangen werden:
- Validierung;
- Hooks;
- Domänenregeln;
- verknüpfte Entitäten.
Ansatz mit Anwendungsbefehl
API-Anfrage
→ API-Ressource
→ CQRS-Befehl
→ Anwendungshandler
→ Domänenregeln
Das zweite Modell lässt sich in der Regel leichter mit dem Rest der Anwendung konsistent halten.
Es erleichtert außerdem das Testen des API-Verhaltens.
Die Admin-API ist standardmäßig aktiviert
Laut aktueller offizieller PrestaShop-Dokumentation ist die Admin-API in PrestaShop 9 sofort verfügbar.
Dennoch müssen API-Clients und Berechtigungen konfiguriert werden, bevor eine externe Anwendung die API nutzen kann.
Der Back-Office-Pfad zur Client-Verwaltung lautet:
Erweiterte Einstellungen
→ Admin-API
Dort können Administratoren API-Clients erstellen und ihnen Scopes zuweisen.
In Produktion ist HTTPS erforderlich
Die PrestaShop-Admin-API erzwingt in Produktion einen sicheren Zugriff.
Im Entwicklungsmodus lässt sich die HTTPS-Prüfung für lokale Arbeit lockern, in Produktion ist sicheres HTTPS jedoch Pflicht.
Entwickeln Sie keine Integration, die auf deaktivierter Transportsicherheit beruht.
API-Zugangsdaten und Tokens sind vertraulich.
Sie dürfen in Produktionsnetzen niemals über unverschlüsseltes HTTP übertragen werden.
OAuth2 ist das Authentifizierungsmodell
Die Admin-API verwendet OAuth2.
OAuth2 unterscheidet mehrere Konzepte:
- Client;
- Ressourcenserver;
- Autorisierungsserver;
- Zugriffstoken;
- Scopes.
In der Standardkonfiguration von PrestaShop:
Externe Anwendung = Client
PrestaShop = Ressourcenserver
PrestaShop = Autorisierungsserver
PrestaShop kann auch mit einem externen Autorisierungsserver arbeiten.
Client Credentials für Server-zu-Server-Integrationen
Für übliche Maschine-zu-Maschine-Integrationen empfiehlt die PrestaShop-Dokumentation den OAuth2-Ablauf Client Credentials .
Typische Beispiele:
- ERP → PrestaShop;
- PIM → PrestaShop;
- WMS → PrestaShop;
- SaaS-Dienst → PrestaShop.
Für jede API-Anfrage ist keine menschliche Anmeldung erforderlich.
Die Integration erhält:
client_id
client_secret
und tauscht diese gegen ein Zugriffstoken ein.
Einen API-Client im Back Office anlegen
Gehen Sie zu:
Erweiterte Einstellungen
→ Admin-API
→ Neuen API-Client hinzufügen
Die Client-Konfiguration umfasst beispielsweise:
- Client-Name;
- Client-ID;
- Beschreibung;
- Gültigkeitsdauer;
- Aktivierungsstatus;
- Scopes.
Verwenden Sie einen aussagekräftigen Client-Namen.
Gut:
Lagerbestandssynchronisierung
Schlecht:
api2
Auch Monate später sollten Administratoren sofort erkennen, wofür diese Zugangsdaten verwendet werden.
Client-Secret sofort sichern
Die PrestaShop-Admin-API-Dokumentation weist darauf hin, dass das generierte Client-Secret nur einmal angezeigt wird.
Bewahren Sie es beim Anlegen des Clients sicher auf.
Speichern Sie es nicht in:
- Versionsverwaltung;
- öffentlichen Konfiguration;
- Issue-Trackern;
- Screenshots;
- Protokollen.
Nutzen Sie nach Möglichkeit Umgebungsgeheimnisse oder eine dedizierte Secret-Verwaltung.
API-Clients über CLI erstellen
PrestaShop stellt auch einen Konsolenbefehl bereit:
bin/console prestashop:api-client create CLIENT_ID
Zum Beispiel:
bin/console prestashop:api-client create warehouse-sync
Zusätzliche Optionen ermöglichen die Konfiguration von:
- Name;
- Beschreibung;
- Scopes;
- Token-Lebensdauer.
Die Dokumentation nennt auch eine Option --all-scopes , warnt aber davor, echten Produktionsintegrationen sämtliche Scopes zu geben.
Minimalprinzip bei Berechtigungen anwenden
Jeder API-Client sollte nur die erforderlichen Scopes erhalten.
Ein Bestandssynchronisierungsdienst benötigt möglicherweise Produkt- oder Lagerzugriff.
Er sollte nicht automatisch Folgendes dürfen:
- unbeteiligte Module verwalten;
- alle API-Clients bearbeiten;
- auf unabhängige Kundenoperationen zugreifen.
Wird ein Token gestohlen, begrenzen eingeschränkte Scopes den möglichen Schaden.
Eine Integration, ein Client
Verwenden Sie nicht denselben API-Client für:
- ERP;
- CRM;
- Marketingautomatisierung;
- Lager;
- Reporting.
Geben Sie jedem Dienst einen eigenen Client.
Vorteile:
- getrennte Zugangsdaten;
- separate Scopes;
- einzelner Widerruf;
- bessere Prüfbarkeit.
Wird die Marketingplattform kompromittiert, können Sie nur diesen Client widerrufen.
Zugriffstoken abrufen
Beim internen PrestaShop-Autorisierungsserver lautet der Token-Endpunkt:
/admin-api/access_token
Die offizielle Dokumentation nutzt eine Anfrage wie:
curl --location 'https://shop.example.com/admin-api/access_token' \
--form 'grant_type="client_credentials"' \
--form 'client_id="warehouse-sync"' \
--form 'client_secret="YOUR_CLIENT_SECRET"' \
--form 'scope[]="product_read"' \
--form 'scope[]="product_write"'
Der Autorisierungsserver gibt ein Zugriffstoken zurück.
Die Anwendung verwendet das Token anschließend für API-Anfragen.
Bearer-Token senden
Authentifizierte Anfragen verwenden:
Authorization: Bearer YOUR_ACCESS_TOKEN
Zum Beispiel:
curl --location \
'https://shop.example.com/admin-api/api-client/infos' \
--header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
Die verfügbaren Endpunkte hängen von der installierten PrestaShop-Version und den aktivierten Modulen ab.
Übernehmen Sie Annahmen aus einem Blogartikel nicht fest in den Code.
Nutzen Sie die generierte API-Dokumentation des Zielshops.
Scopes gehören zur Token-Anfrage
Ein wichtiges OAuth-Detail: Ein Client kann viele Scopes nutzen dürfen, das Zugriffstoken wird jedoch nur für die angeforderten Scopes ausgestellt.
Zum Beispiel:
Client erlaubt:
product_read
product_write
customer_group_read
Ein bestimmtes Token könnte nur Folgendes anfordern:
product_read
Dieses Token besitzt dann engere Berechtigungen.
Das ist nützlich, um Berechtigungen weiter einzuschränken.
Ein fehlender Scope führt zu einem Autorisierungsfehler
Benötigt ein Endpunkt einen Scope, der im Token fehlt, gibt PrestaShop einen Autorisierungsfehler zurück.
Genau dieses Verhalten ist erwünscht.
Eine Integration sollte eindeutig scheitern, statt unbemerkt eine unerlaubte Operation auszuführen.
Behandeln Sie HTTP-Statuscodes im API-Client ausdrücklich.
Zugriffstokens laufen ab
Zur API-Client-Konfiguration gehört die Token-Lebensdauer.
Anwendungen müssen mit ablaufenden Zugriffstokens rechnen.
Betrachten Sie ein Zugriffstoken nicht als dauerhaft gültige Zugangsdaten.
Ein robuster Client:
- holt ein Token;
- speichert es sicher zwischen;
- verfolgt das Ablaufdatum;
- fordert bei Bedarf ein neues an.
Fordern Sie nicht vor jedem einzelnen API-Aufruf ein neues Token an, sofern Ihre Architektur dies nicht wirklich erfordert.
PrestaShop ist immer der Ressourcenserver
Die PrestaShop-Dokumentation trifft eine hilfreiche Unterscheidung.
Der Shop ist immer der Ressourcenserver , der geschützte Ressourcen bereitstellt.
Der Autorisierungsserver kann sein:
- PrestaShop selbst;
- ein externer Autorisierungsserver.
Damit können größere Organisationen bei Bedarf eine zentrale Identitätsinfrastruktur einbinden.
Externe Autorisierungsserver
Die PrestaShop-Architektur unterstützt externe Autorisierungsanbieter.
Das kann in größeren Umgebungen mit bereits vorhandener zentraler OAuth-Infrastruktur sinnvoll sein.
Die offizielle Dokumentation erläutert Integrationskonzepte und zeigt ein Beispiel mit externem Autorisierungsserver.
Das ist komplexer als der standardmäßige interne Ablauf.
Nutzen Sie ihn nur, wenn Ihre Infrastruktur wirklich zentrale Autorisierung benötigt.
Swagger-Dokumentation
Ein wesentlicher Vorteil von API Platform ist die automatische Dokumentation.
PrestaShop stellt Swagger-/OpenAPI-Informationen bereit, mit denen Entwickler die API erkunden können.
In der Entwicklungsumgebung bietet das Back Office einen Swagger-Link.
Das ist sehr nützlich, weil die Swagger-Seite die tatsächlich bereitgestellte API der Installation abbildet.
OpenAPI-JSON
Die Admin-API-Dokumentation kann im OpenAPI-Format bereitgestellt werden.
Die offizielle Dokumentation nennt:
/admin-api/docs.json
Diese Spezifikation kann in Werkzeuge wie folgende importiert werden:
- Postman;
- Insomnia-kompatible Clients;
- OpenAPI-Codegeneratoren.
Das ist viel sicherer, als die Liste der Endpunktstrukturen in einem anderen Projekt manuell zu pflegen.
API-Dokumentation über CLI erzeugen
PrestaShop bietet außerdem:
php bin/console prestashop:generate:apidoc
Die Ausgabe kann umgeleitet werden:
php bin/console prestashop:generate:apidoc > api-spec.json
Anwendungsfälle:
- API-Dokumentation;
- Client-Generierung;
- Versionsvergleich;
- Vertragstests;
- CI.
API-Spezifikation versionieren
Bewahren Sie bei großen Integrationen die generierten OpenAPI-Spezifikationen der unterstützten PrestaShop-Versionen auf.
Vergleichen Sie anschließend die Releases.
Zum Beispiel:
prestashop-9.0-api.json
prestashop-9.1-api.json
Ein Diff kann Folgendes aufdecken:
- neue Endpunkte;
- geänderte Felder;
- neue Pflichtwerte.
Dadurch kann Kompatibilität vorausschauend sichergestellt werden.
Module können API-Ressourcen hinzufügen
Die neue API ist für Erweiterungen durch Module ausgelegt.
PrestaShop erkennt API-Ressourcenklassen in Modulen, wenn die vorgesehene Konvention eingehalten wird.
Der dokumentierte Modulpfad lautet:
src/ApiPlatform/Resources
So kann ein Modul eigene API-Ressourcen hinzufügen.
Der Endpunkt ist nutzbar, wenn das Modul installiert und aktiviert ist.
Module können eigene Scopes definieren
Von Modulen definierte API-Funktionen sollten eigene Berechtigungen erhalten.
Beispiele:
security_audit_read
security_audit_write
supplier_import_read
supplier_import_run
Das ist besser, als umfangreiche allgemeine Berechtigungen zu verlangen.
Ein SaaS-Konnektor kann genau die benötigten Berechtigungen erhalten.
API-Ressourcen verwenden PHP-Attribute
Die API-Platform-Integration von PrestaShop nutzt PHP-Attribute zur Ressourcenkonfiguration.
Damit bleibt die Endpunktkonfiguration nah an der DTO-/Ressourcenklasse.
Konzeptionell:
#[ApiResource(
operations: [
// API operation definitions
]
)]
class ExampleResource
{
// fields
}
PrestaShop bietet außerdem benutzerdefinierte CQRS-orientierte Operationen, um Ressourcen mit Befehlen und Abfragen zu verbinden.
Provider übernehmen Lesezugriffe
Bei CQRS-integrierten API-Ressourcen übernehmen Provider-Abstraktionen die Leseoperationen.
PrestaShop enthält Provider für:
- Abfragen einzelner Ressourcen;
- Listen und Grid-Daten.
Der Provider empfängt die API-Ressourcenkonfiguration, wandelt Daten in die passende Abfrage um und leitet sie weiter.
Prozessoren übernehmen Schreibzugriffe
Schreiboperationen verwenden Processor-Abstraktionen.
Anfragen wie:
- POST;
- PUT;
- PATCH;
- DELETE;
können mit CQRS-Befehlen verbunden werden.
So entsteht ein klarer Ablauf:
HTTP-Anfrage
→ API-Ressource
→ Prozessor
→ CQRS-Befehl
→ Befehlsbus
→ Handler
Warum das für kommerzielle Module nützlich ist
Stellen Sie sich ein Lieferantenimport-Modul vor.
Das Back Office benötigt:
- Warteschlangenstatus;
- Import starten;
- fehlgeschlagene Vorgänge erneut versuchen;
- Lieferantenstatus lesen.
Ein SaaS-Dashboard benötigt möglicherweise dieselben Operationen.
Statt separate Ad-hoc-Endpunkte wie folgende zu erstellen:
/modules/mymodule/run.php?secret=...
kann das Modul die Architektur der Admin-API verwenden.
Das bietet:
- OAuth2;
- Scopes;
- einheitliche API-Dokumentation;
- Framework-Routing;
- Standardantworten.
Nicht jeden lang laufenden Job in eine API-Anfrage packen
Die Admin-API macht Warteschlangen nicht überflüssig.
Eine Anfrage wie:
POST /admin-api/import-all-products
sollte nicht zwei Stunden lang offen bleiben, während 100.000 Produkte verarbeitet werden.
Ein besseres Modell:
POST /imports
→ 202 Accepted
→ Auftrags-ID
Danach:
GET /imports/{id}
kann den Status zurückgeben.
Der Worker läuft getrennt.
Asynchrone Operationen entwerfen
Bei umfangreichen Vorgängen:
API
→ Auftrag erstellen
→ Warteschlange
→ Worker
→ Fortschritt
Dadurch bleibt die API-Latenz vorhersehbar.
Die Integration kann den Status abfragen oder einen Webhook empfangen, sofern das Modul einen implementiert.
Schreibvorgänge idempotent gestalten
Netzwerke fallen aus.
Clients versuchen es erneut.
Angenommen, eine Integration sendet:
Lieferanten-Produktzuordnung erstellen
und erhält einen Timeout, obwohl der Server die Operation bereits abgeschlossen hat.
Erzeugt der erneute Versuch eine weitere Zuordnung, entsteht ein Duplikat.
Verwenden Sie:
- stabile externe IDs;
- Eindeutigkeitsbedingungen;
- Idempotenzschlüssel, wo angebracht.
Ein sicherer erneuter Versuch darf keine zweite Geschäftswirkung auslösen.
Teure Operationen begrenzen
Auch authentifizierte Clients können einen Shop versehentlich überlasten.
Ein Programmierfehler kann Tausende Anfragen pro Sekunde senden.
Schützen Sie aufwendige eigene Endpunkte mit:
- sinnvolle Paginierung;
- Batch-Limits;
- Ratenbegrenzung, wo sinnvoll.
Stellen Sie keinen Endpunkt bereit, der 500.000 vollständig geladene Produkte in einer einzigen Antwort zurückgibt.
Listen paginieren
API-Listenoperationen müssen begrenzt sein.
Bevorzugen Sie:
page
limit
filters
statt:
gib mir den gesamten Katalog
Für Synchronisierung sind inkrementelle Lesevorgänge meist effizienter.
Inkrementelle Synchronisierung verwenden
Wenn ein externes Berichtssystem bereits den Katalog von gestern kennt, sollte es nicht stündlich den gesamten Katalog herunterladen.
Verwenden Sie:
- Änderungszeitstempel;
- Cursor;
- externe Ereignis-IDs;
- domänenspezifische Checkpoints.
Das reduziert:
- API-Datenverkehr;
- CPU-Last;
- Datenbanklast.
HTTP-Fehler ausdrücklich behandeln
Ihre Integration sollte unterscheiden zwischen:
- 400: Validierungsfehler;
- 401: Authentifizierungsproblem;
- 403: fehlender Scope;
- 404: Ressource nicht gefunden;
- 409: Konflikt, falls zutreffend;
- 429: Ratenlimit, sofern von der Infrastruktur eingesetzt;
- 5xx: Serverfehler.
Wiederholen Sie nicht jeden Fehler.
Ein fehlendes Pflichtfeld wird auch nach zehn Versuchen nicht gültig.
Korrelations-IDs protokollieren
Vergeben Sie bei komplexen Integrationen eine Korrelations-ID pro Anfrage oder Job.
Damit lassen sich in Protokollen folgende Vorgänge verknüpfen:
externe Anfrage
→ API-Anfrage
→ CQRS-Befehl
→ Hintergrundauftrag
→ Lieferantenaufruf
Das vereinfacht den Support erheblich.
Geheimnisse niemals protokollieren
Protokollieren Sie nicht:
- Client-Secret;
- vollständiges Bearer-Token;
- Autorisierungsheader.
Entfernen Sie sensible Daten aus Anfrageprotokollen.
Wenn Debugging-Tools vollständige HTTP-Anfragen erfassen, beschränken Sie den Zugriff und halten Sie die Aufbewahrungsdauer kurz.
Zugangsdaten rotieren
Planen Sie einen Prozess zur Rotation von Client-Secrets.
Warten Sie nicht bis zum Verdacht auf eine Kompromittierung.
Eine ausgereifte Integration kann:
- einen Ersatz-Client anlegen;
- ein neues Secret bereitstellen;
- Datenverkehr prüfen;
- den alten Client deaktivieren.
Getrennte Clients erleichtern das.
Admin-API gegenüber älterem Webservice
Der ältere Webservice existiert weiterhin im PrestaShop-Ökosystem, doch die neue Admin-API steht für die moderne, mit PrestaShop 9 eingeführte Architektur.
Prüfen Sie bei neuen Integrationen zuerst die Admin-API.
Gründe dafür sind:
- OAuth2;
- Scopes;
- API Platform;
- CQRS;
- Erweiterbarkeit durch Module;
- generierte OpenAPI-Dokumentation.
Schreiben Sie eine stabile ältere Integration nicht bloß aus Modegründen neu.
Vermeiden Sie aber zusätzliche technische Altschulden, wenn die moderne API die Anforderungen bereits erfüllt.
Empfohlene Integrationsarchitektur
Eine Produktionsintegration kann so aussehen:
ERP / PIM
↓
OAuth2-Token
↓
PrestaShop-Admin-API
↓
CQRS
↓
Geschäftslogik
↓
Datenbank
Große Aufgaben:
API → Warteschlange → Worker
Die API bildet die Schnittstellengrenze.
Die Warteschlange übernimmt lang laufende Arbeiten.
Sicherheitscheckliste
- HTTPS in Produktion
- Ein API-Client pro Integration
- Scopes nach dem Minimalprinzip
- Geheimnisse sicher gespeichert
- Tokens nicht protokollieren
- Tokenablauf berücksichtigt
- Alte Clients deaktiviert
- Eingaben validiert
- Große Operationen asynchron
- API-Fehler überwacht
Entwicklungscheckliste
- Aktuelles Swagger prüfen
- OpenAPI-Spezifikation exportieren
- Erforderliche Scopes testen
- Abgelaufenes Token testen
- Ungültiges Token testen
- Fehlenden Scope testen
- Validierungsfehler testen
- Wiederholungsversuche testen
- Paginierung testen
- Deaktiviertes Modul testen
Häufig gestellte Fragen
Ist die PrestaShop-9-Admin-API standardmäßig aktiviert?
Ja. Laut aktueller offizieller Dokumentation ist sie in PrestaShop 9 sofort verfügbar, Clients und Scopes müssen aber konfiguriert werden.
Welche Authentifizierung nutzt die Admin-API?
OAuth2.
Welchen Grant-Typ sollte eine Server-zu-Server-Integration verwenden?
PrestaShop empfiehlt den Client-Credentials-Ablauf für Server-zu-Server-Integrationen.
Welches Framework bildet die Grundlage der Admin-API?
API Platform 3.
Verwendet die Admin-API CQRS?
Ja. PrestaShop integriert API-Ressourcen mit vorhandenen CQRS-Befehlen und -Abfragen.
Wo lege ich einen API-Client an?
Im Back Office unter Erweiterte Einstellungen → Admin API oder über den Konsolenbefehl prestashop:api-client Konsolenbefehl.
Wie lautet die URL für das Zugriffstoken?
Beim internen Autorisierungsserver lautet der dokumentierte Endpunkt /admin-api/access_token.
Können Module Endpunkte hinzufügen?
Ja. Die Erweiterbarkeit durch Module ist ein zentrales Ziel der neuen API. Modulressourcen können aus folgendem Pfad geladen werden: src/ApiPlatform/Resources.
Ist Swagger verfügbar?
Ja. API Platform generiert die API-Dokumentation und PrestaShop stellt Swagger-/OpenAPI-Zugriff für die Admin-API bereit.
Sollte eine Integration alle Scopes erhalten?
Nein. Die PrestaShop-Dokumentation empfiehlt ausdrücklich, jedem Client nur die unbedingt benötigten Scopes zu geben.