# Carpeta de pruebas

> Prueba un lote DDEX antes de entregarlo: la carpeta SFTP /test y POST /ddex/validate. No se crea nada.

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

Cada buzón DDEX es un único acceso SFTP con exactamente dos carpetas: `/test` comprueba un lote y no crea nada; `/production` lo importa. La API tiene un solo tipo de clave (`hm_live_…`); su vía de pruebas es [POST /ddex/validate](https://developer.hillsmusic.com/es/reference/ddex-deliveries/#test-a-ddex-message-or-batch). Una prueba ejecuta todas las comprobaciones de una entrega (el XML, las reglas de HILLS, los archivos de audio, portada y video, los UPC e ISRC frente al catálogo, los géneros, los territorios y los acuerdos) y deja el catálogo tal como estaba: ni lanzamientos, ni grabaciones, ni artistas, ni códigos, ni entregas.

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

## Por SFTP

Un acceso por cuenta, creado con el buzón. Sube a `/production/<batch>/` para entregar o a `/test/<batch>/` para probar; un lote es una carpeta con el XML del ERN (se recomienda 4.3) y los archivos a los que remite, cerrada con su marcador (`BatchComplete_*.xml` o cualquier `*.complete`).

| Ruta | Qué ocurre |
| --- | --- |
| `/production/<batch>/` | En cuanto llega el marcador, se importa el lote: cada lanzamiento se convierte en un borrador de tu catálogo y pasa por la revisión y la entrega a las plataformas como de costumbre. Cada lote, en su propia carpeta. |
| `/test/<batch>/` | En cuanto llega el marcador, se lee el lote y se comprueba por completo. No se crea nada. El informe se escribe a su lado: `/test/<batch>.report.txt` y `/test/<batch>.report.json`. |
| `/test/<file>.xml` o `/test/<file>.zip` | Un único mensaje o zip, que se prueba de la misma forma; el informe queda en `/test/<file>.report.txt` y `.report.json`. |
| `/test/<anything else>` | Una prueba de conexión (basta con `ping.txt`): la página DDEX del panel muestra que la conexión funciona. |

Una carpeta de lote de producción que nunca recibe su marcador se elimina a los 7 días; lo que haya en `/test` (lotes, informes, archivos de prueba de conexión) se elimina en el mismo plazo.

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

## Por la API

<a id="production"></a>

## Producción

Datos reales. POST /ddex (y las subidas directas) entregan lotes DDEX que se convierten en borradores de lanzamiento en tu catálogo y pasan por la revisión y la entrega a las plataformas como de costumbre. SFTP: la carpeta /production.

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

## Pruebas

La misma clave. POST /ddex/validate acepta un .xml o un .zip, ejecuta todas las comprobaciones de una entrega (el XML, las reglas de HILLS, los archivos de audio, portada y video, los UPC e ISRC frente al catálogo, los géneros, los territorios y los acuerdos) y responde con el informe. No se crea nada: ni lanzamientos, ni grabaciones, ni artistas, ni códigos, ni entregas. SFTP: la carpeta /test (se escribe un informe junto a cada lote). La página DDEX del panel enumera todas las pruebas en Test reports. Las claves de prueba (hm_test_…) se retiraron el 12 de octubre de 2026 y se rechazan (401 test_keys_retired).

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

## Informes de prueba

Cada prueba, venga de SFTP, de la API o del panel, aparece en la página DDEX del panel, en Test reports, y se conserva 90 días: cada comprobación por fase (pass / warning / error / skipped), lo que HILLS crearía y el veredicto: `would_import`, `would_import_with_warnings`, `would_be_flagged` o `would_be_rejected`.

Fuente: https://developer.hillsmusic.com/es/reference/test-folder/