# Pasta de teste

> Teste um lote DDEX antes de entregá-lo: a pasta SFTP /test e POST /ddex/validate. Nada é criado.

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

Cada caixa de entrada DDEX é um login SFTP com exatamente duas pastas: `/test` verifica um lote sem criar nada, `/production` o importa. A API tem um único tipo de chave (`hm_live_…`); o caminho de teste dela é [POST /ddex/validate](https://developer.hillsmusic.com/pt/reference/ddex-deliveries/#test-a-ddex-message-or-batch). Um teste executa todas as verificações de uma entrega (o XML, as regras da HILLS, os arquivos de áudio, capa e vídeo, os UPCs e ISRCs em relação ao catálogo, gêneros, territórios e deals) e deixa o catálogo como estava: nenhum lançamento, gravação, artista, código ou entrega.

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

## Via SFTP

Um login por conta, criado junto com a caixa de entrada. Faça upload em `/production/<batch>/` para entregar, ou em `/test/<batch>/` para testar; um lote é uma pasta com o XML ERN (4.3 recomendado) e os arquivos a que ele se refere, fechada pelo seu marcador (`BatchComplete_*.xml` ou qualquer `*.complete`).

| Caminho | O que acontece |
| --- | --- |
| `/production/<batch>/` | Quando o marcador chega, o lote é importado: cada lançamento vira um rascunho no seu catálogo e passa pela revisão e pela entrega às plataformas como de costume. Cada lote em sua própria pasta. |
| `/test/<batch>/` | Quando o marcador chega, o lote é lido e verificado por completo. Nada é criado. O relatório é gravado ao lado: `/test/<batch>.report.txt` e `/test/<batch>.report.json`. |
| `/test/<file>.xml` ou `/test/<file>.zip` | Uma mensagem ou um zip avulso, testado da mesma forma; o relatório vai para `/test/<file>.report.txt` e `.report.json`. |
| `/test/<anything else>` | Um teste de conexão (basta um `ping.txt`): a página DDEX do painel mostra a conexão funcionando. |

Uma pasta de lote de produção que nunca recebe o marcador é removida após 7 dias; tudo o que estiver em `/test` (lotes, relatórios, arquivos de teste de conexão) sai após o mesmo prazo.

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

## Via API

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

## Produção

Dados reais. POST /ddex (e os uploads diretos) entregam lotes DDEX que viram lançamentos em rascunho no seu catálogo e passam pela revisão e pela entrega às plataformas como de costume. SFTP: a pasta /production.

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

## Teste

A mesma chave. POST /ddex/validate recebe um .xml ou um .zip e executa todas as verificações de uma entrega (o XML, as regras da HILLS, os arquivos de áudio, capa e vídeo, os UPCs e ISRCs em relação ao catálogo, gêneros, territórios e contratos (deals)) e responde com o relatório. Nada é criado: nenhum lançamento, gravação, artista, código ou entrega. SFTP: a pasta /test (um relatório é gravado ao lado de cada lote). A página DDEX do painel lista todos os testes em Test reports. As chaves de teste (hm_test_…) foram desativadas em 12 de outubro de 2026 e são recusadas (401 test_keys_retired).

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

## Relatórios de teste

Todo teste, feito por SFTP, pela API ou pelo painel, aparece na página DDEX do painel em Test reports e fica guardado por 90 dias: cada verificação por etapa (aprovada / aviso / erro / ignorada), o que a HILLS criaria e o veredito: `would_import`, `would_import_with_warnings`, `would_be_flagged` ou `would_be_rejected`.

Fonte: https://developer.hillsmusic.com/pt/reference/test-folder/