La version 3.105.0 initialement prévue la semaine du 16 février sortira avec la 3.106.0 la semaine du 24 février 2026.

Périmètre

BackOffice

• Ajout des noms de comptes (avec tris) sur les listes de configuration des Buying Policies d'encours.

Afin de faciliter la lecture et la configuration, les noms sont désormais affichés dans les listes de configuration des tolérances d'encours et dans les blocages de comptes.

Il est aussi possible de trier sur le nom du compte par ordre alphabétique ou inverse.

• Ajout de l'affectation de stores aux utilisateurs opérateurs

Les utilisateurs opérateurs sont désormais liés aux stores. Ainsi, il est possible d'activer une segmentation par store entre les utilisateurs du backoffice.

⚠️

Attention

• Tous les utilisateurs créés avant cette version seront systématiquement affectés sur TOUS les stores existants pour assurer la rétrocompatibilité.
• Les environnements sans store ne sont pas concernés.
• La création d'un nouvel opérateur après cette version n'aura pas d'affectation par défaut. Il faudra explicitement préciser les stores liés à cet utilisateur.

• Import et mise à jour de commandes via le Connecteur API

Le job d'import de commandes est désormais disponible via le Connecteur API

Il permet d’exécuter les mêmes opérations que l’import de commandes par CSV tout en s’intégrant directement à vos APIs :

• Créer des commandes externes
• Mettre à jour des commandes existantes (internes ou externes)
• Ajouter ou modifier des lignes
• Supprimer des lignes
• Mettre à jour le statut des commandes

Lors de la configuration du job, il suffit de sélectionner le type ORDER et le connecteur de type API.

• Renommage du job de mise à jour de commandes internes via le Connecteur API

Le job de mise à jour de commandes internes via le Connecteur API est désormais nommé: ORDER_UPDATE.

Il permet exclusivement de mettre à jour des commandes internes en s’intégrant directement à vos APIs :

• Ajouter ou modifier des lignes
• Supprimer des lignes
• Mettre à jour le statut des commandes

Lors de la configuration du job, il suffit de sélectionner le type ORDER_UPDATE.

API

📘

NEW

Stores

• Affectation de stores aux operator users

Contexte

Dans un environnement multi-stores, tous les operator users avaient jusqu'ici une visibilité sur l'ensemble des stores du tenant dans le Back Office DJUST. Il n'était pas possible de restreindre l'accès d'un utilisateur à un périmètre de stores spécifique.

Cette évolution introduit la possibilité de rattacher un operator user à un ou plusieurs stores, posant ainsi les bases d'une segmentation par store dans le Back Office. Un opérateur affecté uniquement aux stores France et Belgique ne verra pas les stores Allemagne ou Espagne dans son interface.

Fonctionnement

• Accès explicite uniquement : il n'existe pas de mode implicite "tous les stores". L'affectation doit être réalisée store par store. Pour donner accès à l'ensemble des stores, il faut envoyer la liste complète.
• Pas d'héritage automatique : lorsqu'un nouveau store est créé sur le tenant, il n'est pas automatiquement accessible aux operator users existants. L'accès doit être explicitement ajouté.
• Création d'un operator user : par défaut, aucun store n'est affecté à la création. L'affectation se fait dans un second temps via les endpoints dédiés.
• Identification des stores : les stores sont référencés par leur externalId (identifiant externe).
• Rétrocompatibilité : les operator users existants ne sont pas impactés. Tant qu'aucune affectation n'est configurée, le comportement reste inchangé.

Impact API

Nouvelle sous-ressource sur le domaine Operator Users :

Les endpoints d'écriture (PUT, PATCH, DELETE) acceptent un body avec le champ storeExternalIds (tableau d'identifiants externes de stores). Accès réservé aux operator users (dj-client: OPERATOR).

Bénéfices

👉 Côté métier : permet de segmenter la visibilité des operator users par store dans le Back Office, renforçant le contrôle des accès dans les organisations multi-stores.

