> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Pubblica Data App (deprecato)

> Sugar di publish one-shot per app api-type: submit e publish. Sostituito dal wizard import contratto e dalla catena a tre step.

<Warning>
  **Deprecato.** Gli invii ora passano dalla procedura guidata di importazione del contratto del portale (basata sull'endpoint assemble-contract) o dalla catena in tre passaggi (salvataggio del workspace → creazione della build → creazione della release). Questo endpoint resta disponibile per la console integrata e i test esistenti; la rimozione verrà pianificata separatamente.
</Warning>

**`POST`** `https://api-datahub.octoparse.com/v1/data-apps`

Autenticazione: API key obbligatoria (`Authorization: Bearer <API Key>`).

Scorciatoia di pubblicazione in un solo passaggio per le app di tipo api (dichiarative): internamente è una catena atomica di creazione dell'identità → salvataggio del workspace → creazione della build → creazione della release. Inviare significa pubblicare.

**La versione è decisa dall’azione di publish**: di default il segmento patch della max version corrente incrementa di uno (la prima è `0.1.0`). La submission non necessita né porta un numero di versione (questo path ignora `identity.version`). Per una versione esplicita usa create release nella catena a tre step. code-type non usa questo sugar: gli image build sono asincroni, quindi “submit and publish” non tiene.

Lo spazio dei nomi viene dedotto da auth: `identity.app_name` nel manifesto è solo il nome dell'app; l'app atterra sotto il nome dell'editore (utente, nome dell'app). `app_id` viene coniato una volta e sopravvive alle modifiche del nome utente o del nome dell'app; i riferimenti esterni sono sempre a due segmenti. Le versioni sono immutabili: la pubblicazione aggiunge di nuovo una nuova versione e non ne sovrascrive mai una vecchia. Due name gate vengono eseguiti prima della pubblicazione: l'account deve avere un nome utente (`400`); la proprietà storica di (nome utente, nome dell'app) deve essere tua — dopo un trasferimento del nome utente, i nomi utilizzati dal predecessore entrano in un blocco di 30 giorni (`409`).

## Richiesta

### Body della richiesta

<ParamField body="manifest" type="string" required>
  Testo grezzo del manifest.
</ParamField>

<ParamField body="files" type="object">
  File allegati.
</ParamField>

<ParamField body="secrets" type="object">
  Mappa da nomi secret a valori in chiaro.
</ParamField>

### Esempio di richiesta

```bash theme={null}
curl -X POST \
  -H "Authorization: Bearer $OCTOPARSE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"manifest": "spec_version: \"0.2\"\n…", "secrets": {"EXAMPLE_API_KEY": "sk-example"}}' \
  "https://api-datahub.octoparse.com/v1/data-apps"
```

## Risposta

### 200 successo

```json theme={null}
{
  "data": {
    "app_id": "app_6dfe4e839ccf",
    "namespace": "carol",
    "app_name": "reviews-query",
    "version": "0.1.0",
    "build_id": "bld_a583f440a0ab",
    "published_at": "2026-09-15T08:00:00+00:00"
  }
}
```

Il payload è wrappato in `data`. Campi:

<ResponseField name="app_name" type="string" required>
  Nome dell'app.
</ResponseField>

<ResponseField name="namespace" type="string">
  Username del publisher.
</ResponseField>

<ResponseField name="version" type="string">
  Numero di versione pubblicata.
</ResponseField>

<ResponseField name="status" type="string">
  —
</ResponseField>

<ResponseField name="card" type="object" required>
  —
</ResponseField>

<ResponseField name="missing_secrets" type="string[]">
  —
</ResponseField>

<ResponseField name="name_reused_from" type="string">
  —
</ResponseField>

### Errori

| HTTP | `code`              | `category`      | Descrizione                                                                                                               |
| ---- | ------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------- |
| 401  | `unauthorized`      | `forbidden`     | API key mancante o non valida.                                                                                            |
| 422  | `invalid-manifest`  | `invalid_input` | Il manifest non ha superato la validazione; `issues[]` elenca i problemi.                                                 |
| 400  | `username-required` | `invalid_input` | Account has no username yet, so a `<username>/<app_name>` reference non può essere formed.                                |
| 409  | `app-name-reserved` | `forbidden`     | Il nome è occupato da un binding storico di un'altra persona (blocco di 30 giorni dopo un trasferimento del nome utente). |
| 400  | `invalid-app-name`  | `invalid_input` | Il nome viola le regole di naming o è una parola riservata.                                                               |

Le risposte di errore usano `{"error": {code, category, message, retryable}}`. Vedi <a href="/docs/it/datahub/api/reference/introduction#errors">Errori</a>.

## Librerie client

Gli SDK Python e JavaScript non wrappano ancora questo endpoint. Chiama REST direttamente.