Périmètre

🔗 Data Hub

📘

NEW

Import Full — Suppression des attributs et custom fields via le Data Hub

Contexte

Jusqu'à présent, les imports via le Data Hub (SFTP, connecteur API) ne permettaient pas de supprimer la valeur d'un attribut ou d'un custom field existant sur une entité. Envoyer une valeur vide ou null dans un fichier d'import n'avait aucun effet : la valeur en base était conservée. Pour les clients qui synchronisent leurs données produit ou compte depuis un ERP, il était donc impossible de « vider » un champ sans intervention manuelle.

Fonctionnement

Un nouveau paramètre importFull est désormais disponible sur la configuration des jobs d'import (CSV, connecteur API, Mirakl). Lorsqu'il est activé :

• Les attributs produit dont la valeur est null dans le fichier d'import sont supprimés de l'entité cible.
• Les custom fields dont la valeur est null sont également supprimés de l'entité cible.

Lorsque importFull est désactivé (valeur par défaut), le comportement reste inchangé : les valeurs vides ou null sont ignorées et les données existantes sont préservées. Tous les jobs existants conservent automatiquement ce comportement par défaut — aucune action n'est requise.

Le paramètre est configurable à la création (POST /job) et à la modification (PUT /job/{id}) d'un job, et visible en lecture (GET /job/{id}).

📄 Documentation : Job Configuration Overview

👉 Côté métier : il est désormais possible de supprimer des attributs et custom fields directement via les flux d'import, sans intervention manuelle, garantissant une synchronisation fidèle avec le système source.

👉 Côté technique : nouveau champ importFull (booléen, défaut false) sur la configuration des jobs d'import. Rétrocompatibilité totale — aucun changement de comportement sans activation explicite.

---

Import de commandes — Mise à jour du statut sans lignes de commande

Contexte

L'import de commandes via SFTP ou connecteur API imposait jusqu'ici de fournir les lignes de commande, même pour une simple mise à jour de statut sur une commande logistique existante. Cette contrainte rendait les cas d'usage de mise à jour de statut inutilement complexes.

Fonctionnement

Il est désormais possible d'envoyer un fichier csv ou payload minimal contenant uniquement l'identifiant de la commande (External Id ou Reference) et le nouveau statut, sans fournir de lignes de commande. Le système met à jour le statut de la commande logistique en conservant intactes les informations sur la commande.

Si le csv ou payload ne contient pas de lignes et que la commande référencée n'existe pas, une erreur de validation explicite est retournée.

📄 Documentation : Order Update Import

👉 Côté métier : les mises à jour de statut de commandes logistiques sont simplifiées — un fichier contenant uniquement l'identifiant et le statut suffit.

👉 Côté technique : le job d'import CSV/Connecteur API accepte un csv/payload sans lignes de commande pour les mises à jour de statut.

🛠️ API

📘

NEW

Gestion des shipping types — Création et consultation

Contexte

Dans le cadre du nouveau module de livraison, les opérateurs ont besoin de définir des types d'expédition (shipping types) pour configurer leurs options de livraison. Deux nouveaux endpoints permettent désormais de créer et de consulter les shipping types disponibles sur la plateforme.

Fonctionnement

Création — Un opérateur peut créer un shipping type en fournissant un nom (obligatoire) et une description (optionnelle). Un identifiant peut être spécifié manuellement ; s'il est absent, il est généré automatiquement. L'identifiant est unique sur la plateforme et immutable après création. Le shipping type est immédiatement disponible pour configuration.

Consultation — La liste des shipping types est paginée et filtrable :

• Recherche partielle sur le nom (insensible à la casse)
• Filtrage par plage de dates de création et de modification
• Tri par name, createdAt ou updatedAt (défaut : createdAt:desc)

Tous les filtres sont combinés en logique AND.

Impact API

POST /v1/shipping-types (operationId : ADM-SHIPPING-TYPE-100) Crée un shipping type. Retourne 201 Created avec l'identifiant de la ressource créée.

GET /v1/shipping-types (operationId : ADM-SHIPPING-TYPE-550) Liste paginée et filtrable des shipping types. Retourne 200 OK.

Les deux routes requièrent dj-client: OPERATOR.

📄 Documentation : Shipping Types

👉 Côté métier : les opérateurs peuvent désormais définir et consulter leurs types d'expédition directement via l'API, première brique du module de livraison.

👉 Côté technique : deux nouveaux endpoints administration sur /v1/shipping-types (POST + GET). Pagination, filtres et tri standards DJUST.

---

Gestion des familles logistiques — Consultation et détachement de catégories

Contexte

