Connecter PrestaShop à n8n : API Webservice, stock et automatisations e-commerce

PrestaShop reste l'une des plateformes e-commerce les plus installées en France et en Europe francophone, portée par sa gratuité et son hébergement libre. Contrairement à WooCommerce ou Shopify, elle n'a pas de node officiel dans n8n ni de webhook natif poussant les événements en temps réel : automatiser une boutique PrestaShop demande donc de connaître deux ou trois détails précis de son API Webservice. Ce guide couvre l'activation, l'authentification, les deux stratégies pour recevoir les événements (polling ou module hook), les ressources disponibles, et les automatisations les plus rentables.

Activer le Webservice et générer une clé API

L'API REST de PrestaShop est désactivée par défaut. Dans le back-office :

1. Paramètres avancés → Webservice ;
2. Basculez « Autoriser l'accès webservice de la boutique PrestaShop » sur Oui ;
3. Cliquez sur Ajouter une nouvelle clé webservice, générez une clé de 32 caractères (bouton « Générer », plutôt qu'une clé choisie à la main, plus facile à deviner) ;
4. Dans la section Permissions, cochez précisément les ressources nécessaires (orders, customers, products, stock_availables…) et, pour chacune, les droits GET/POST/PUT/DELETE réellement requis — une clé en lecture seule pour un workflow de reporting, une clé en écriture séparée pour un workflow qui modifie la boutique.

Comme pour toute clé d'automatisation, une clé par usage et le principe du moindre privilège s'appliquent : les mêmes réflexes que notre guide de sécurisation des credentials API.

Authentification depuis n8n : Basic Auth avec la clé

L'API Webservice s'authentifie en HTTP Basic Auth : la clé webservice sert d'identifiant, et le mot de passe reste vide. Dans n8n, sur le node HTTP Request, créez un credential Generic Auth → Basic Auth avec la clé en « User » et rien en « Password ». Testez ensuite un appel simple :

GET https://votre-boutique.fr/api/orders?output_format=JSON

Deux détails à connaître : l'API répond en XML par défaut — ajoutez systématiquement output_format=JSON en paramètre de requête pour recevoir un JSON directement exploitable par les nodes n8n suivants ; et une erreur 401 signale presque toujours des permissions insuffisantes sur la ressource appelée plutôt qu'un problème d'authentification lui-même.

Pas de trigger natif : deux stratégies pour le temps réel

C'est la vraie différence avec WooCommerce ou Shopify : PrestaShop ne pousse rien vers l'extérieur par défaut. Deux approches, à choisir selon votre besoin de fraîcheur :

• Polling programmé (le plus simple, zéro installation côté boutique) : un Schedule Trigger interroge toutes les quelques minutes /api/orders?output_format=JSON&filter[date_upd]=[YYYY-MM-DD HH:MM:SS,YYYY-MM-DD HH:MM:SS]&date=1, ne traite que les enregistrements modifiés depuis le dernier passage, et journalise le dernier timestamp traité pour éviter les trous. Une pagination correcte sur limit évite de rater des commandes sur les boutiques à fort volume ;
• Module hook (temps réel réel) : un petit module PrestaShop accroché sur actionOrderStatusUpdate (changement de statut) ou actionObjectOrderAddAfter (nouvelle commande) qui poste un JSON vers l'URL du node Webhook n8n. C'est quelques dizaines de lignes de PHP, mais ça exige un accès développeur à la boutique — les community nodes comme n8n-nodes-prestashop8 embarquent d'ailleurs ce mécanisme pour éviter de l'écrire soi-même.

Quelle que soit l'option retenue, votre n8n doit être accessible en HTTPS, et un même événement peut arriver plusieurs fois (rejeu du module, double passage du polling sur une fenêtre chevauchante) — une clé d'idempotence sur l'ID de commande protège le reste du workflow.

Les ressources : Order, Customer, Product, Stock

L'API Webservice expose l'essentiel du back-office en CRUD :

• orders : lecture et mise à jour du statut, des transporteurs, des notes ;
• customers et addresses : comptes clients et adresses associées ;
• products : catalogue, prix, description, catégories ;
• stock_availables : quantités disponibles par combinaison de produit — la ressource clé pour toute synchronisation de stock ;
• carts : les paniers, y compris ceux qui n'ont jamais été convertis en commande — le point d'entrée naturel pour une relance de panier abandonné.

Chaque ressource se filtre avec la syntaxe filter[champ]=valeur et se trie avec sort=[champ_ASC|DESC], directement dans l'URL du node HTTP Request.

Les automatisations les plus rentables

• Commande → facture → CRM : nouvelle commande détectée (webhook ou polling) → facture PDF → upsert client dans le CRM (HubSpot/Pipedrive) → notification Slack. Le même socle que décrit notre guide de l'automatisation des commandes e-commerce ;
• Synchronisation de stock entre PrestaShop, un ERP et d'éventuelles marketplaces, sur le modèle en quatre flux (ventes → stock, approvisionnements → boutique, alertes, réconciliation quotidienne) détaillé dans notre article sur la synchronisation de stock avec Shopify — la logique est identique, seule la ressource stock_availables change de forme ;
• Relance de panier abandonné : Schedule Trigger sur la ressource carts filtrée sur les paniers non convertis depuis plus de deux heures, puis même pipeline que notre guide de relance de paniers abandonnés par IA ;
• Contenu produit et traduction : fiches enrichies par IA (description, SEO) et traduites automatiquement pour les boutiques multi-marché, fréquentes chez les marchands PrestaShop qui vendent en France, Belgique et Suisse depuis la même instance ;
• Avis clients : demande d'avis programmée après livraison, puis analyse par IA pour prioriser les retours produit à traiter.

Fiabiliser cette synchronisation n'est pas cosmétique : l'étude de Nicole DeHoratius et Ananth Raman, « Inventory Record Inaccuracy: An Empirical Analysis » (Management Science, 2008, voir sur Google Scholar), a mesuré sur près de 370 000 références en magasin que 65 % des enregistrements de stock étaient inexacts par rapport au comptage physique — et a montré que la complexité de l'environnement et de la structure de distribution aggrave l'écart. En e-commerce, cette complexité se traduit par des systèmes qui divergent silencieusement — la boutique, l'ERP, une marketplace — chacun croyant détenir la vérité. Un pipeline n8n qui centralise les écritures et réconcilie quotidiennement, comme décrit plus haut, est exactement la réponse à ce type de dérive documentée.

PrestaShop, WooCommerce ou Shopify côté automatisation ?

Les trois se pilotent depuis n8n, mais avec des niveaux de friction différents à l'entrée : WooCommerce et Shopify offrent un trigger natif qui pousse les événements sans rien coder ; PrestaShop demande soit d'accepter le polling (simple mais avec un délai de quelques minutes), soit d'installer un module hook pour du vrai temps réel. Une fois cette étape passée, les patterns d'automatisation — commande, stock, avis, relances — sont transposables presque à l'identique d'une plateforme à l'autre, comme le montrent nos guides WooCommerce + n8n et Shopify + n8n.

En résumé

Connecter PrestaShop à n8n tient en trois étapes : activer le Webservice et générer une clé aux permissions précises, l'utiliser en Basic Auth sur un node HTTP Request avec output_format=JSON, puis choisir entre polling programmé (rapide à mettre en place) et module hook (temps réel réel). Commencez par le trio commande → facture → CRM et la synchronisation de stock — le risque le plus coûteux d'une boutique mal outillée — avant d'étendre vers les relances de panier et le contenu produit assisté par IA.