Connecter Mirakl à votre logiciel métier : l'API vendeur des places de marché

Opérateur, vendeur, boutique : qui se connecte à quoi ?

Dans le vocabulaire de la documentation Mirakl, l'opérateur est l'entreprise qui exploite la place de marché et en fixe la configuration, et le vendeur y tient une boutique (shop). C'est cette boutique que le logiciel métier du vendeur pilote, par l'API vendeur. La documentation développeur de Mirakl sépare aussi deux produits : la place de marché de produits et une variante consacrée aux services, chacune avec sa propre API vendeur.

Trois conséquences pratiques en découlent :

• Une clé par boutique. La référence de l'API vendeur indique le schéma de sécurité Shop-API-Key. Un utilisateur qui a accès à plusieurs boutiques désigne la bonne par le paramètre shop_id ; sans lui, l'API travaille sur la boutique par défaut.
• Des règles propres à chaque opérateur. La documentation de l'appel A02, qui met à jour les informations de la boutique, prévient que certains champs peuvent ne pas être modifiables selon la configuration de l'opérateur. Deux places de marché Mirakl ne se comportent donc pas forcément de la même façon.
• Des questions à poser à l'opérateur. L'existence d'un environnement de test, les catégories et attributs attendus pour vos produits, les délais de traitement des commandes se vérifient auprès de chaque place de marché avant le développement.

Que permet l'API vendeur de Mirakl ?

L'API vendeur de Mirakl couvre le cycle de vente d'une boutique, du compte jusqu'aux retours. Les appels portent un code court (A01, OF24, RT11) qui sert de repère dans la documentation et dans les échanges avec l'opérateur.

Pour les places de marché de services, l'API vendeur dédiée suit la même logique : une commande à l'état WAITING_ACCEPTANCE est acceptée (SOR21) ou refusée (SOR22) par le vendeur, et la liste des commandes (SOR11) se filtre par dates de création et de dernière modification.

Fréquences d'appel : la contrainte qui dessine l'intégration

La référence de l'API vendeur Mirakl affiche, pour chaque appel, une fréquence d'utilisation recommandée et une fréquence maximale. Quelques exemples relevés en octobre 2026 :

• Lire les informations de la boutique (A01) : une fois par jour, valeur recommandée et maximale.
• Lister les retours (RT11) : toutes les 15 minutes recommandé, toutes les 5 minutes au plus.
• Créer, accepter ou clôturer un retour : à chaque événement concerné, pas davantage.

Dans les pages de référence consultées, nous n'avons pas relevé de mécanisme qui pousse les événements vers le vendeur. Le logiciel métier interroge donc Mirakl à intervalles réguliers, en filtrant sur la date de dernière mise à jour (RT11 accepte par exemple un filtre sur les retours modifiés après une date) et en parcourant les résultats par pagination à jeton (seek pagination). Un planificateur central, qui connaît la fréquence permise pour chaque appel et pour chaque boutique, évite de sortir du cadre documenté par Mirakl.

Cinq flux pour vendre sur plusieurs places de marché Mirakl

1. Un stock, plusieurs vitrines. Un fabricant de luminaires vend sur trois places de marché opérées sur Mirakl. Le logiciel métier calcule le disponible par article et met à jour l'offre de chaque boutique, avec une réserve propre à chaque canal pour limiter les ventes à découvert.
2. Un prix par place de marché. La politique tarifaire (prix plancher, promotion, frais de port) reste dans l'ERP ; le service produit un fichier de prix par boutique et l'importe par PRI01 aux heures creuses.
3. Les commandes vers la préparation. Le service relève les commandes de chaque boutique au rythme permis, crée la commande dans le logiciel de gestion en notant la place de marché d'origine, puis renvoie les informations d'expédition produites par l'intégration transporteur.
4. Les retours jusqu'à l'avoir. La liste des retours est relue toutes les quinze minutes ; l'entrepôt valide la réception (RT25), statue sur la conformité (RT26), et le logiciel métier déclenche l'avoir.
5. Les documents de conformité. Quand un justificatif expire, le logiciel métier dépose la nouvelle version sur chaque boutique par S32, au lieu qu'un salarié se connecte à chaque espace vendeur.

Chacun de ces flux supprime une ressaisie entre l'espace vendeur et la gestion interne, l'objectif décrit dans notre page pour éliminer les doubles saisies.

Erreurs, doublons, reprise : ce que l'intégration doit encaisser

• Les imports par fichier : un fichier de prix modifie des centaines d'offres d'un coup. Le service conserve chaque fichier envoyé, daté, pour rejouer un import ou expliquer un prix erroné.
• Les doublons : une commande relue lors de deux passages successifs n'est créée qu'une fois ; l'identifiant de commande Mirakl et l'identifiant de boutique forment ensemble la clé de correspondance.
• La reprise : le service mémorise, boutique par boutique, la date de la dernière mise à jour traitée et repart de là après une coupure, avec un léger chevauchement.
• Le journal : chaque appel, sa réponse et sa durée sont conservés pendant une période définie, utile pour répondre à un opérateur qui interroge un délai d'expédition.
• Les clés : une par boutique, stockée hors du code et remplaçable sans redéployer le service.
• Les données personnelles : les commandes contiennent nom et adresse des acheteurs de l'opérateur ; le logiciel métier ne conserve que ce qui sert à expédier et facturer, selon notre guide RGPD et logiciel métier.

Connecteur multicanal ou service sur mesure ?

Un vendeur peut aussi passer par un logiciel multicanal du marché, à condition qu'il prenne en charge les places de marché Mirakl visées et ses autres canaux. C'est la bonne réponse quand le catalogue est standard et que le logiciel de gestion est lui-même relié à cet outil : inutile de développer ce qui existe.

Le sur-mesure devient pertinent quand l'ERP est spécifique, que les règles de stock ou de prix sont propres à l'entreprise, que les retours suivent un circuit atelier particulier, ou qu'un abonnement indexé sur le volume finit par peser. Amazon, de son côté, se connecte par sa propre interface, la SP-API, présentée sur notre page Amazon Seller Central.

Ce que YMHB Web livre pour une intégration Mirakl

YMHB Web commence par le cadrage : liste des places de marché, fréquences permises pour chaque appel, source de vérité de chaque donnée (stock, prix, statut de commande), règles particulières de chaque opérateur. Le chiffrage suit ce cadrage. Le service est ensuite construit boutique par boutique, avec un planificateur qui respecte les fréquences de Mirakl, une table de correspondance des identifiants dans PostgreSQL et un journal consultable.

À la livraison, le client dispose des clés de boutique et de l'hébergement à son nom, du code, déposé chez lui, documenté et à lui au paiement intégral, et d'un écran de supervision : dernière synchronisation par boutique, commandes en attente, imports en erreur. Le principe général est décrit sur notre page API et intégrations entre vos logiciels.