Webservice PrestaShop : activer l’API et créer une clé d’accès

Table des matières :

1. Pré-requis (versions, TLS, droits) et impact réel côté serveur
2. Activer le Webservice PrestaShop : ce que fait réellement le toggle « Activer le service web »
3. Créer une clé d’accès : longueur, stockage, IP allowlist, et permissions minimales
4. Tester l’API Webservice : curl, filtres, pagination, formats, et diagnostics 401/403
5. Sécurisation production : IP allowlist, propagation du header Authorization, rate limiting, et anti-bruteforce
6. Webservice legacy vs API d’administration PrestaShop 9 : choisir le bon contrat d’intégration
7. Logs, supervision et performance : rendre l’API testable et débogable (sinon vous allez “jouer à l’aveugle”)

Pré-requis (versions, TLS, droits) et impact réel côté serveur

Ce guide cible le Webservice PrestaShop (API legacy) exposé sous /api (authentification HTTP Basic avec une clé comme identifiant). Les écrans Back-Office sont globalement identiques de PrestaShop 1.7.8.x à PrestaShop 8.1.x ; en PrestaShop 9.x le Webservice est toujours présent pour compatibilité, mais il cohabite avec la nouvelle API d’administration (OAuth/API Platform) — ne mélangez pas les deux modèles d’authentification.

Côté runtime, partez sur des versions cohérentes avec votre stack : typiquement PHP 7.4 pour 1.7.8, PHP 8.1/8.2 pour 8.x, et PHP 8.2+ pour 9.x. Le Webservice n’est pas « gratuit » : chaque requête passe par le front controller, initialise le contexte, et peut déclencher des requêtes SQL non triviales selon la ressource (produits + déclinaisons + images = rapidement cher). Si vous avez des pics de charge, traitez l’API comme un endpoint critique (quota, IP allowlist, supervision) au même titre que le checkout.

Deux conséquences concrètes (souvent sous-estimées) :

• Le coût dépend de la représentation demandée : display=full sur des ressources lourdes (produits, déclinaisons, images) peut faire exploser le temps CPU/SQL. Pour des synchronisations, préférez des lectures incrémentales (par date), et des payloads minimalistes (uniquement les champs nécessaires).
• Le coût dépend du client : un connecteur qui lance 10 appels simultanés « par produit » va saturer PHP-FPM plus vite qu’un batch paginé et séquentiel. C’est un sujet de conception d’intégration, pas seulement de configuration serveur.

Pré-requis de base avant d’exposer /api :

1. HTTPS strict (HSTS idéalement) ; l’auth HTTP Basic transporte un secret et ne doit jamais transiter en clair.
2. Un plan de rotation de clé et de révocation (au minimum : procédure + calendrier + qui valide).
3. Des sauvegardes et un environnement de staging si vous activez des droits d’écriture (POST/PUT/DELETE).
4. Un minimum d’observabilité (logs HTTP + logs PrestaShop) pour pouvoir corréler un incident API avec le serveur et la base.

Côté conformité (contexte UE/France), gardez en tête que les endpoints customers / addresses / orders exposent des données personnelles. Même si l’API est « interne », une fuite de clé ou un proxy mal configuré peut devenir un incident de sécurité. En pratique : cloisonnez les accès, conservez des logs utiles (sans sur-collecte), et limitez les droits au strict nécessaire (principe de minimisation).

Enfin, si vous activez l’écriture via API, adoptez un réflexe simple : staging d’abord, prod ensuite. Les erreurs d’intégration courantes ne sont pas des « bugs PrestaShop » : c’est un champ requis manquant, un encodage inattendu, ou un ordre d’opérations incorrect (ex. créer un produit sans associations attendues). Le staging évite de tester en direct sur le catalogue réel.

Activer le Webservice PrestaShop : ce que fait réellement le toggle « Activer le service web »

Dans le Back-Office : Paramètres avancés → Service Web → Activer le service web. Ce toggle ne « crée » pas l’API : il autorise le front controller api/dispatcher.php à répondre et active la gestion des permissions liées aux clés. En pratique, vous exposez un point d’entrée public sous https://votre-domaine.tld/api/.

Sur Apache, PrestaShop s’appuie sur des règles de réécriture (mod_rewrite) et sur un .htaccess dans /api/. Sur Nginx, il n’y a pas de .htaccess : vous devez reproduire l’équivalent en location /api (sinon vous tombez sur des 404/403 « mystérieux »). L’erreur classique en prod : l’API marche en local (Apache) et casse en prod (Nginx + PHP-FPM) car les règles /api ou le header Authorization ne sont pas propagés.

Validez immédiatement l’exposition réseau :

