# Dossier de test

> Testez un lot DDEX avant de le livrer : le dossier SFTP /test et POST /ddex/validate. Rien n’est créé.

<!-- Generated from openapi/hills-v1.json by scripts/api-reference.mjs. Edit the operation in hills-music (server/lib/ops), not this page. -->

Chaque boîte de dépôt DDEX correspond à un identifiant SFTP avec exactement deux dossiers : `/test` vérifie un lot sans rien créer, `/production` l’importe. L’API n’a qu’un seul type de clé (`hm_live_…`) ; son circuit de test est [POST /ddex/validate](https://developer.hillsmusic.com/fr/reference/ddex-deliveries/#test-a-ddex-message-or-batch). Un test exécute toutes les vérifications d’une livraison (XML, règles HILLS, fichiers audio, pochettes et vidéos, UPC et ISRC comparés au catalogue, genres, territoires et accords) et laisse le catalogue tel quel : ni sortie, ni enregistrement, ni artiste, ni code, ni livraison.

<a id="over-sftp"></a>

## Par SFTP

Un identifiant par compte, créé avec la boîte de dépôt. Déposez dans `/production/<batch>/` pour livrer, ou dans `/test/<batch>/` pour tester ; un lot est un dossier contenant le XML ERN (4.3 recommandée) et les fichiers qu’il référence, clôturé par son fichier marqueur (`BatchComplete_*.xml` ou n’importe quel `*.complete`).

| Chemin | Ce qui se passe |
| --- | --- |
| `/production/<batch>/` | Dès l’arrivée du marqueur, le lot est importé : chaque sortie devient un brouillon dans votre catalogue, puis passe par la vérification et la livraison aux plateformes comme d’habitude. Un dossier par lot. |
| `/test/<batch>/` | Dès l’arrivée du marqueur, le lot est lu et entièrement vérifié. Rien n’est créé. Le rapport est écrit à côté : `/test/<batch>.report.txt` et `/test/<batch>.report.json`. |
| `/test/<file>.xml` ou `/test/<file>.zip` | Un message ou un zip seul, testé de la même façon ; le rapport est écrit dans `/test/<file>.report.txt` et `.report.json`. |
| Tout autre fichier dans `/test/` | Un test de connexion (un `ping.txt` suffit) : la page DDEX du tableau de bord indique que la connexion fonctionne. |

Un dossier de lot de production qui ne reçoit jamais son marqueur est supprimé au bout de 7 jours ; tout ce qui se trouve dans `/test` (lots, rapports, fichiers de test de connexion) est supprimé après le même délai.

<a id="over-the-api"></a>

## Par l’API

## Production

Données réelles. POST /ddex (et les envois directs) livrent des lots DDEX qui deviennent des sorties en brouillon dans votre catalogue, puis passent par la vérification et la livraison aux plateformes comme d’habitude. SFTP : le dossier /production.

## Test

La même clé. POST /ddex/validate accepte un .xml ou un .zip, exécute toutes les vérifications d’une livraison (XML, règles HILLS, fichiers audio, pochettes et vidéos, UPC et ISRC comparés au catalogue, genres, territoires et accords), puis renvoie le rapport. Rien n’est créé : ni sortie, ni enregistrement, ni artiste, ni code, ni livraison. SFTP : le dossier /test (un rapport est écrit à côté de chaque lot). La page DDEX du tableau de bord liste chaque test sous Test reports. Les clés de test (hm_test_…) ont été retirées le 12 octobre 2026 et sont refusées (401 test_keys_retired).

<a id="test-reports"></a>

## Rapports de test

Chaque test, qu’il vienne du SFTP, de l’API ou du tableau de bord, est listé sur la page DDEX du tableau de bord sous Test reports et conservé 90 jours : chaque vérification par étape (pass / warning / error / skipped), ce que HILLS créerait, et le verdict : `would_import`, `would_import_with_warnings`, `would_be_flagged` ou `would_be_rejected`.

Source: https://developer.hillsmusic.com/fr/reference/test-folder/