Manuel utilisateur
Centre d'aide/Manuel utilisateur/Connecter Rithum (Dsco) : commandes entrantes, messages ASN et de facture sortants

Connecter Rithum (Dsco) : commandes entrantes, messages ASN et de facture sortants

Dernière mise à jour 2026-11-01

Récupérez le Client ID et le Client Secret de votre compte fournisseur Rithum, laissez l’URL de base de l’API vide pour la production ou saisissez l’adresse du bac à sable pour essayer d’abord, testez, configurez le mapping par partenaire commercial, activez.

Le connecteur Rithum échange des documents EDI avec des détaillants via le réseau Rithum (API Dsco v3) : les documents de commande de vos partenaires commerciaux entrent et deviennent des commandes, et les documents ASN et de facture repartent vers ces partenaires, le stock étant échangé par la même connexion. Ce n’est pas une connexion de boutique — tout est organisé par partenaire commercial et par document.

Étapes : identifiants, test en deux temps, mapping par partenaire commercial, activation.

Prérequis#

  • Un compte fournisseur Rithum (Dsco). Les identifiants API de cette connexion appartiennent à ce compte fournisseur — ce n’est pas un identifiant de boutique.
  • Votre contact d’intégration Rithum joignable : le Client ID et le Client Secret sont émis en paire pour votre compte fournisseur et, si vous ne les avez pas encore, c’est le contact d’intégration qui les fournit.
  • Au moins un partenaire commercial (détaillant) avec lequel vous échangez des documents sur Rithum — commandes entrantes, ASN et factures sortants. Chaque partenaire est mappé séparément plus loin dans ce guide.
  • Un choix d’environnement pour la première connexion : laissez l’URL de base de l’API vide pour la production, ou saisissez l’adresse du bac à sable pour essayer la connexion d’abord. Les adresses exactes figurent dans l’étape de saisie ci-dessous.

Obtenir les identifiants#

  1. Cherchez dans votre compte fournisseur Rithum, dans les paramètres API / développeur, les identifiants API : le Client ID et le Client Secret. Ils appartiennent au compte fournisseur et sont émis en paire — il vous faut les deux.
  2. S’il n’y a aucun identifiant API à cet endroit, demandez-les à votre contact d’intégration Rithum. Précisez qu’il vous faut le Client ID et le Client Secret API de votre compte fournisseur.
  3. Copiez les deux valeurs en entier et conservez-les en lieu sûr. La paire ne fonctionne qu’ensemble : un Client ID d’une paire émise ne fonctionnera pas avec le Client Secret d’une autre.
  4. Si vous perdez le Client Secret, demandez à Rithum d’en émettre un nouveau — un secret perdu ne peut pas être récupéré depuis la connexion, car il n’est jamais réaffiché après l’enregistrement.

Remplir dans Integration#

  1. Ouvrez Integration → Marketplace → Rithum → Nouvelle connexion.
  2. URL de base de l’API (facultatif) : laissez ce champ vide pour la production — la connexion ira alors à https://api.dsco.io/api/v3. Pour essayer d’abord la connexion sur le bac à sable, saisissez à la place https://staging-api.dsco.io/api/v3. Saisissez exactement l’une de ces deux adresses, ou laissez le champ vide — ne tapez pas l’adresse d’un autre système.
  3. Client ID : collez le Client ID émis pour votre compte fournisseur Rithum. Attention à ne pas l’intervertir avec le Client Secret — l’ID va dans ce champ, le secret dans le suivant.
  4. Client Secret : collez le Client Secret de la même paire émise que le Client ID. Il est chiffré au repos et jamais réaffiché.

Tester la connexion#

Cliquez sur Tester la connexion. Le test se déroule en deux temps, et les deux doivent réussir pour que la connexion compte comme fonctionnelle. Il échange d’abord votre Client ID et votre Client Secret contre un token d’accès auprès de Rithum. Il utilise ensuite ce token pour appeler la vérification /hello à l’adresse API que vous avez choisie — l’adresse de production quand l’URL de base est vide, ou l’adresse du bac à sable que vous avez saisie. Un succès signifie que les deux étapes ont fonctionné : vos identifiants ont été acceptés et l’API Rithum a répondu. En cas d’échec, gardez l’erreur affichée par le test : elle indique si c’est l’étape du token ou l’étape /hello qui a échoué, et la FAQ ci-dessous traite chaque cas.

Mapping / choisir un modèle#