• GET /api/ doit retourner une liste des ressources (XML), ou un 401 si aucune auth n’est fournie.
• GET /api/products doit retourner 401/403 selon permissions.
• Si vous êtes derrière CDN/Varnish, assurez-vous que /api bypass le cache (sinon vous mettez des réponses authentifiées en cache… scénario à éviter).

Checklist « activation propre » (utile en runbook) :

• Le dossier /api existe bien à la racine de l’installation PrestaShop et est accessible par le serveur web.
• Le vhost redirige HTTP → HTTPS, et /api n’échappe pas à la redirection (sinon vous testez en clair sans le vouloir).
• Le proxy/CDN ne met pas /api en cache, et ne réécrit pas les en-têtes sensibles.
• Vous avez une stratégie de logs distincte (au minimum un access log) pour /api afin de repérer les patterns d’erreur.

Pour l’architecture cache/proxy, recoupez avec : optimiser caches, CDN et Varnish lors des soldes et l’article sur Varnish, Redis, Memcached et OPcache côté serveur.

Pour la doc officielle (modèle REST, ressources, paramètres), la référence reste : PrestaShop DevDocs — Webservice API

Créer une clé d’accès : longueur, stockage, IP allowlist, et permissions minimales

Toujours dans Paramètres avancés → Service Web, cliquez Ajouter. PrestaShop génère une clé (souvent 32 caractères hex) utilisable comme username en HTTP Basic (mot de passe vide par convention). Ne confondez pas « clé API » et « token OAuth » : ici, c’est un secret statique, sans expiration native, et donc à gérer comme un mot de passe long.

Bonnes pratiques de stockage (souvent la vraie cause des fuites) :

• Ne commitez jamais une clé en clair dans Git (même sur un dépôt privé). Utilisez des variables d’environnement chiffrées, un coffre de secrets, ou un gestionnaire de secrets (Vault, AWS Secrets Manager, etc.).
• Si vous devez la mettre dans un outil d’intégration (ETL, iPaaS, connecteur marketplace), vérifiez les droits : qui peut lire le secret ? qui peut l’exporter ?
• Évitez de la disperser : une clé par intégration (ERP, BI, transporteur, marketplace) limite l’impact d’une compromission.

Point important : le Back-Office permet d’associer une liste d’IP autorisées à utiliser cette clé. Utilisez-la, surtout pour les intégrations serveur-à-serveur (ERP, PIM, middleware). Cette restriction ne remplace pas un firewall mais elle réduit drastiquement la surface d’attaque si la clé fuit.

Deux pièges fréquents côté IP allowlist :

• NAT / IP sortante variable : un SaaS peut changer d’IP. Dans ce cas, négociez une liste d’IP fixes (ou passez par un middleware qui, lui, a une IP stable).
• Reverse proxy : si votre PrestaShop est derrière un proxy, l’IP vue par PHP peut être celle du proxy, pas celle du client. L’allowlist peut alors bloquer à tort. La solution est soit d’autoriser l’IP du proxy (si c’est volontairement le seul point d’entrée), soit de configurer correctement la remontée de l’IP réelle au niveau serveur (selon votre architecture).

Pour les sujets de durcissement global (TLS, .htaccess, surface d’attaque), recoupez avec Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess.

Le modèle de permission est par ressource (orders, customers, products, etc.) et par méthode : GET / POST / PUT / DELETE / HEAD (selon version). Appliquez le principe du moindre privilège : une intégration “lecture catalogue” n’a rien à faire avec orders en écriture. En audit, posez-vous la question suivante : si cette clé fuite aujourd’hui, qu’est-ce qu’un attaquant peut réellement faire ?

Mini-scenario réaliste : vous branchez un PIM qui ne fait que lire le catalogue et renvoyer des descriptions. La clé n’a besoin que de products (GET/PUT) et éventuellement images (POST/DELETE selon votre flux). Donner customers ou orders « au cas où » est un risque inutile (données personnelles + impact business).

Exemple de contrôle rapide en SQL (adaptez le préfixe) pour inventorier les clés et permissions en prod, utile lors d’un audit :

SELECT id_webservice_account, description, active, `key`
FROM ps_webservice_account;

SELECT p.id_webservice_account, p.resource, p.method
FROM ps_webservice_permission p
ORDER BY p.id_webservice_account, p.resource, p.method;

Astuce opérationnelle : documentez vos clés avec une description exploitable (ex. ERP Odoo PROD - lecture commandes), et ajoutez une date de création/rotation dans votre gestionnaire de tickets ou votre coffre de secrets. Le jour où vous devez révoquer en urgence, cette discipline fait gagner du temps.

Tester l’API Webservice : curl, filtres, pagination, formats, et diagnostics 401/403

L’auth est de type HTTP Basic : la clé est le login, le mot de passe est généralement vide. Avec curl, le test minimal :

# Lister les ressources disponibles (attendez-vous à du XML)
curl -i -u 'VOTRE_CLE:' https://boutique.tld/api/

