La Store API WooCommerce : ce qu'une boutique expose publiquement

Vous êtes tombé sur l'adresse /wp-json/wc/store/v1/products, dans le rapport d'un outil, dans le code source d'une page ou dans les journaux de votre serveur. Ajoutée au nom de domaine d'une boutique WooCommerce, elle renvoie par défaut une liste de produits à n'importe qui, sans connexion ni clé. Si la boutique est la vôtre, vous voulez savoir ce qu'elle laisse voir d'autre. Si c'est celle d'un autre, vous voulez savoir sur quoi compter.

Cette adresse appartient à la Store API, l'interface que WooCommerce fournit pour tout ce qui sert au client : listes de produits, panier et commande. Grâce à elle, n'importe qui peut lire le catalogue publié : prix, images, catégories, attributs, variations, état du stock et avis approuvés. Les produits en brouillon, en attente, privés ou planifiés renvoient une erreur 404. Coûts, notes de commande, champs personnalisés, commandes et comptes clients ne figuraient dans aucune des réponses anonymes que nous avons recueillies.

Certains réglages modifient la réponse. Deux d'entre eux, la visibilité « Masqué » et le format d'affichage du stock, cachent moins que leur nom ne le laisse croire. Nous avons monté une boutique de test avec un produit dans chaque état, puis nous l'avons lue en visiteur anonyme. Nous avons ensuite passé des démos publiques de thèmes dans le Store API Checker gratuit.

Où se trouve la Store API

Toutes les adresses de la Store API commencent par le domaine de la boutique, suivi de /wp-json/wc/store/v1/. La documentation de la Store API la présente comme une API sans authentification, qui ne demande ni clé d'API ni jeton d'accès. Elle répond en JSON. L'adresse /wp-json/wc/store/v1 seule renvoie la liste des routes que la boutique prend en charge : 31 sur notre boutique de test.

Les routes du catalogue sont en lecture seule. Voici ce que ces routes et celle du panier ont renvoyé à une requête anonyme sur notre boutique de test :

Adresse, après /wp-json/wc/store/v1	Ce qui est revenu
/products	Les produits publiés, 10 par page sauf si vous en demandez plus
/products/<id> ou /products/<slug>	Un produit ou une variation
/products/categories	Chaque catégorie, avec sa description, son image et son nombre de produits
/products/tags, /products/attributes	Les étiquettes, et les attributs globaux comme Color ; leurs valeurs sous /products/attributes/<id>/terms
/products/reviews	Les avis approuvés, avec le nom de l'auteur, le texte et la note
/products/collection-data	Des totaux sur demande : fourchette de prix, produits par état de stock et par note
/cart	Le panier du visiteur lui-même, vide pour un nouveau visiteur

Une page contient au plus 100 produits. Une demande de 101 a reçu une erreur 400 : « per_page doit être compris entre 1 (inclus) et 100 (inclus) ». Deux en-têtes de réponse donnent la taille du catalogue : X-WP-Total pour le nombre de produits, X-WP-TotalPages pour le nombre de pages. C'est ainsi que la démo du thème Flatsome a annoncé ses 67 produits.

Un produit, champ par champ

Chaque produit de la liste arrivait avec 37 champs. La liste des champs était la même sur notre boutique et sur les démos Woostify et Flatsome. Voici une partie de la fiche de notre tablier en lin, raccourcie aux endroits marqués :

{
  "id": 14,
  "name": "Linen Apron",
  "sku": "APR-01",
  "prices": {
    "price": "2900",
    "regular_price": "3400",
    "sale_price": "2900",
    "currency_code": "USD",
    "currency_minor_unit": 2,
    …
  },
  "is_in_stock": true,
  "stock_availability": {
    "text": "12 en stock",
    "class": "in-stock"
  },
  "add_to_cart": { "maximum": 12, … },
  "extensions": {}
  …
}

Les prix sont des nombres entiers

Le tablier est vendu 29,00, et sa fiche indique "2900". Chaque prix est écrit dans la plus petite unité de la devise, et currency_minor_unit donne le nombre de décimales : 2 ici. La documentation applique la même règle à ses filtres de prix : 10025 vaut 100,25 USD et 1025 vaut 1 025 JPY. Lu de cette façon, le champ ne pose aucun problème de séparateur. La démo Flatsome est réglée avec une virgule décimale, et son API envoyait quand même "3900" pour un article à 39 dollars.

Notre boutique en français affichait des dollars : passer le site en français n'a pas changé la devise, qui reste un réglage de la boutique.

Le reste de la fiche

Autour des prix, on retrouve ce qu'affiche une page produit : le nom, l'UGS, l'adresse publique, les deux descriptions en HTML, puis les catégories, étiquettes, marques et attributs. Chaque image arrive avec son adresse en pleine taille, une miniature, les versions redimensionnées et son texte alternatif. La fiche donne aussi la note moyenne, le nombre d'avis, ainsi que le poids et les dimensions quand ils sont renseignés.

