---
title: "La API del board: tasks, zones y transiciones"
description: "Cada ruta va acotada a un tenant y un repo. El intake es una línea. El resto del contrato sigue en movimiento, y esto lo dice en vez de congelarlo."
url: https://commitcycle.com/es/api/
language: es
---

# La misma superficie que usa la consola

> Cada ruta va acotada a un tenant y un repo. El intake es una línea. El resto del contrato sigue en movimiento, y esto lo dice en vez de congelarlo.

API Shipped · contrato en movimiento

No hay una segunda implementación detrás de la consola o de la CLI: las dos hablan con ésta. Lo cual también significa que se mueve cuando se mueve el producto, y esta página tiene cuidado con lo que promete.

El intake es un POST con un título y una credencial del board, así que un pequeño puente que escribas tú puede registrar trabajo desde lo que uses hoy.

## Lo que es estable

```
POST /v1/<tenant>/<repo>/tasks
{ "title": "una línea", "requested_by": "tu@ejemplo.com" }
```

- **Un board es un par.** Cada ruta va acotada por path — `/v1/<tenant>/<repo>/…` — y un board es ese par, nada más.
- **El intake es una línea.** Un título aterriza en Triage. Una petición sin acotar no es trabajo en marcha, aquí como en todas partes.
- **El estado lo cambia el gate.** La ruta de scoping descarta en silencio un campo `state`, así que nada puede arrancar trabajo escribiéndolo de lado.

## Lo que sigue moviéndose

La referencia completa de payloads está registrada y sin escribir, y ese orden es deliberado y no un descuido del backlog: las formas siguen moviéndose, y **documentar un contrato en movimiento produce documentación que miente**. Lo que existe está marcado como pendiente; lo de arriba es lo que ha aguantado.

Si vas a construir sobre esto ahora, el handshake de versión es lo primero que conviene cablear: a un cliente desactualizado se le dice en una línea, en lugar de que lo descubra más tarde como un desacuerdo de reglas.

## Dónde se detiene

- **No es el camino del enforcement.** El hook nunca llama a la red para decidir, así que una caída de la API no puede abrir una zone — nunca estuvo en el camino de la denegación.
- **No puede leer tu rama.** Un close necesita un change manifest: `cycle verify --close` lo construye en la máquina donde está la rama, y la API lo recibe. El único diff que el board lee por su cuenta es la lista de archivos de un pull request fusionado, desde GitHub, donde su App está instalada (CC-1346, CC-1352).

Las rutas tal y como están se documentan en [la referencia de la API](https://commitcycle.com/docs/reference/api/) (en inglés). Para casi todo, [la CLI](https://commitcycle.com/es/cli/) y [el servidor MCP](https://commitcycle.com/es/mcp/) son el camino más corto.

## Preguntas que responde esta página

### ¿La API de CommitCycle es lo bastante estable para construir sobre ella?

El direccionamiento y el intake sí: un board es un par tenant/repo, y POST /tasks con un título aterriza en Triage. Los payloads más ricos siguen moviéndose con las fases, así que todo lo que va más allá está documentado como pendiente en lugar de publicado y luego roto.
