DEVELOPERS / CAN YOU JUST API

A worker needs work.
And a place in the plan.

Connect an external worker to its assigned CYJ tasks, progress and human handoffs.

The Can You Just API is currently an agent API under /api/v1. It gives a configured resource access to its own work within an organisation, with explicit permissions. It is not a general CRUD API for every CYJ feature.

See two real operations ↓

Execution happens in your environment.

CYJ → external workerAssigned work, prerequisites, project priority and blocking context
Your application or AI agentPerforms the work using its own tools and runtime
External worker → CYJProgress, notes, factual effort and requests for human help

CYJ remains the planning and scheduling layer. It does not run AI inference, host an autonomous coding worker or execute your scripts.

Find the next work.

Read owned tasks, available work and waiting work. Inspect project priority and deadlines, assignees, dependencies and blocking reasons. Available work follows scheduler eligibility and excludes live claims.

Report what changed.

Update supported task fields, estimated duration, status and dependencies; append notes or replace recorded actual-effort intervals. Project properties and resource assignment remain human-managed.

Coordinate workers.

Claim a runnable task with a time-limited lease, renew or release it, and use current versions to protect writes. Retry supported mutations with an idempotency key rather than duplicating a successful request.

Bring a person into the loop.

Create a human assistance request linked to an owned task. It enters Incoming without consuming capacity until accepted. Read the response and explicitly evaluate supported assistance or source changes.

What could you build?

An internal application can drive a worker assigned to CYJ stages. A script can report progress and leave an explanation on its task. An external AI agent can discover eligible work, perform it elsewhere and ask a person for a review when it becomes blocked.

The API also exposes the mapped recipient’s Incoming queue and supported acceptance, planning, reassignment and completion actions. It does not currently expose general project creation, organisation-wide reporting, team management or a full schedule export.

For work originating in a project system, use an implemented connector where appropriate. A custom connection must fit the API’s assigned-resource operations.

Connecting existing systems →Human and AI capacity →

ILLUSTRATIVE REQUESTS / FICTIONAL VALUES

Small operations. Real contracts.

These are two supported operations, not a complete integration tutorial. The token below is an intentionally invalid placeholder. Task 42 and version 7 are fictional; use a task owned by the configured resource and its current ETag.

1. Read waiting work.

With tasks:read, retrieve owned work that is blocked. This example response is an empty queue; non-empty results contain task details and blocking reasons.

GET /api/v1/tasks/waiting HTTP/1.1
Authorization: Bearer EXAMPLE_TOKEN_NOT_VALID
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

[]

2. Append a progress note.

With tasks:notes, append a note to an owned task. Read that task first to obtain the current ETag. If a claim is active, also supply its X-Task-Claim token. A stale version requires a fresh read; the same idempotency key is reused only for an identical retry.

POST /api/v1/tasks/42/notes HTTP/1.1
Authorization: Bearer EXAMPLE_TOKEN_NOT_VALID
If-Match: "task-42-plan-7"
Idempotency-Key: example-note-001
Content-Type: application/json

{"text":"Build checked. Waiting for review."}

HTTP/1.1 204 No Content

Access is deliberately bounded.

An organisation administrator configures an API client, its mapped resource and permitted scopes, then issues a Bearer credential. Treat that credential as a secret and send it over HTTPS. Administrators can rotate or revoke credentials.

Task operations require ownership by the mapped resource as well as the relevant scope. A client without a mapped resource has identity-only access. Credentials also depend on an active sponsoring membership; they do not grant access to another organisation’s work.

Writes use preconditions and business-rule validation. Worker claims and idempotency support coordination, but do not guarantee that a side effect in your external system happens exactly once.

AI work still has dependencies.

An AI worker can have an estimate and continuous availability while its human reviewer keeps ordinary working hours. Atlas, a fictional worker, might finish a build overnight and wait for Alice’s review. More agent capacity does not make Alice available at 02:00.

The worker executes outside CYJ. It can report progress, request human help and evaluate a response through the API; CYJ models the work and its scheduling consequences.

See the calculated human–AI handoff →

API DOCUMENTATION

The capability overview starts here.

API v1 developer documentation covers authentication, assigned work, leases, retries and human handoffs. Start with a first request or look up the exact operation contract.

Make your first request ↗Developer documentation →Explore source-linked work →

A worker needs work.And a place in the plan.