Un produit variable liste ses variations par ID, chacune avec ses valeurs d'attribut, et donne une fourchette de prix. Notre mug en grès renvoyait une fourchette de 1500 à 1800 et deux variations, Sand et Slate. La liste des produits laisse les variations de côté par défaut. Ajoutez ?type=variation pour les obtenir, ou ouvrez-en une par son ID.

Le dernier champ, extensions, était vide sur tous les produits lus. C'est là que les extensions publient leurs propres données, par une interface que la documentation décrit pour les développeurs. Sur une boutique équipée d'extensions, cherchez-y les champs absents de la liste de base.

Les produits qui répondent, et ceux qui renvoient une 404

Notre boutique de test comptait onze produits, répartis entre les états que propose la fiche produit. Pour chaque état, le tableau indique si le produit figurait dans la liste et ce que renvoyait sa propre adresse :

État dans l'administration	Dans la liste	À sa propre adresse
Publié, visibilité « Catalogue et recherche »	Oui	La fiche complète
Publié, en rupture de stock	Oui	La fiche complète, « En rupture de stock »
Visibilité « Catalogue » ou « Résultats de recherche uniquement »	Oui	La fiche complète
Visibilité « Masqué »	Oui	La fiche complète
Visibilité « Protégée par mot de passe »	Oui, descriptions vides	La fiche, descriptions vides
Brouillon, En attente, Privé ou Planifié	Non	404, « ID de produit non valide. »

Le statut de publication tranche

Les quatre produits non publiés sont restés hors de la liste, hors des résultats de recherche et hors de leur propre adresse. La documentation du point d'accès des produits pose la règle : seuls les produits publiés sont accessibles par la Store API.

« Masqué » retire le produit des pages, pas de l'API

Dans l'administration, la visibilité « Masqué » retire un produit de la boutique et des résultats de recherche. La Store API listait pourtant notre emballage cadeau, et une recherche sur « Gift » le trouvait. La liste accepte un filtre catalog_visibility. Sans lui, notre boutique renvoyait les sept mêmes produits qu'avec catalog_visibility=any. Avec visible, elle renvoyait les quatre réglés sur « Catalogue et recherche ». Un produit que les visiteurs ne doivent pas voir se met en Privé ou reste en Brouillon.

Un mot de passe ne couvre que les descriptions

Notre coffret pour revendeurs était protégé par un mot de passe. La liste donnait tout de même son prix de 120,00, sa catégorie, sa note et son nombre d'avis. Ses deux descriptions revenaient vides, et son avis restait absent de la route des avis. La documentation décrit le même comportement : les descriptions sont masquées tant que le bon mot de passe n'a pas été saisi, et les autres données du produit restent lisibles.

Une rupture de stock reste listée, sauf réglage contraire

La case « Masquer les produits en rupture de stock du catalogue » se trouve dans WooCommerce → Réglages → Produits → Inventaire. Une fois cochée, notre liste est passée de sept produits à six. La couverture en laine avait disparu, et sa propre adresse répondait toujours, avec « En rupture de stock ».

Le stock : le réglage d'affichage change les mots, pas la limite

Le même écran Inventaire propose un « Format d'affichage du stock » à trois choix. Nous les avons essayés tour à tour, avec le tablier à 12 unités puis à 2 ; son seuil de stock faible était de 3. Voici ce que disait sa fiche à chaque fois :

Format d'affichage du stock	Unités	stock_availability	low_stock_remaining	add_to_cart.maximum
Toujours afficher le stock restant (par défaut)	12	« 12 en stock »	null	12
Afficher le stock uniquement lorsqu'il est bas	12	« En stock »	null	12
Afficher le stock uniquement lorsqu'il est bas	2	« Plus que 2 en stock »	2	2
Ne jamais afficher le stock restant	12	« En stock »	null	12
Ne jamais afficher le stock restant	2	« En stock »	null	2

La phrase suit le réglage, et low_stock_remaining aussi. Le champ add_to_cart.maximum, la plus grande quantité qu'un client peut mettre au panier, ne le suit pas. Il valait le nombre d'unités en stock avec les trois choix. Sur un produit sans stock géré, comme la couverture en laine, il valait 9999.

La page produit porte le même chiffre. Avec « Ne jamais afficher », la page du tablier affichait « En stock », et son code source contenait "maximum":12 dans les données produit intégrées à la page. Si vos niveaux de stock sont sensibles, retenez que le réglage d'affichage change les mots de la page. Un stock géré fixe toujours la limite du panier que publient la page et l'API.

Ce qu'aucune requête anonyme n'a renvoyé