👉 Côté technique : 4 nouveaux endpoints CRUD dédiés à la gestion de l'affectation store/operator user, avec une approche explicite (pas de "all stores" implicite) garantissant un contrôle fin des accès.

Transactions

• API de détail d’un événement de transaction de paiement

Contexte

Djust expose désormais une API dédiée pour récupérer le détail complet d’un événement de transaction (authorization, capture, refund, etc.) à partir de son identifiant eventId.

Objectif : permettre l’investigation fine d’un paiement à une étape précise, avec références PSP, informations d’erreur, et breakdown des montants / commissions selon le profil utilisateur.

Nouvelle API

ADM-TRANSACTION-552 - GET /v1/transactions/events/{eventId}

Retourne la fiche détail d’un event identifié par eventId, destinée à alimenter la page “Event detail”.

Règles de visibilité

• OPERATOR : peut accéder à n’importe quel event (tous suppliers / toutes transactions).
• SUPPLIER : peut accéder uniquement aux events liés à ses propres commandes logistiques / transactions.

• Liste des événements de transaction de paiement

Contexte

Une nouvelle API Backend permet désormais de consulter la liste des événements de paiement associés à une transaction commerciale, avec support de la recherche, des filtres, du tri et de la pagination.

Cette API expose une vision event-based du cycle de vie d’un paiement (authorization, capture, refund, etc.) afin de faciliter le diagnostic, l’audit et le support.

Nouvelle API

ADM-TRANSACTION-551 - GET /v1/transactions/events

Permet de récupérer la liste chronologique des événements rattachés à une transaction.

Règles de visibilité

• OPERATOR :
  • Accès à tous les events de toutes les transactions
  • Accès aux suppliers liés aux events
• SUPPLIER:
  • Accès uniquement aux events rattachés à ses propres transactions / commandes logistiques

👍

UPDATE

Cart v1 / v2

• L'ensemble des routes historiques Cart v1 et v2 sont désormais dépréciées

Il est fortement conseillé de migrer progressivement vers les API "Order based checkout". Les routes historiques Cart v1 et v2 ne sont plus mises à jour.

Les routes sont évidemment toujours disponibles mais ne bénéficieront plus d'évolution (hors anomalie bloquante).

L'ensemble de ces routes sera supprimé à moyen terme quand l'ensemble des migrations client aura été sécurisée.

Liste des APIs concernées :

CART-100 : POST /v1/shop/carts (Créer un panier)
CART-300 : DELETE /v1/shop/carts (Supprimer un panier)
CART-500 : GET /v1/shop/carts (Récupérer un panier)
CART-201 : PUT /v1/shop/carts/{cartId} (Affecter ou modifier une adresse de facturation/livraison)
CART-200 : PUT /v1/shop/carts/{cartId}/lines (Ajouter/Mettre à jour/Supprimer des lignes)
CART-301 : DELETE /v1/shop/carts/{cartId}/lines (Supprimer des lignes de panier)

ORDER-202 : PUT /v1/shop/commercial-orders/{orderCommercialId}/shipping-address
ORDER-100 : POST /v1/shop/commercial-orders

