Connecter PrestaShop à votre logiciel métier : Webservice, Admin API et modules

Webservice ou Admin API : par quelle porte entrer dans PrestaShop ?

Une boutique PrestaShop offre deux interfaces de programmation, et le choix dépend d'abord de sa version : une boutique en PrestaShop 8 n'a que le Webservice, une boutique en PrestaShop 9 dispose des deux.

Le blog technique de PrestaShop a présenté l'Admin API, pendant la préparation de la version 9, comme destinée à remplacer à terme le Webservice, jugé daté, sans calendrier de retrait. La documentation de l'Admin API annonce encore une documentation développeur plus complète. En 2026, une intégration sur une boutique en version 9 peut donc combiner les deux : l'Admin API pour les ressources qu'elle couvre, le Webservice pour le reste.

Quelles données de la boutique le Webservice met-il à disposition ?

La référence du Webservice de PrestaShop 8 recense près de 80 points d'entrée. Ceux qu'un logiciel métier utilise le plus se regroupent ainsi :

• Catalogue : products, combinations (les déclinaisons, par exemple taille ou coloris), categories, manufacturers, product_features, images.
• Prix et fiscalité : specific_prices, specific_price_rules, groups, taxes, tax_rules.
• Stock : stock_availables (la quantité disponible à la vente) et stock_movements.
• Clients : customers, addresses, customer_threads pour les échanges avec le service client.
• Commandes : orders, order_details, order_histories (l'historique des statuts), order_states, order_carriers, order_invoices, order_payments, order_slip (les avoirs).
• Multiboutique : shops, shop_groups, shop_urls.

Les listes se filtrent dans l'adresse même de la requête : display=full ou une liste de champs pour choisir ce qui revient, filter[champ] pour restreindre, sort pour trier, limit pour paginer. La documentation précise qu'un tri sur une date exige d'ajouter date=1. En mode multiboutique, la clé précise aussi les boutiques accessibles.

Comment être prévenu d'une commande PrestaShop dès sa validation ?

Dans les documentations consultées, ni le Webservice ni l'Admin API ne proposent d'abonnement à des événements à la manière des webhooks d'autres plateformes. Deux méthodes restent ouvertes.

Un module émetteur. PrestaShop exécute des hooks aux étapes importantes, et un module peut s'y brancher. Le hook actionValidateOrder, rangé parmi les hooks de nouvelles commandes, reçoit le panier, la commande, le client, la devise et le statut. Le hook actionOrderStatusPostUpdate est appelé après chaque changement de statut, avec l'ancien statut, le nouveau et l'identifiant de commande. Le module envoie alors un message signé au service d'intégration, qui le traite à son rythme sans ralentir le tunnel de commande.

Une interrogation planifiée. Le service d'intégration demande à intervalle régulier les commandes récentes, triées par date, et les compare à celles déjà traitées. Rien n'est installé dans la boutique, mais le délai dépend de la fréquence, et chaque passage sollicite le serveur.

Le montage robuste associe les deux : le module pour la rapidité, l'interrogation pour rattraper un message perdu pendant une coupure. Le principe est détaillé dans notre définition du webhook.

Quatre situations de PME où l'on relie PrestaShop au logiciel métier

1. Le fabricant de meubles et ses déclinaisons. Chaque modèle de table existe en trois essences et quatre longueurs. Le logiciel de production fait foi : il crée le produit et ses combinations avec la référence fabricant de chaque déclinaison, puis met à jour stock_availables à chaque fin d'ordre de fabrication.
2. Le distributeur et ses revendeurs. Un distributeur de matériel de motoculture tient ses conditions commerciales dans son ERP. Chaque revendeur validé devient un client PrestaShop rattaché à un groupe dédié, et les remises négociées deviennent des prix spécifiques : les tarifs en ligne sont ceux de l'ERP, sans ressaisie.
3. Le statut qui déclenche l'expédition. Paiement accepté : le hook de changement de statut prévient l'entrepôt. Colis parti : l'outil de préparation ajoute le statut « expédié » dans order_histories et complète les informations de transport de la commande (order_carriers). L'étiquette vient de l'intégration transporteur, par exemple Chronopost.
4. L'avoir jusqu'à la comptabilité. Le service lit factures (order_invoices) et avoirs (order_slip) et les transmet à l'outil comptable ou à la plateforme de facture électronique, sujet de notre page sur la facture électronique dans un logiciel métier.

Les pièges propres à PrestaShop

• Le format d'écriture : selon la documentation PrestaShop, depuis la version 8.1, le Webservice produit du JSON (paramètre output_format=JSON) mais ne lit pas le JSON en entrée. Créations et modifications passent par XML, ce qui alourdit le code et les tests.
• Le serveur : sous Apache, le Webservice dépend de mod_rewrite et d'un VirtualHost en AllowOverride All. Un changement d'hébergeur mal préparé suffit à couper l'API.
• Les modules tiers : la liste des statuts de commande se lit par la ressource order_states avant la mise en service, puis à nouveau après chaque installation d'un module de paiement ou de livraison, pour que la table de correspondance des statuts reste juste.
• Les clés trop larges : la documentation invite à une grande prudence sur les droits d'une clé et sur les personnes à qui on la confie. Une clé par flux, avec le minimum de droits, se révoque sans tout casser.
• Les doublons : un même acheteur peut exister en invité puis en client inscrit. Le service rapproche par adresse e-mail avant de créer une fiche dans le logiciel métier.
• Les données personnelles : on ne transmet que les champs utiles et on fixe une durée de conservation aux journaux, selon les principes de notre guide RGPD et logiciel métier.

Module du marché, export planifié ou développement sur mesure ?

Comment YMHB Web construit et maintient l'intégration

1. Cadrage : version de PrestaShop, modules installés, statuts de commande réellement utilisés, source de vérité de chaque donnée. Le chiffrage vient ensuite, jamais avant.
2. Choix de l'interface : Webservice, Admin API ou les deux, selon la version et les ressources nécessaires, avec l'accès à PrestaShop isolé dans un module dédié du service pour basculer plus tard d'une interface à l'autre.
3. Construction flux par flux sur une copie de la boutique, avec des commandes de test couvrant les cas limites : paiement refusé, commande modifiée, retour partiel.
4. Mise en service avec une période de double contrôle, où l'ancien et le nouveau circuit tournent en parallèle.
5. Maintenance : chaque mise à jour de PrestaShop ou d'un module passe d'abord sur la copie.

Les clés et l'hébergement sont au nom du client, le code du service lui appartient au paiement intégral, et la documentation décrit chaque flux et la procédure de reprise. L'offre complète figure sur notre page API et intégrations entre vos logiciels.