Nous avions donné au tablier un coût de 11,50, une note de commande et un champ personnalisé contenant une référence fournisseur. Aucune de ces trois valeurs n'est apparue dans les réponses enregistrées, en français comme en anglais. Aucun champ ne donnait le nombre de ventes d'un produit ni sa date de création. L'avis laissé en attente de modération n'est jamais apparu, pas plus que les adresses e-mail des auteurs d'avis.

Les avis approuvés sont publics, comme sur les pages produits. Chacun arrivait avec le nom de son auteur, le texte, la note, la date, un indicateur « vérifié » et les adresses d'une image d'avatar.

Les commandes et les clients n'ont pas de liste dans la Store API. Nous avons demandé à la route des commandes une commande existante, sans sa clé. Elle a répondu par une erreur 401 et le message « L'ID ou la clé de commande fournie n'est pas valide. »

D'après la documentation du point d'accès des commandes, cette route exige la clé de la commande, et l'e-mail de facturation pour une commande d'invité. La route du panier a renvoyé un panier vide, celui du nouveau visiteur. La page d'accueil de la documentation le résume : la Store API ne permet pas de consulter les autres clients ni les commandes par leur ID.

Les données absentes ici se trouvent derrière l'API REST à clés, wc/v3. Sans clé, elle a refusé les listes de produits, de commandes et de clients. Chaque refus disait « Désolé, vous ne pouvez pas lister les ressources. »

Les clés de cette API se créent dans WooCommerce → Réglages → Avancé → Clés de l'API REST. Chaque paire est rattachée à un utilisateur du site, selon la documentation de l'API REST.

Vérifier une boutique avec le Store API Checker

Lire ces adresses à la main convient pour une boutique. Le Store API Checker fait ce premier passage à partir du seul domaine, gratuitement et sans compte. Il demande la liste des routes, puis un enregistrement parmi les produits, les catégories et les avis. Le rapport indique si chaque ressource a répondu, en combien de temps, et combien d'éléments la boutique annonce.

Nous l'avons lancé sur des démos publiques d'éditeurs de thèmes. Voici ce qu'il a indiqué pour quatre d'entre elles :

Site	Rapport	Produits, catégories, avis
Démo du thème Flatsome	Catalogue accessible, Store API détectée	67, 15, 192
Démo du thème Shoptimizer	Catalogue accessible, Store API détectée	23, 12, 21
Une démo de thème derrière une vérification anti-robot	Catalogue indisponible, Store API indisponible	Indisponible
Le site WordPress d'un éditeur de thèmes, sans boutique à cette adresse	Catalogue indisponible, Store API indisponible	Indisponible

Sur les deux démos accessibles, chaque ligne est revenue en moins d'une seconde. Pour la démo Flatsome, les trois nombres sont ceux que nos propres requêtes avaient reçus.

« Catalogue indisponible » signifie que la route des produits n'a pas répondu par une liste JSON, et les deux refus avaient des causes différentes. Sur la démo protégée, les quatre requêtes ont reçu une erreur 403. Notre propre requête y a reçu une page intitulée « Just a moment... ». Sur le site de l'éditeur, WordPress a répondu par sa propre erreur « aucune route », une 404 : WordPress tourne à cette adresse, mais aucune boutique WooCommerce.

Qui envoie la requête compte aussi. La démo Shoptimizer a refusé la requête par défaut de curl avec une 403 et a répondu au Checker. La limitation du débit propre à la Store API est désactivée par défaut et ne vise que les requêtes POST. Une lecture du catalogue refusée vient donc d'autre chose que les réglages par défaut de WooCommerce : un pare-feu, une vérification anti-robot ou une extension de sécurité. Pour voir ce que voit un client, ouvrez l'adresse des produits dans votre propre navigateur. Si vous n'êtes pas encore sûr que le site tourne sous WooCommerce, commencez par le guide pour savoir si un site utilise WooCommerce.

D'un catalogue lisible à un fichier

Quand le rapport affiche « Catalogue accessible », son bouton « Extraire ce catalogue » ouvre ScrapeWoo avec l'adresse de la boutique. Vous y passez en revue les catégories et les produits publiés, et vous gardez ceux qui vous servent. Vous les exportez ensuite en CSV WooCommerce, CSV Shopify, CSV standard ou JSON, sans connexion à la boutique ni clé. Les prix sortent en montants, chaque variation reste rattachée à son parent, et les quantités en stock figurent dans le fichier quand la boutique les publie.

Le fichier contient le catalogue publié que décrit cet article. Coûts, notes de commande, champs personnalisés et produits non publiés sortent de l'administration de la boutique. Le guide pour exporter des produits WooCommerce compare les trois méthodes.

Si la boutique est la vôtre, passez votre domaine dans le Checker, puis ouvrez /wp-json/wc/store/v1/products?per_page=100 dans un navigateur. Cette page montre votre catalogue tel que la Store API le donne à n'importe quel visiteur anonyme.