Fast-cart v1 :
CART-101 : POST /v1/shop/carts/import (Initialiser un import fast-cart depuis un fichier)
CART-551 : GET /v1/shop/carts/import (Récupérer la progression d'un import fast-cart)
CART-506 : GET /v1/shop/carts/import/error-report (Récupérer le rapport d'import fast-cart)

CART-550 : GET /v2/shop/carts (Récupérer les paniers paginés)
CART-351 : DELETE /v2/shop/carts (Supprimer tous les paniers)
CART-100 : POST /v2/shop/carts (Créer un panier)
CART-500 : GET /v2/shop/carts/{cartId} (Récupérer un panier par ID)
CART-200 : PUT /v2/shop/carts/{cartId} (Mettre à jour un panier)
CART-300 : DELETE /v2/shop/carts/{cartId} (Supprimer un panier)
CART-101 : POST /v2/shop/carts/{cartId}/initialize-orders (Initialiser les commandes en DRAFT)
CART-551 : GET /v2/shop/carts/{cartId}/lines (Récupérer les lignes de panier paginées)
CART-150 : PUT /v2/shop/carts/{cartId}/lines (Ajouter/Mettre à jour/Supprimer des lignes)
CART-350 : DELETE /v2/shop/carts/{cartId}/lines (Supprimer des lignes de panier)
CART-151 : PUT /v2/shop/carts/{cartId}/lines-by-variant (Mettre à jour les lignes par variante)

Mapper

• Les routes historiques listées ci-dessous sont désormais dépréciées

Elles ont été dupliquées et remplacées par de nouveaux endpoints respectant les standards REST.

Les routes dépréciées restent disponibles mais ne sont plus amenées à évoluer.

Ces routes seront supprimées à moyen terme après sécurisation des migrations.

• Filtrage des exports de commandes par Supplier

Contexte

Lors d’un export de commandes, il est parfois nécessaire d’envoyer uniquement les commandes d’un Supplier donné vers son système cible. Jusqu’ici, un job unique exportait l’ensemble des commandes vers un ERP central, laissant le dispatch multi-fournisseurs côté client.

Fonctionnement

Les endpoint POST /jobout et PUT /jobout/{jobOutId} acceptent désormais un champ suppliers dans le body de la requête.

• Ajout ou mise à jour : le champ suppliers permet de définir la liste des supplierExternalId autorisés pour le job d’export. Lors d’une création ou d’une mise à jour, la valeur fournie remplace la configuration existante.
• Suppression : envoyer suppliers avec une chaîne vide ("") efface le filtrage par Supplier.
• Comportement par défaut : si suppliers est vide ([]) ou Null, toutes les commandes éligibles sont exportées.

Impact API

Endpoint : POST /jobout

• Nouveau champ modifiable : suppliers (type list)
• Réponse : 201 Created (inchangé)
• Accès : dj-client: OPERATOR
• Rétrocompatibilité : aucun impact sur les intégrations existantes — le champ est optionnel.

Endpoint : PUT /jobout/{jobOutId}

• Nouveau champ modifiable : suppliers (type list)
• Réponse : 200 OK (inchangé)
• Accès : dj-client: OPERATOR
• Rétrocompatibilité : aucun impact sur les intégrations existantes — le champ est optionnel.

Bénéfices

👉 Côté métier : permet de gérer nativement les exports de commandes multi-fournisseurs directement depuis DJUST.

👉 Côté technique : nouveau champ optionnel sur un endpoint existant, aucun breaking change. Les intégrations actuelles fonctionnent sans modification.

• Création de job d'import de commandes via API pour le Connecteur API

Contexte

Avec l’introduction de l’import et de la mise à jour de commandes via Connecteur API, il est désormais possible de configurer un job dédié par API.

Fonctionnement

L’endpoint POST /v1/mapper/jobs accepte désormais un nouveau type de job ORDER_API_JOB dans le champ jobType.

Impact API

• Endpoint : POST /v1/mapper/jobs
• Champ : jobType
• Nouvel enum : ORDER_API_JOB
• Réponse : 201 Job successfully created (inchangé)
• Accès : dj-client: OPERATOR

Bénéfices

👉 Côté métier : Permet de configurer des imports de commandes via API sans dépendre d’un flux CSV.

👉 Côté technique : nouvel enum sur un endpoint existant, aucun breaking change. Les intégrations actuelles fonctionnent sans modification.

• Renommage du type de job d’update de commandes internes via le Connecteur API

Contexte

Avec l’introduction de l’import de commandes via Connecteur API, le périmètre de l'objet Order a été clarifié afin de mieux distinguer :

• l’import et la mise à jour globale de commandes.
• la mise à jour spécifique des commandes internes.

Dans ce cadre, le type de job précédemment nommé ORDER_API_JSON_JOB porte le nouveau nom ORDER_UPDATE_API_JSON_JOB

Fonctionnement

L’endpoint POST /v1/mapper/jobs accepte désormais le type de job ORDER_UPDATE_API_JSON_JOB dans le champ jobType.

Ce type de job est dédié uniquement à la mise à jour de commandes internes via Connecteur API.

Aucun changement fonctionnel n’est introduit :

• le comportement du job reste identique
• seule la dénomination évolue pour refléter plus clairement son usage.

Impact API

• Endpoint : POST /v1/mapper/jobs
• Enum renommé : ORDER_API_JSON_JOB → ORDER_UPDATE_API_JSON_JOB
• Réponse : 201 Job successfully created (inchangé)
• Accès : dj-client: OPERATOR

• Renommage du type de job d'import et de mise à jour de commandes via CSV

Contexte

Avec l’introduction de l’import de commandes via Connecteur API, le périmètre de l'objet Order a été clarifié afin de mieux distinguer :

• l’import et la mise à jour globale de commandes.
• la mise à jour spécifique des commandes internes.

Dans ce cadre, le type de job précédemment nommé EXTERNAL_ORDER_CSV_JOB porte le nouveau nom ORDER_CSV_JOB

Fonctionnement

L’endpoint POST /v1/mapper/jobs accepte désormais le type de job ORDER_CSV_JOB dans le champ jobType.

Ce job permet toujours par CSV :

• La création de commandes externes
• La mise à jour de commandes existantes
• L’ajout, la modification ou la suppression des lignes
• La mise à jour du statut des commandes

Impact API

• Endpoint : POST /v1/mapper/jobs
• Enum renommé : EXTERNAL_ORDER_CSV_JOB → ORDER_CSV_JOB
• Réponse : 201 Job successfully created (inchangé)
• Accès : dj-client: OPERATOR

Orders

• Mise à jour de l'external ID sur les commandes logistiques

Contexte

Lorsqu'une commande logistique est manipulée à la fois depuis un front-end (Back Office) et un middleware (ERP, WMS…), il est nécessaire de pouvoir injecter ou mettre à jour l'identifiant externe (externalId) de la commande après sa création. Jusqu'ici, ce champ ne faisait pas partie des champs modifiables via l'API d'administration.

Fonctionnement

Le endpoint ADM-ORDER-201 - PATCH /v1/logistic-orders/{logisticOrderId} accepte désormais le champ externalId dans le body de la requête :

• Ajout ou mise à jour : envoyer externalId avec une valeur non vide assigne ou remplace l'identifiant externe existant.
• Suppression : envoyer externalId avec une chaîne vide ("") efface l'identifiant externe.
• Pas d'impact sur le cycle de vie : la modification de l'externalId n'affecte ni le statut de la commande, ni l'identifiant interne DJUST, ni les traitements déjà effectués.
• Mise à jour partielle : comme pour les autres champs du PATCH (shippingTrackingUrl, customFieldValues), seuls les champs envoyés sont modifiés.

Impact API

• Endpoint : PATCH /v1/logistic-orders/{logisticOrderId} — ADM-ORDER-201
• Nouveau champ modifiable : externalId (type string)
• Réponse : 204 No Content (inchangé)
• Accès : dj-client: OPERATOR ou SUPPLIER
• Rétrocompatibilité : aucun impact sur les intégrations existantes — le champ est optionnel.

Bénéfices

👉 Côté métier : permet de synchroniser l'identifiant externe d'une commande logistique entre le Back Office et un système tiers (ERP, WMS), sans recréation de commande.

👉 Côté technique : nouveau champ optionnel sur un endpoint existant, aucun breaking change. Les intégrations actuelles fonctionnent sans modification.