> ## 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.

# Data App veröffentlichen (veraltet)

> One-shot-Publish-Sugar für api-type-Apps: submit und publish. Abgelöst durch Contract-Import-Wizard und Drei-Schritt-Kette.

<Warning>
  **Veraltet.** Einreichungen laufen jetzt über den Contract-Import-Assistenten des Portals (gestützt auf den assemble-contract-Endpoint) oder über die dreistufige Kette (Workspace speichern → Build erstellen → Release erstellen). Dieser Endpoint bleibt für die integrierte Konsole und bestehende Tests erhalten; die Entfernung wird separat geplant.
</Warning>

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

Authentifizierung: API-Schlüssel erforderlich (`Authorization: Bearer <API Key>`).

Veröffentlichung in einem Schritt für Apps vom Typ api (deklarativ): intern eine atomare Kette aus Identität anlegen → Workspace speichern → Build erstellen → Release erstellen. Absenden heißt veröffentlichen.

**Die Version wird durch die Publish-Aktion entschieden**: standardmäßig erhöht sich das Patch-Segment der aktuellen Max-Version um eins (erste ist `0.1.0`). Die Submission braucht und trägt keine Versionsnummer (dieser Pfad ignoriert `identity.version`). Für eine explizite Version Create Release in der Drei-Schritt-Kette nutzen. code-type nutzt diesen Sugar nicht: Image-Builds sind asynchron, daher hält „submit and publish“ nicht.

Namespace wird aus auth abgeleitet: `identity.app_name` im Manifest ist nur der App-Name; die App landet unter dem eigenen des Publishers (Benutzer, App-Name). `app_id` wird einmal geprägt und überlebt Änderungen des Benutzernamens oder des App-Namens; externe Referenzen sind immer zweigeteilt. Releases sind unveränderlich: Beim erneuten Veröffentlichen wird eine neue Version angehängt und niemals eine alte überschrieben. Vor der Veröffentlichung laufen zwei Namenstore: Das Konto muss einen Benutzernamen haben (`400`); das historische Eigentum an (Benutzername, App-Name) muss Ihnen gehören — nach einer Übertragung des Benutzernamens geben die Namen des verwendeten Vorgängers ein 30-tägiges Einfrieren ein (`409`).

## Anfrage

### Anfrage-Body

<ParamField body="manifest" type="string" required>
  Roher Manifesttext.
</ParamField>

<ParamField body="files" type="object">
  Angehängte Dateien.
</ParamField>

<ParamField body="secrets" type="object">
  Map von Secret-Namen zu Klartextwerten.
</ParamField>

### Beispielanfrage

```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"
```

## Antwort

### 200 Erfolg

```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"
  }
}
```

Payload ist in `data` gewrappt. Felder:

<ResponseField name="app_name" type="string" required>
  App-Name.
</ResponseField>

<ResponseField name="namespace" type="string">
  Publisher-Benutzername.
</ResponseField>

<ResponseField name="version" type="string">
  Veröffentlichte Versionsnummer.
</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>

### Fehler

| HTTP | `code`              | `category`      | Beschreibung                                                                                                                          |
| ---- | ------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| 401  | `unauthorized`      | `forbidden`     | Fehlender oder ungültiger API-Schlüssel.                                                                                              |
| 422  | `invalid-manifest`  | `invalid_input` | Das Manifest hat die Validierung nicht bestanden; `issues[]` listet die Probleme auf.                                                 |
| 400  | `username-required` | `invalid_input` | Account has no Username yet, so a `<Username>/<app_name>` reference kann nicht formed.                                                |
| 409  | `app-name-reserved` | `forbidden`     | Der Name ist durch eine historische Bindung einer anderen Person belegt (30-tägige Sperre nach einer Übertragung des Benutzernamens). |
| 400  | `invalid-app-name`  | `invalid_input` | Name verletzt Naming-Regeln oder ist ein reserviertes Wort.                                                                           |

Fehlerantworten nutzen `{"error": {code, category, message, retryable}}`. Siehe <a href="/docs/de/datahub/api/reference/introduction#errors">Fehler</a>.

## Client-Bibliotheken

Die Python- und JavaScript-SDKs wrappen diesen Endpoint noch nicht. REST direkt aufrufen.