PrestaShop reste le CMS e-commerce open-source n°1 en France avec plus de 300 000 boutiques actives. Son webservice REST, stable depuis la 1.5, permet d'accéder à l'intégralité du catalogue. En 2026 c'est toujours la seule voie officielle pour brancher un middleware, un ERP ou un outil tiers comme Seegea.
Cette page s'adresse aux développeurs et freelances qui intègrent PrestaShop : on détaille l'authentification, les ressources clés, les formats XML vs JSON, les pièges récurrents, et comment Seegea s'appuie dessus pour offrir une édition catalogue fluide.
Stack Seegea \u2194 PrestaShop
Les 3 ressources API PrestaShop les plus critiques
products
/api/productsname multilingue, description, reference (SKU), price HT, id_category_default, active. GET, POST, PUT, DELETE supportés.combinations
/api/combinationsid_product. Attention : chaque combinaison porte ses propres price, wholesale_price, reference, ean13. Cohérence à maintenir côté middleware.stock_availables
/api/stock_availablesproducts.quantity. Pattern multi-entrepôts supporté via id_shop.Exemple de requête GET product via webservice
# Récupérer un produit en JSON
curl -X GET \
"https://boutique.exemple.com/api/products/42?output_format=JSON" \
-u "YOUR_API_KEY:"
# Réponse (extrait)
{
"product": {
"id": "42",
"reference": "TSHIRT-BIO-M",
"price": "19.9150",
"name": [
{ "language": { "id": "1" }, "value": "T-shirt coton bio" },
{ "language": { "id": "2" }, "value": "Organic cotton T-shirt" }
],
"active": "1",
"associations": {
"combinations": [
{ "id": "128" }, { "id": "129" }
]
}
}
}Le prix renvoyé est en HT avec 4 décimales. La conversion TTC dépend des règles de taxes (id_tax_rules_group) du produit.
Les 5 pièges du webservice PrestaShop
1. Le prix HT/TTC mal interprété
Le webservice renvoie le prix HT (price) avec 4 décimales. Pour obtenir le TTC, il faut appliquer le tax_rules_group associé. Beaucoup de middlewares affichent des prix divergents entre PrestaShop, Shopify et le front storeview à cause de ça.
2. Les langues multi-idiomes oubliées
Presque tous les champs textuels PrestaShop sont des tableaux multilingues (name, description, link_rewrite, meta_title…). Un middleware qui écrit uniquement en language id=1 écrase les autres langues. Toujours boucler sur id_lang pour chaque langue active.
3. Les combinaisons non mises à jour atomiquement
Modifier une combinaison nécessite 2 appels : 1 PUT sur /combinations/{id} + 1 PUT sur /stock_availables pour le stock dédié. Si le 2e plante, vous avez une combinaison avec prix à jour mais stock incohérent. Pattern de transaction à coder côté middleware.
4. Pas de rate limit natif, mais pas scalable
PrestaShop n'a pas de rate limit strict côté API, mais le serveur PHP/MySQL sous-jacent tient rarement plus de 50 req/s en écriture sur une instance OVH standard. Au-delà, timeouts 504 et corruption de données possibles. Toujours batcher et temporiser en production.
5. Les images traitées hors webservice standard
L'upload d'images passe par /api/images/products/{id_product} avec un POST multipart/form-data, pas du JSON. Beaucoup de middlewares foirent cette partie et se retrouvent avec des fiches texte sans visuel — désastre côté Google Shopping.
Comment Seegea s'intègre avec PrestaShop
Seegea expose un module PrestaShop natif (v3.9.x en 2026, compatible PrestaShop 1.7.x et 8.x) qui gère :
- Authentification OAuth-like avec rotation de clé, stockage chiffré côté Seegea.
- Webhooks (
products/create,products/update,orders/create,stock_mvt) pour la synchronisation temps réel. - Import initial du catalogue via appel batch sur products + combinations + stock_availables + images, parse parallèle dans Inngest.
- Édition via webservice REST en JSON, respect du pattern multilingue, transaction combinaisons + stock.
- Rollback snapshot + re-push si un bulk edit dérape.
Description IA multilingue
Optimisation images automatique
/api/images/products, compression, redimensionnement 1000×1000 Google Shopping. Core Web Vitals remontent mécaniquement.Rollback par produit
| Besoin | Webservice brut | Seegea + module PrestaShop |
|---|---|---|
| Setup initial | 10 à 30 j-h dev | 48 heures |
| Bulk edit 500 combinaisons | Script PHP custom | Grille inline |
| Édition multilingue | À coder pour chaque langue | Native (fr, en, es…) |
| Images WebP + resize | À coder (Sharp/Imagick) | Natif |
| Respect rate PHP/MySQL | À coder (queue + retry) | Géré côté Seegea |
| Rollback éditorial | Impossible natif | Ctrl+Z + re-push REST |
Voyez Seegea branché sur votre PrestaShop
30 min Google Meet · démo sur votre vrai catalogue
Quand coder directement et quand passer par Seegea
Règle pragmatique :
- Coder directement sur le webservice : pour des flux ERP → PrestaShop (prix, stock, référence), pour des intégrations one-shot (migration, exports), pour de la lecture seule (data warehouse, BI).
- Passer par Seegea : pour l'édition catalogue au quotidien (enrichissement, bulk edit, rollback, IA, médias). Toute la partie éditoriale qui reste aujourd'hui bloquée dans le back-office PrestaShop natif ou dans vos CSV.
Seegea est conçu en France entre Annecy et Chantilly. Notre équipe maintient le module PrestaShop officiel et parle couramment "id_lang", "id_tax_rules_group", "override Product.php". Si vous avez un doute sur votre architecture, 30 minutes en visio Google Meet suffisent pour arbitrer.