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

# Build erstellen

> Aktuellen Draft zu immutable Snapshot frieren — für Debug-Runs und Publishing.

**`POST`** `https://api-datahub.octoparse.com/v1/data-apps/{app_id}/builds`

Authentifizierung: API-Schlüssel erforderlich (`Authorization: Bearer <API Key>`). Nur App-Autor; andere erhalten `404`.

Friert den aktuellen Workspace in einen unveränderlichen Snapshot ein – das Objekt, auf das Debug-Runs und das Publishing verweisen.

Vorbedingungen: Ein Arbeitsbereich muss vorhanden sein und sein aktueller Inhalt muss gültig sein (ansonsten `422` mit `issues`); der Textkörper kann ⟦2 enthalten⟧ (⟦3,⟧ wenn der Entwurf zwischen Speichern und Einfrieren geändert wurde). Wenn⟧ bereits ein fertiger Snapshot mit der gleichen ⟦4 vorhanden ist, wird er wiederverwendet und es wird keine doppelte Zeile erstellt. aPI-Typ-Builds werden sofort fertig; Code-Typ gibt ⟦5 zurück⟧ und reiht einen Image-Build in die Warteschlange ein — wird erneut gesendet, während einer bereits für die gleiche App ausgeführt wird, gibt ⟦6 zurück⟧. Veraltete Apps können immer noch erstellt werden; nur neue Releases werden abgelehnt.

## Anfrage

### Pfadparameter

<ParamField path="app_id" type="string" required>
  App-Referenz.
</ParamField>

### Anfrage-Body

<ParamField body="expected_revision" type="integer">
  Expected current draft revision. Mismatch gibt zurück `409`.
</ParamField>

### Beispielanfrage

```bash theme={null}
curl -X POST \
  -H "Authorization: Bearer $OCTOPARSE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"expected_revision": 3}' \
  "https://api-datahub.octoparse.com/v1/data-apps/carol/reviews-query/builds"
```

## Antwort

### 200 Erfolg

```json theme={null}
{
  "data": {
    "build_id": "string",
    "build_status": "string",
    "content_hash": "string",
    "source_revision": 0,
    "reused": false,
    "created_at": "string"
  }
}
```

Payload ist in `data` gewrappt. Felder:

<ResponseField name="build_id" type="string" required>
  Build-ID.
</ResponseField>

<ResponseField name="build_status" type="string" required>
  `ready`, `building` (code-type) oder `failed`.
</ResponseField>

<ResponseField name="content_hash" type="string" required>
  Content-Hash.
</ResponseField>

<ResponseField name="source_revision" type="integer" required>
  Draft-Revision zum Zeitpunkt des Einfrierens.
</ResponseField>

<ResponseField name="reused" type="boolean">
  Ob an existing same-content snapshot was reused.
</ResponseField>

<ResponseField name="created_at" type="string">
  Erstellungszeit.
</ResponseField>

### Fehler

| HTTP | `code`                | `category`      | Beschreibung                                                                                           |
| ---- | --------------------- | --------------- | ------------------------------------------------------------------------------------------------------ |
| 401  | `unauthorized`        | `forbidden`     | Fehlender oder ungültiger API-Schlüssel.                                                               |
| 404  | `workspace-not-found` | `not_found`     | Diese App hat keinen laufenden Draft. Das ist ein normaler Main-Path-Zustand, kein Fehler.             |
| 422  | `build-failed`        | `invalid_input` | Der Workspace-Inhalt hat die Validierung nicht bestanden; `issues[]` listet die Probleme auf.          |
| 409  | `revision-conflict`   | `invalid_input` | `expected_revision` stimmt nicht mit der aktuellen Draft-Revision überein – gleichzeitige Bearbeitung. |

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.