Sur Rithum, le mapping se fait par partenaire commercial, pas en un seul réglage pour toute la connexion. Pour chaque partenaire détaillant, choisissez le modèle de ce partenaire et vérifiez comment ses documents de commande se mappent dans la commande standard — numéro de commande, lignes, quantités, coordonnées de livraison — et comment les données ASN et de facture se mappent en retour dans le format de document attendu par ce partenaire. Un partenaire sans mapping configuré n’a nulle part où faire atterrir ses documents : ses commandes ne peuvent pas entrer, et les documents ASN et de facture ne peuvent pas être construits pour lui. Un test de connexion réussi prouve seulement que les identifiants et l’adresse API fonctionnent — cela ne signifie pas qu’un partenaire soit déjà mappé. Traitez vos partenaires un par un et vérifiez l’aperçu de mapping de chacun avant d’activer.

Aller-retour des documents Rithum : documents de commande entrants du partenaire, documents ASN et de facture sortants.

Activer#

Après activation, les documents de commande de vos partenaires commerciaux mappés entrent et deviennent des commandes, le stock est échangé par la connexion, et les documents ASN et de facture sont renvoyés à chaque partenaire via Rithum. Les partenaires sans mapping restent silencieux — rien ne circule pour eux tant que leur mapping n’est pas configuré. Si vous avez testé sur l’adresse du bac à sable, remettez l’URL de base de l’API à vide (production) et testez à nouveau avant d’activer pour les échanges réels. Surveillez les premiers documents de chaque partenaire dans Runs / Logs avant de laisser l’échange sans surveillance.

FAQ#

Le test échoue à l’étape du token

Rithum n’a pas accepté les identifiants, donc aucun token n’a été émis et le test n’a jamais atteint la vérification /hello. Les causes habituelles sont une valeur copiée de façon incomplète, le Client ID et le Client Secret collés dans les champs l’un de l’autre, ou les deux valeurs venant de paires émises différentes — l’ID et le secret ne fonctionnent que comme la paire dans laquelle ils ont été émis.

Recopiez les deux valeurs depuis les paramètres API / développeur de votre compte fournisseur, en veillant à ce que le Client ID aille dans le champ Client ID et le Client Secret dans le champ Client Secret, tous deux de la même paire émise. Si vous n’avez plus le secret, ou si vous n’êtes pas sûr de la paire à laquelle vos valeurs appartiennent, demandez à votre contact d’intégration Rithum une paire nouvellement émise, saisissez les deux valeurs, enregistrez et testez à nouveau.

Le token est émis, mais la vérification /hello échoue

Vos identifiants ont été acceptés — l’étape du token a réussi — mais l’adresse API visée par la connexion n’a pas répondu à la vérification /hello, donc la connexion ne compte pas encore comme connectée. La cause habituelle est l’URL de base de l’API : elle a été saisie différemment des deux adresses utilisées par cette connexion, modifiée à la main, ou elle pointe encore vers le bac à sable alors que vous vouliez tester la production (ou l’inverse).

Réglez l’URL de base de l’API sur exactement l’une des deux adresses : laissez-la vide pour la production (https://api.dsco.io/api/v3), ou saisissez l’adresse du bac à sable https://staging-api.dsco.io/api/v3 si vous testez sur le bac à sable. Enregistrez et testez à nouveau. Si la vérification /hello échoue toujours avec l’adresse exacte, gardez l’erreur affichée par le test et consultez Runs / Logs avant de réessayer.

Connecté, mais les commandes d’un partenaire n’arrivent jamais

La connexion elle-même fonctionne — le test passe et d’autres partenaires peuvent circuler normalement. Le problème est que ce partenaire commercial n’a pas de mapping configuré, ou que vous êtes encore connecté à l’adresse du bac à sable alors que le partenaire envoie en production, donc ses documents de commande n’ont nulle part où atterrir sur cette connexion.

Vérifiez d’abord l’URL de base de l’API : pour les échanges réels, elle doit être vide (production). Ouvrez ensuite le mapping de ce partenaire commercial, choisissez son modèle et vérifiez l’aperçu de mapping avec l’un de ses vrais documents de commande — numéro de commande, lignes, quantités et coordonnées de livraison doivent tous atterrir dans la commande standard. Enregistrez le mapping, puis vérifiez Runs / Logs pour le prochain document de ce partenaire.

Les commandes entrent, mais les documents ASN et de facture n’arrivent pas chez le partenaire

L’entrant fonctionne, donc les identifiants et l’adresse API sont bons. Le manque se situe côté sortant dans le mapping de ce partenaire : le partenaire est mappé pour les documents de commande entrants, mais ses documents ASN et de facture sortants n’ont jamais été configurés, donc les résultats du fulfillment n’ont aucun document pour repartir.

Ouvrez le mapping de ce partenaire commercial et configurez aussi le côté sortant : documents ASN et documents de facture, dans le format attendu par ce partenaire. Vérifiez l’aperçu de mapping avec une commande déjà traitée, puis surveillez Runs / Logs pour le prochain document sortant vers ce partenaire.