# Accéder à une ressource
curl -i -u 'VOTRE_CLE:' https://boutique.tld/api/products

Si vous obtenez 401 Unauthorized, c’est soit une clé invalide, soit le header Authorization qui n’arrive pas jusqu’à PHP (cas fréquent avec Nginx/PHP-FPM ou certains reverse proxies). Un 403 Forbidden correspond typiquement à une clé valide mais permission manquante sur la ressource/méthode. Un 404 sur /api indique plutôt un problème de routage/réécriture (Nginx mal configuré, dossier /api non accessible, règles rewrite cassées).

Table de diagnostic rapide (pratique en exploitation) :

Statut	Cause probable	Vérification rapide
401	Clé invalide ou header Authorization perdu	Tester sur Apache direct (sans proxy), vérifier config Nginx HTTP_AUTHORIZATION
403	Permissions manquantes sur la ressource/méthode	Vérifier la clé dans BO (GET/POST/PUT/DELETE cochés)
404	Rewrite / routage /api cassé	Tester GET /api/ sans auth, vérifier location /api
405	Méthode non autorisée	POST/PUT/DELETE non cochés, ou ressource non modifiable
500	Erreur PHP / module / override	Regarder error log PHP + logs PrestaShop
503 / timeout	Saturation (PHP-FPM, DB) ou rate limiting en amont	Logs proxy + métriques, réduire concurrence, paginer

Pour des synchronisations “sérieuses”, exploitez les paramètres de l’API Webservice : filtres, tri, pagination. Quelques patterns utiles (les noms exacts peuvent varier selon ressources et versions, à valider sur votre instance) :

# Pagination (ex : 50 premiers)
curl -s -u 'VOTRE_CLE:' \
  'https://boutique.tld/api/orders?limit=0,50&sort=[date_add_DESC]'

# Filtrer par date (ex : intervalle)
curl -s -u 'VOTRE_CLE:' \
  'https://boutique.tld/api/orders?filter[date_add]=[2026-01-01,2026-12-31]'

# Récupérer un objet précis
curl -s -u 'VOTRE_CLE:' https://boutique.tld/api/orders/12345

Deux recommandations côté client API (souvent décisives pour la stabilité) :

• Backoff et reprises : si vous recevez un timeout ou un 503, réessayez avec un délai progressif (et une limite). Sinon vous aggravez la saturation.
• Constance des requêtes : évitez les paramètres « variables » inutiles (changements d’ordre, display=full aléatoire), car ils compliquent le debug et la mise en cache côté proxy interne (si vous en utilisez un).

Sur le format, l’historique PrestaShop est XML-first. Certaines versions supportent un rendu JSON via paramètre (ex. output_format=JSON) ou en-tête Accept, mais ce n’est pas uniformément fiable selon overrides/modules. Dans une intégration industrielle, standardisez côté client sur XML (parsing robuste + validation) ou mettez un middleware qui normalise en JSON (et gère retries, backoff, idempotence) plutôt que d’espérer un JSON natif stable.

Sécurisation production : IP allowlist, propagation du header Authorization, rate limiting, et anti-bruteforce

TLS d’abord, puis contrôle réseau. Le Webservice PrestaShop n’embarque pas de mécanisme natif de rate limiting ni de détection d’abus. Si vous exposez /api sur Internet (intégration SaaS, marketplace), mettez le contrôle au niveau reverse proxy/WAF : quotas par IP, par clé, voire par path (/api/orders plus sensible que /api/products).

Un exemple de politique raisonnable (à adapter) :

• /api/orders : faible débit, priorité à la stabilité, journalisation renforcée.
• /api/products : débit plus élevé accepté mais pagination obligatoire.
• Toute tentative sur des ressources non autorisées : blocage rapide (réduire le bruit, limiter le brute force).

Sur une infra proxy/edge, vous pouvez implémenter ça avec HAProxy/Nginx ou une API Gateway (cf. API Gateway : authentification, rate limiting et routage des microservices et l’approche HAProxy : terminaison TLS, limitation de débit et supervision Prometheus).

Le piège Nginx/PHP-FPM le plus courant : le header Authorization est perdu. Si c’est votre cas, vous verrez des 401 même avec une clé valide. Correction typique (à adapter à votre vhost) :

