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

# Crear release

> Promueve un build listo a una versión formal. El número de versión se fija en este momento.

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

Autenticación: se requiere API key (`Authorization: Bearer <API Key>`). Solo el autor de la app; el resto recibe `404`.

Promueve un build listo especificado a una versión formal. **El número de versión se fija aquí**: por defecto se incrementa el segmento patch de la última versión; o pase una versión de tres segmentos explícita.

Precondiciones: el build existe y está listo; el snapshot se vuelve a pasar por la validación de publicación en el momento del release; la app no está deprecada (si lo está, las releases nuevas se rechazan). El número de versión debe ser mayor que cualquier release existente.

## Solicitud

### Parámetros de ruta

<ParamField path="app_id" type="string" required>
  Referencia de app.
</ParamField>

### Cuerpo de la solicitud

<ParamField body="build_id" type="string" required>
  Id del build a publicar. Debe estar listo.
</ParamField>

<ParamField body="version" type="string">
  Versión explícita de tres segmentos. Omítala para incrementar el segmento patch.
</ParamField>

<ParamField body="expected_revision" type="integer">
  Revisión actual esperada del borrador. Si no coincide, `409`.
</ParamField>

### Ejemplo de solicitud

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

## Respuesta

### 200 correcto

```json theme={null}
{
  "data": {
    "version": "1.2.0",
    "build_id": "bld_a583f440a0ab",
    "published_at": "2026-09-15T08:00:00+00:00",
    "latest": true
  }
}
```

La carga útil va envuelta en `data`. Campos:

<ResponseField name="app_name" type="string" required>
  —
</ResponseField>

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

<ResponseField name="version" type="string" required>
  Número de versión publicada.
</ResponseField>

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

<ResponseField name="published_at" type="string">
  Hora de publicación.
</ResponseField>

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

### Errores

| HTTP | `code`              | `category`      | Descripción                                                                                |
| ---- | ------------------- | --------------- | ------------------------------------------------------------------------------------------ |
| 401  | `unauthorized`      | `forbidden`     | API key ausente o no válida.                                                               |
| 404  | `build-not-found`   | `not_found`     | El snapshot de build no existe.                                                            |
| 409  | `build-not-ready`   | `invalid_input` | El build aún no está listo (building o failed) y no se puede publicar.                     |
| 422  | `invalid-manifest`  | `invalid_input` | El manifest falló la validación; `issues[]` lista los problemas.                           |
| 409  | `revision-conflict` | `invalid_input` | `expected_revision` no coincide con la revisión actual del borrador — edición concurrente. |

Las respuestas de error usan `{"error": {code, category, message, retryable}}`. Véase <a href="/docs/es/datahub/api/reference/introduction#errors">Errores</a>.

## Bibliotecas cliente

Los SDK de Python y JavaScript aún no encapsulan este endpoint. Llame a REST directamente.