← Tous les articles
Blog · Septembre 2026

Un prix pour vos comptes pro, aucun pour vos visiteurs anonymes

Un distributeur B2B affiche un prix catalogue à tout le monde, un prix net à ses comptes pro connectés, et parfois aucun prix du tout à un visiteur anonyme. La question vient tout de suite : qui décide, à chaque recherche, quel prix afficher ? Si la réponse est « un paramètre envoyé par le navigateur », n'importe qui peut le modifier et lire des prix pro sans être client.

Une règle par clé, jamais par requête

Chez Heurix, cette règle ne se négocie jamais à l'appel : elle se configure à part, sur la clé publique elle-même, côté serveur.

curl -X PUT https://api.heurix.fr/v1/keys/public/hxp_xxx/pricing \
  -H "Authorization: Bearer VOTRE_CLE_SERVEUR" \
  -H "Content-Type: application/json" \
  -d '{"catalog": "moncatalogue", "price_field": "price_pro"}'

price_field dit quel champ du produit sert de prix pour cette clé (price par défaut) ; price_visibletrue par défaut — dit si un prix est servi du tout. Une clé publique (préfixe hxp_) ne peut appeler que recherche, parcours de catalogue et événements de conversion ; la configurer demande une clé serveur (hx_), qui elle ne doit jamais quitter votre back-end.

Cette configuration est réservée aux clés serveur pour une raison précise : une clé publique vit dans un navigateur. Si elle pouvait déclarer elle-même son prix, n'importe quel visiteur lirait les prix pro en changeant un paramètre. Pour la même raison, une requête de recherche ne prend aucun paramètre de prix — la règle vient toujours de la clé, jamais de l'appel.

Ce qui rattrape une faute de frappe

catalog est obligatoire dans cet appel, et pas par excès de prudence : sans lui, un nom de champ mal orthographié passerait sans erreur, et tous les produits paraîtraient sans prix. Avec lui, un champ qu'aucun produit ne porte est refusé, et le message dit lesquels existent :

{"detail": "Aucun des 5000 produits de « moncatalogue » ne porte le champ
 « price_prro ». Champs de prix présents : price, price_pro."}

Une couverture partielle, elle, est acceptée et chiffrée. Un produit qui ne porte pas le champ configuré n'a pas de prix du tout pour autant — jamais un repli silencieux sur price, qui servirait discrètement le prix catalogue à un acheteur pro.

Le masquage ne s'arrête pas à un seul nom de champ

price_visible: false ne retire pas seulement price : « pas de prix sans compte » ne voudrait rien dire si price_pro continuait de sortir sous un autre nom. Est retiré tout champ dont le nom contient price, prix ou tarif — et la réponse liste ce qui a sauté plutôt que de vous le laisser découvrir :

{"price_visible": false,
 "removed_fields": ["price", "price_pro", "tarif_livraison"]}

Ce que votre front reçoit, dans tous les cas

Quel que soit le champ configuré, la recherche renvoie toujours le prix sous la même clé, price — votre intégration ne change pas. Un indicateur s'ajoute seulement quand la situation sort de l'ordinaire : "custom_price": true si ce n'est pas le prix catalogue, "price_visible": false si aucun prix n'est servi. Le nom réel du champ, lui, ne descend jamais jusqu'au navigateur ; il reste consultable côté serveur via GET /v1/keys/public. Une clé jamais configurée se comporte exactement comme avant — price, servi, sans qu'aucun de ces deux indicateurs n'apparaisse.

Jusque dans le tri et les filtres de prix

Le réglage ne s'arrête pas à la fiche produit. Trier par price_asc ou price_desc lit le champ de prix configuré pour la clé appelante — price par défaut, le prix pro pour une clé qui pointe vers price_pro. Une contrainte de prix posée en langage naturel dans la requête (« moins de 5 € ») filtre elle aussi sur le prix que sert cette clé, pas nécessairement sur price. Configurer une clé une seule fois suffit donc à aligner l'affichage, le tri et les filtres — sans une ligne de code supplémentaire côté intégration.

Une limite assumée

Une clé publique porte un seul jeu de règles de prix, pas un tarif par client individuel. Un distributeur qui distingue visiteurs anonymes, comptes pro et grands comptes crée une clé par population, et sert la bonne depuis son propre back-office — seul endroit où l'identité du client est réellement connue.

Créer une clé pour une nouvelle population se fait une fois, côté serveur :

curl -X POST https://api.heurix.fr/v1/keys/public \
  -H "Authorization: Bearer VOTRE_CLE_SERVEUR" \
  -H "Content-Type: application/json" \
  -d '{"allowed_origins": "monsite.fr,www.monsite.fr"}'

allowed_origins est optionnel mais recommandé : la clé n'est alors acceptée que depuis les domaines listés, ce qui la rend inutilisable si quelqu'un la recopie ailleurs. La même clé se retrouve ensuite avec GET /v1/keys/public, ou se révoque avec DELETE /v1/keys/public/{clé} si une population cesse d'exister.

Pour la suite

Si votre catalogue porte déjà un champ de prix pro à côté du prix catalogue, une clé publique dédiée le sert sans toucher à votre code de recherche. S'il vous faut aussi masquer complètement le prix pour les visiteurs anonymes, price_visible: false sur cette même clé suffit.

Essai gratuit 14 jours

Testez Heurix sur votre catalogue, sans carte bancaire.

Voir les tarifs