Le module de livraison introduit la notion de famille logistique, qui permet de regrouper des catégories de classification pour appliquer des règles d'expédition cohérentes. Deux nouveaux endpoints permettent de consulter les familles logistiques et de détacher des catégories de classification d'une famille.

Fonctionnement

Consultation — La liste des familles logistiques est paginée et filtrable :

• Recherche partielle sur le nom (insensible à la casse)
• Filtrage par identifiants de catégories de classification rattachées
• Filtrage par plage de dates de création et de modification
• Tri par name, createdAt ou updatedAt (défaut : createdAt:desc)

Chaque famille logistique indique si elle est système (famille par défaut) et expose le nombre de catégories de classification rattachées.

Détachement de catégories — Il est possible de retirer une ou plusieurs catégories de classification d'une famille logistique. Les catégories détachées retombent automatiquement sur la famille logistique par défaut (système). Si une catégorie listée n'est pas rattachée à la famille ciblée, elle est ignorée silencieusement. Un tableau vide ou null est accepté sans erreur et n'entraîne aucune modification.

Les identifiants de catégories attendus sont les External IDs (externalId).

Impact API

GET /v1/logistic-families (operationId : ADM-LOGISTIC-FAMILY-550) Liste paginée et filtrable des familles logistiques. Retourne 200 OK.

DELETE /v1/logistic-families/{logisticsFamilyId}/classification-categories (operationId : ADM-LOGISTIC-FAMILY-350) Détache des catégories de classification d'une famille logistique. Retourne 204 No Content.

Les deux routes requièrent dj-client: OPERATOR.

📄 Documentation : Logistic Families

👉 Côté métier : les opérateurs peuvent consulter leurs familles logistiques et réorganiser le rattachement des catégories de classification, avec un retour automatique vers la famille par défaut pour les catégories détachées.

👉 Côté technique : deux nouveaux endpoints administration sur /v1/logistic-families (GET + DELETE). Les catégories détachées sont référencées par External ID. Pagination, filtres et tri standards DJUST.

👍

UPDATE

Recherche étendue sur les Offer Inventories

Contexte

Le paramètre search de l'endpoint GET /internal/v1/offer-inventories ne couvrait pas les identifiants d'offre, obligeant les utilisateurs à utiliser d'autres moyens pour retrouver un offer inventory à partir de son offre.

Fonctionnement

Le paramètre search prend désormais en charge deux nouveaux critères de recherche :

• Offer External Id — l'identifiant externe de l'offre (fourni par le client / ERP)
• Offer Djust Id — l'identifiant interne DJUST de l'offre

Les champs de recherche déjà couverts par search restent fonctionnels sans régression.

Impact API

GET /internal/v1/offer-inventories?search={value} Le paramètre search matche désormais également sur l'Offer External Id et l'Offer Djust Id.

👉 Côté métier : les offer inventories sont désormais directement retrouvables à partir de l'identifiant de leur offre, simplifiant la recherche depuis le Back-Office ou les intégrations.

👉 Côté technique : le paramètre search de GET /internal/v1/offer-inventories couvre deux champs supplémentaires (Offer External Id, Offer Djust Id). Aucun changement de contrat, aucun nouveau paramètre.

---

---

Paramètre de tri — Support du format property:direction

Contexte

Les APIs DJUST exposaient le paramètre de tri sort uniquement au format property,direction (séparateur virgule).

Fonctionnement

L'ensemble des APIs DJUST exposant un paramètre sort acceptent désormais les deux formats :

• property:direction — format conforme à la convention DJUST (recommandé)
• property,direction — format historique, conservé pour la rétrocompatibilité

Les deux séparateurs sont interprétés de manière strictement équivalente. Le tri multi-critères fonctionne avec les deux formats, y compris en les combinant dans une même requête. Les entrées utilisant un séparateur non reconnu (ex. property-direction) sont ignorées silencieusement, conformément au comportement existant.

Aucune migration n'est requise pour les intégrations existantes — le format historique reste pleinement supporté.

Impact API

Toutes les routes exposant un paramètre sort (Admin et Shop) sont concernées. Exemples :

• ?sort=createdAt:desc (nouveau format)
• ?sort=name:asc&sort=createdAt:desc (multi-tri)
• ?sort=createdAt,desc (format historique, toujours supporté)

📄 Documentation : Get Logisitic Orders List

👉 Côté métier : aucun impact — le comportement existant est préservé, le nouveau format s'ajoute de manière transparente.

👉 Côté technique : le format property:direction est désormais accepté sur toutes les routes paginées. Il est recommandé de l'adopter pour les nouvelles intégrations. Aucun breaking change.