Page mise à jour le
Ce que l'API permet
Ce que PrestaShop expose réellement
Repris de la documentation publique de l'éditeur, pas d'une plaquette commerciale. Le lien vers cette documentation est en bas de page.
Accès aux ressources de la boutique, une par une
Une fois le webservice activé (Paramètres avancés > Webservice), une clé ouvre les ressources que vous cochez : commandes, produits, clients, adresses, stocks, transporteurs, factures, et bien d'autres listées dans la documentation PrestaShop 9. Chaque clé a ses droits : lecture seule sur les commandes, écriture sur le stock, rien sur les employés. C'est volontairement fin. Une clé « tout autoriser » est une faille, pas un gain de temps. L'accès se fait à la racine /api/ de la boutique, avec réécriture d'URL obligatoire.
Filtrer ce qui a changé depuis la dernière lecture
On peut demander les commandes d'un client, les villes qui commencent par un mot, ou les commandes ajoutées entre deux heures, avec le paramètre de date documenté. C'est la manière honnête de rattraper l'absence d'événement poussé : on relit ce qui est nouveau, pas tout le catalogue. Un cache de contenu (en-tête Content-Sha1, corrigé depuis PrestaShop 8.0) permet de constater qu'une ressource n'a pas bougé et d'éviter une mise à jour inutile. Sans filtre de date, une synchro nocturne ressaisit l'historique.
Créer, modifier, supprimer — dans le format de la boutique
Créer une ressource, c'est récupérer le modèle vide, le remplir, l'envoyer. Modifier, c'est relire la fiche complète, changer ce qu'il faut, renvoyer le tout — ou n'envoyer que les champs concernés avec une mise à jour partielle. Un retour à la ligne mal placé dans une balise casse l'écriture : la documentation le signale noir sur blanc. Depuis PrestaShop 8.1, la sortie peut être en JSON ; l'entrée, elle, reste dans le format historique. Ce n'est pas anodin pour qui croit « coller du JSON et ça passe ».
Multiboutique : la clé ne voit que les magasins associés
En mode multiboutique, chaque clé est liée à une ou plusieurs boutiques. Une commande passée sur le magasin B n'apparaît pas si la clé n'y a pas accès. C'est le piège le plus fréquent des catalogues qui vendent sous plusieurs noms. Avant d'automatiser, on liste les boutiques concernées et on teste la clé sur chacune. Sinon l'agent « ne voit pas les commandes du site vitrine » pour une raison qui n'a rien de technique une fois qu'on l'a nommée.
Documentation du webservice PrestaShop 9 (nouvel onglet) — Documentation développeur officielle du projet PrestaShop 9 : activation, clé, ressources, filtres, formats. Consultée le 21-08-2026.
Trois automatisations concrètes
Ce qu'on met en place avec
Trois situations réelles, décrites comme du travail plutôt que comme de la technique.
Reprendre les commandes du matin sans export CSV
Toutes les heures, l'agent demande les commandes ajoutées depuis le dernier passage, avec leur détail et leur état. Celles déjà facturées sortent. Les autres préparent une pièce dans la compta ou une ligne dans l'atelier. Un statut « paiement accepté » n'est pas un encaissement bancaire : le rapprochement reste un geste à part. L'intérêt n'est pas la vitesse, c'est d'arrêter de télécharger un fichier que personne ne relit.
Remonter le stock réel vers la fiche produit
Quand l'entrepôt décrémente une référence, l'agent écrit la quantité disponible sur la ressource stock de PrestaShop. Un écart — deux ventes simultanées, un inventaire non saisi — n'est pas inventé : il est signalé. PrestaShop peut tenir plusieurs déclinaisons pour un même produit ; écrire au mauvais niveau vend une taille que vous n'avez plus. La règle « quelle déclinaison, quel magasin » se décide avant la première écriture.
Créer le client une seule fois
Un nouveau compte boutique ne doit pas produire une fiche ailleurs s'il existe déjà sous un autre mail. L'agent cherche d'abord, puis crée, et recopie l'adresse de livraison telle que PrestaShop la tient. Les adresses, les clients et les commandes sont trois ressources distinctes : les relier à la main est exactement le travail qu'on retire. Un doublon créé « pour aller plus vite » se paie à chaque relance suivante.
Limites
Ce que cette intégration ne fera pas
Les contraintes qu'on rencontre pour de vrai. Les découvrir maintenant coûte une lecture ; les découvrir en cours de projet coûte le projet.
Pas d'événement poussé dans le webservice classique
Le webservice PrestaShop est un accès à la demande : on lit, on écrit, on revient. Il n'envoie pas tout seul un signal à chaque commande. Pour réagir vite, on interroge à intervalle court avec un filtre de date, ce qui charge la boutique. PrestaShop 9 documente aussi une Admin API destinée à remplacer ce webservice à terme ; pour une boutique en production aujourd'hui, le chemin documenté pour un outil tiers reste le webservice. Promettre « dès la commande » sans le dire, c'est mentir sur le délai.
La réécriture d'URL et le HTTPS ne sont pas optionnels
Sans réécriture d'URL (mod_rewrite, AllowOverride), l'adresse /api/ ne répond pas. PrestaShop indique qu'il est préférable d'appeler en HTTPS pour éviter l'interception de la clé. Mettre la clé dans l'adresse du navigateur est documenté comme risqué et interdit en production. Une boutique dont l'hébergeur bloque PUT ou DELETE verra les mises à jour échouer. On teste ces cinq méthodes avant d'écrire une ligne d'automatisation.
Les modules métier restent souvent hors d'atteinte
Le webservice expose les ressources du cœur. Un champ ajouté par un module de marketplace, de point relais ou de facturation française n'existe pour l'extérieur que si le module étend le webservice — PrestaShop documente cette extension, elle n'est pas automatique. Beaucoup de boutiques françaises vivent dans ces modules. On dresse la liste des champs indispensables et on vérifie, module par module, s'ils sortent. Ce qui ne sort pas se traite à part, ou pas du tout.
Ce que brancher PrestaShop demande vraiment
Activer le webservice, créer une clé aux droits minimaux, vérifier que /api/ répond en HTTPS, puis lire une commande réelle. Ensuite seulement on écrit. Le premier flux utile est presque toujours « nouvelles commandes vers un autre outil », parce qu'il se teste sur le volume du jour. L'écriture du stock vient après, quand la lecture est fiable. Compter un temps d'inventaire des modules : c'est là que les projets PrestaShop s'allongent, pas sur la clé elle-même.
Vos questions
Le webservice est-il allumé sur une boutique PrestaShop neuve ?
Non. Il est désactivé par défaut, et c'est voulu : ouvrir la base à l'extérieur sans clé ni droits serait une faille. Il faut l'activer dans Paramètres avancés > Webservice, puis créer une clé et cocher uniquement les ressources nécessaires. Une boutique « qui a PrestaShop » n'est donc pas une boutique déjà connectable. Le premier geste d'un projet d'intégration, avant tout devis de développement, est de vérifier que cette page existe, que la réécriture d'URL fonctionne, et qu'une clé de test répond.
Peut-on être prévenu à la seconde où une commande arrive ?
Pas avec le webservice classique. On peut relire souvent les commandes récentes, par exemple toutes les cinq minutes, ce qui suffit à l'atelier dans la plupart des TPE. Ce n'est pas de l'instantané, et le dire évite de construire un espoir que l'outil ne tient pas. S'il faut vraiment l'instant, on regarde un module qui pousse l'événement, ou l'Admin API plus récente — et on vérifie ce que la version installée expose vraiment, pas ce que la brochure d'un connecteur affirme.
Faut-il une clé distincte par outil connecté ?
Oui, c'est la lecture honnête de la page d'accès. Chaque clé porte ses droits et peut être révoquée sans casser les autres. Une clé unique partagée entre la compta, l'atelier et un tableur, c'est un seul secret à voler et un seul interrupteur qui éteint tout. On nomme la clé, on limite les ressources, on la stocke hors de la boutique. La révocation est un geste de routine, pas un incident.
Une idée en tête ?
Réservez un rendez-vous ou écrivez-nous — réponse sous 24 h.