# Test folder

> Test a DDEX batch before it is delivered: the SFTP /test folder and POST /ddex/validate. Nothing is created.

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

Every DDEX inbox is one SFTP login with exactly two folders: `/test` checks a batch and creates nothing, `/production` imports it. The API has one kind of key (`hm_live_…`); its test path is [POST /ddex/validate](https://developer.hillsmusic.com/reference/ddex-deliveries/#test-a-ddex-message-or-batch). A test runs every check a delivery gets (XML, the HILLS rules, the audio, artwork and video files, UPCs and ISRCs against the catalog, genres, territories and deals) and leaves the catalog as it was: no release, recording, artist, code or delivery.

## Over SFTP

One login per account, made with the inbox. Upload into `/production/<batch>/` to deliver, or into `/test/<batch>/` to test; a batch is a folder with the ERN XML (4.3 recommended) and the files it points at, finished by its marker (`BatchComplete_*.xml` or any `*.complete`).

| Path | What happens |
| --- | --- |
| `/production/<batch>/` | Once the marker arrives the batch is imported: each release becomes a draft on your catalog and goes through review and delivery to the stores as usual. Each batch in its own folder. |
| `/test/<batch>/` | Once the marker arrives the batch is read and fully checked. Nothing is created. The report is written next to it: `/test/<batch>.report.txt` and `/test/<batch>.report.json`. |
| `/test/<file>.xml` or `/test/<file>.zip` | A single message or zip, tested the same way; the report lands at `/test/<file>.report.txt` and `.report.json`. |
| `/test/<anything else>` | A connection test (`ping.txt` is enough): the DDEX page in the dashboard shows the connection as working. |

A production batch folder that never gets its marker is removed after 7 days; whatever sits in `/test` (batches, reports, connection test files) goes after the same time.

## Over the API

## Production

Real data. POST /ddex (and direct uploads) deliver DDEX batches that become draft releases on your catalog and go through review and delivery to the stores as usual. SFTP: the /production folder.

## Test

The same key. POST /ddex/validate takes an .xml or a .zip and runs every check a delivery gets (XML, the HILLS rules, the audio, artwork and video files, UPCs and ISRCs against the catalog, genres, territories and deals), then answers the report. Nothing is created: no release, recording, artist, code or delivery. SFTP: the /test folder (a report is written next to each batch). The DDEX page in the dashboard lists every test under Test reports. Test keys (hm_test_…) were retired on 2026-10-12 and are refused (401 test_keys_retired).

## Test reports

Every test, from SFTP, the API or the dashboard, is listed on the DDEX page in the dashboard under Test reports and kept 90 days: every check by stage (pass / warning / error / skipped), what HILLS would create, and the verdict: `would_import`, `would_import_with_warnings`, `would_be_flagged` or `would_be_rejected`.

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