API Shipped · contract still moving

The same surface the console uses

There is no second implementation behind the console or the CLI — they both talk to this. Which also means it moves when the product moves, and this page is careful about what it promises.

~/bridgecurl

$ curl -s https://dash.commitcycle.com/v1/acme/web/tasks -H "authorization: Bearer $CC_TOKEN" -H "content-type: application/json" -d '{"title":"Export times out on large boards","requested_by":"support@acme.dev"}'

HTTP 201

{ "task": { "id": "CC-58", "state": "Triage",

"title": "Export times out on large boards", … } }

# one line, in Triage — scoping it is the next step, not this one

Intake is one POST with a title and a board credential, so a small bridge you write can file work from whatever you use today.

What is stable

POST /v1/<tenant>/<repo>/tasks
{ "title": "one line", "requested_by": "you@example.com" }

What is still moving

The full payload reference is filed and unwritten, and that is a deliberate order rather than a backlog accident: the shapes are still moving, and documenting a moving contract produces documentation that lies. What exists is marked pending; what is written above is what has held.

If you are building against this now, the version handshake is the part to wire first — a stale client is told so in one line instead of discovering it as a rule disagreement later.

Where it stops

The routes as they stand are in the API reference. For most work the CLI and the MCP server are the shorter path.

Questions this page answers

Is the CommitCycle API stable enough to build against?

The addressing and intake are: a board is a tenant/repo pair, and POST /tasks with a title lands in Triage. The richer payloads are still moving with the phases, so anything beyond those is documented as pending rather than published and then broken.