location /api/ {
  try_files $uri /api/dispatcher.php?$args;
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root/api/dispatcher.php;
  fastcgi_param HTTP_AUTHORIZATION $http_authorization;
  fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Ajoutez ensuite une couche anti-bruteforce. Comme la clé est statique, un attaquant peut tenter des combinaisons et observer les réponses. Bloquez au niveau edge (rate limit) et éventuellement au niveau système avec fail2ban sur vos logs (Nginx/Apache). Même si l’article ci-dessous cible une autre surface (navigation à facettes), les principes sont transposables : bloquer un trafic abusif via fail2ban. Enfin, ne stockez jamais la clé côté front (JS), ni dans un module qui l’expose via un endpoint non authentifié.

Dernier point « sécurité + ops » : rotation. Comme la clé ne périme pas nativement, prévoyez une rotation sans downtime :

1. Créer une nouvelle clé avec les mêmes droits.
2. Déployer côté client (ERP/middleware) en supportant les deux clés pendant une fenêtre de transition.
3. Désactiver/révoquer l’ancienne clé.
4. Vérifier les logs /api pour s’assurer qu’il n’y a plus d’appels avec l’ancienne.

Webservice legacy vs API d’administration PrestaShop 9 : choisir le bon contrat d’intégration

Le Webservice legacy est pragmatique pour : synchroniser un catalogue, pousser des stocks, lire des commandes, brancher un ERP “classique”. Mais il a des limites structurantes : auth Basic sans scopes dynamiques, absence de tokens expirables, pas de webhooks natifs, modèle de ressource parfois incomplet selon besoin métier, et une expressivité filtrage/pagination qui peut devenir fragile quand on veut faire du near-real-time propre.

Un bon critère de choix (simple) :

• Si vous avez besoin d’un accès “données boutique” (catalogue/commandes) et que votre existant est déjà basé sur /api, le legacy reste souvent le chemin le plus court — mais à condition de l’encadrer (réseau, quotas, permissions).
• Si vous avez besoin d’une gouvernance d’API (droits fins, tokens, audit, intégration moderne), et que vous êtes en PrestaShop 9, vous avez intérêt à regarder la nouvelle API d’administration.

Si vous êtes en PrestaShop 9 et que vous développez une intégration orientée Back-Office moderne (droits, audit, architecture API), l’option sérieuse est la nouvelle API d’administration (OAuth, API Platform). Elle est couverte ici : API d’administration PrestaShop 9 : OAuth, API Platform v3, endpoints CQRS. Dans un contexte “headless” ou microservices, ce choix s’aligne mieux avec une gouvernance d’API (contrats, versioning, politiques d’accès) ; voir aussi commerce headless : microservices et API REST/GraphQL scalable.

Pour les intégrations opérationnelles (ERP/PIM/logistique), l’approche robuste en 2026 reste : middleware entre PrestaShop et le SI, avec gestion d’état, reprises, idempotence, et sécurisation centralisée (coffre de secrets, rotation). Sur le blog, deux briques internes vont dans ce sens : connecter un ERP : API, connecteurs et donnée unique et automatisations : RGPD, moindre privilège et journaux d’audit. Si vous automatisez lourdement (pricing, stock, commandes) via scripts, regardez aussi l’outillage MCP : PrestaShop MCP Server : installation, webservices et gestion produits.

Logs, supervision et performance : rendre l’API testable et débogable (sinon vous allez “jouer à l’aveugle”)

Le Webservice échoue rarement “proprement” en prod : vous aurez des 401 (auth), 403 (permissions), 500 (fatal PHP), 503 (saturation), ou des timeouts côté client. La base : activez une stratégie de logs côté plateforme (Nginx/Apache avec temps de réponse, upstream status), et corrélez avec les logs applicatifs PrestaShop. Pour un runbook concret côté boutique : monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail.

Côté logs HTTP, si vous pouvez, ajoutez (sans complexifier) :

• un identifiant de requête (request_id) dans les logs du reverse proxy ;
• la durée (request_time) et, si proxy vers PHP-FPM, la durée upstream (upstream_response_time) ;
• le chemin exact demandé (/api/...) pour isoler les endpoints coûteux.

Quand vous faites des appels massifs (sync catalogue), vous allez toucher la base de données. Si les temps explosent, ne “tunez” pas à l’aveugle : activez le slow query log et mesurez les requêtes réellement lentes, puis itérez (index, limitations de display=full, pagination stricte). Deux références internes utiles : activer le slow query log sur PrestaShop et debug profiling : analyser les performances SQL.

Enfin, traitez /api comme une surface pouvant déclencher des incidents infra : saturation PHP-FPM, files descriptors, pics de CPU, ou effets de bord caches/proxy. Si vous voyez des 503 pendant des synchronisations, diagnostiquez côté serveur (ressources, logs, limites) avant de modifier le code : Erreur HTTP 503 : diagnostic serveur, logs et ressources et, pour la mise en place de pratiques de charge/supervision, monitoring, tests de charge et runbooks soldes.

À retenir : le cœur PrestaShop ne vous protège pas contre un client API mal configuré. C’est à vous d’imposer quotas, backoff, pagination, et de fixer des limites (taille de payload, nombre de requêtes simultanées). Sans ces garde-fous, « activer l’API » devient rapidement « exposer un point de contention » sur la prod.