Issues - Crewship

Issues are crew-scoped tracker items: each carries a human-readable identifier (e.g. ENG-42), a status flow, and lifecycle operations for agent execution. Beyond CRUD, the API covers comments, relations, an activity log, workspace labels, and projects that group issues with tracking metadata. Under the hood, issues are stored in the missions table with mission_type = 'issue' — they share infrastructure with missions but keep their own status flow, identifiers, and lifecycle.

All issue endpoints require authentication and workspace context.

Endpoints

Method	Endpoint	Purpose
`GET`	`/api/v1/issues`	List issues across a workspace
`GET`	`/api/v1/issues/{identifier}`	Get an issue by identifier (workspace-wide)
`POST`	`/api/v1/crews/{crewId}/issues`	Create an issue
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}`	Get an issue within a crew
`PATCH`	`/api/v1/crews/{crewId}/issues/{identifier}`	Update an issue
`DELETE`	`/api/v1/crews/{crewId}/issues/{identifier}`	Delete an issue
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/work`	Transfer work between people and agents
`PUT`	`/api/v1/crews/{crewId}/issues/{identifier}/review-policy`	Require or drop human acceptance of the work
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/start`	Start issue execution
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/stop`	Stop a running issue
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/review`	Submit a review decision
`PATCH`	`/api/v1/issues/bulk`	Bulk-update up to 100 issues
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/subtasks`	List an issue’s sub-issues
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/activity`	List an issue’s activity log
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/events`	The same log, seq-cursored, for resync after a dropped realtime frame
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/runs/{runId}/result`	Read the full stored result
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/runs`	List an issue’s agent task-runs
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/sessions`	List an issue’s agent sessions
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/sessions/{sessionId}/checkpoints`	List a session’s checkpoints
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/comments`	List comments on an issue
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/comments`	Add a comment
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/relations`	List relations
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/relations`	Create a relation
`DELETE`	`/api/v1/relations/{relationId}`	Delete a relation
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/code-links`	List linked pull requests
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/code-links`	Attach a pull request / merge request
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/code-links/{linkId}/refresh`	Re-fetch a link’s state
`DELETE`	`/api/v1/crews/{crewId}/issues/{identifier}/code-links/{linkId}`	Remove a link
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/attachments`	List attached files
`POST`	`/api/v1/crews/{crewId}/issues/{identifier}/attachments`	Attach a file
`GET`	`/api/v1/crews/{crewId}/issues/{identifier}/attachments/{attachmentId}`	Download an attached file
`DELETE`	`/api/v1/crews/{crewId}/issues/{identifier}/attachments/{attachmentId}`	Remove an attached file
`GET`	`/api/v1/labels`	List workspace labels
`POST`	`/api/v1/labels`	Create a label
`PATCH`	`/api/v1/labels/{labelId}`	Update a label
`DELETE`	`/api/v1/labels/{labelId}`	Delete a label
`GET`	`/api/v1/projects`	List projects
`POST`	`/api/v1/projects`	Create a project
`GET`	`/api/v1/projects/{projectId}`	Get a project
`PATCH`	`/api/v1/projects/{projectId}`	Update a project
`DELETE`	`/api/v1/projects/{projectId}`	Delete a project
`GET`	`/api/v1/projects/{projectId}/stats`	Project breakdown stats
`GET`	`/api/v1/projects/{projectId}/milestones`	List project milestones
`POST`	`/api/v1/projects/{projectId}/milestones`	Create a project milestone
`PATCH`	`/api/v1/milestones/{milestoneId}`	Update a project milestone
`DELETE`	`/api/v1/milestones/{milestoneId}`	Delete a project milestone

Issues CRUD

Create, read, update, and delete issues. Most write operations require OWNER, ADMIN, or MANAGER role and emit a WebSocket event on workspace:{workspaceId}.

List Issues (Workspace)

GET /api/v1/issues?workspace_id={workspaceId}

Returns issues across the workspace with filtering, sorting, and pagination. Query Parameters:

Parameter	Type	Default	Description
`workspace_id`	string	Required	Workspace ID
`mission_type`	string	`"issue"`	Filter by type (`"issue"` or `"mission"`)
`status`	string	—	Comma-separated status filter (e.g., `TODO,IN_PROGRESS`)
`priority`	string	—	Comma-separated priority filter (e.g., `urgent,high`)
`project_id`	string	—	Filter by project
`crew_id`	string	—	Filter by crew
`assignee_id`	string	—	Filter by assignee
`label`	string	—	Filter by label name
`q`	string	—	Search in title or identifier (LIKE match), on the server
`search`	string	—	Older alias of `q`
`sort`	string	`"created_at"`	Sort column: `created_at`, `updated_at`, `priority`, `sort_order`
`limit`	integer	`50`	Rows per page (1-500)
`offset`	integer	`0`	Pagination offset
`counts`	string	—	`1` to also compute per-status totals under the same filters as the page (every filter applied, `limit`/`offset` ignored). Answered in the `X-Status-Counts` header; the body is unchanged. Any other value is ignored.

The body stays a bare array. The total the filter matched — before limit/offset — is in the X-Total-Count response header, with X-Limit and X-Offset echoing the values applied. An agent assignee carries assignee_slug next to assignee_name. Response: 200 OK

[
  {
    "id": "issue_abc",
    "workspace_id": "ws_123",
    "crew_id": "crew_456",
    "crew_name": "Engineering",
    "crew_slug": "engineering",
    "number": 42,
    "identifier": "ENG-42",
    "title": "Fix authentication token refresh",
    "description": "Tokens are not being refreshed before expiry",
    "status": "TODO",
    "priority": "high",
    "assignee_type": "agent",
    "assignee_id": "agent_789",
    "assignee_name": "Backend Dev",
    "owner": null,
    "delegate": {
      "id": "agent_789",
      "name": "Backend Dev"
    },
    "created_by": {
      "type": "agent",
      "id": "agent_789",
      "name": "Backend Dev"
    },
    "authored_via": "agent_tool_call",
    "due_date": "2024-02-01",
    "sort_order": 0.0,
    "mission_type": "issue",
    "lead_agent_id": "agent_lead",
    "created_at": "2024-01-15T10:00:00Z",
    "updated_at": "2024-01-15T10:00:00Z",
    "completed_at": null,
    "labels": [
      {
        "id": "label_abc",
        "name": "bug",
        "color": "#ef4444",
        "label_group": null
      }
    ],
    "project_id": "proj_123",
    "comment_count": 3
  }
]

Pagination (#2286): the body is still the bare array above — unchanged for every existing client — but the response now also carries two headers:

Header	Description
`X-Total-Count`	Total rows matching the query (every filter applied, `limit`/`offset` ignored)
`X-Has-More`	`"true"` when `offset + len(body)` is less than `X-Total-Count`, else `"false"`
`X-Status-Counts`	Only with `?counts=1`: a JSON object of status → row count over the same scope as `X-Total-Count`, e.g. `{"BACKLOG":12,"TODO":4,"DONE":31}`. Statuses with no rows are absent. `crewship issue list --counts` prints it.

A caller that only reads the array still gets identical bytes; a caller that wants to know whether a 100-row page was the whole story reads the headers instead of guessing. crewship issue list prints a “Showing N of TOTAL issues” footer from them and takes --offset to page further; the issues board (hooks/use-issues-list.ts) uses them to drive its own “Load more”.

Error degradation contract (#2285): the issues board classifies a failed request to this endpoint instead of rendering it as an empty workspace. A 403 is shown separately from a 5xx/network failure — it’s reported as “the request was refused”, naming a scoped agent/CLI token as the likely cause (AuthKindCLIToken in internal/api/middleware.go is the credential “an agent, CI job, or script holds”; a 403 here is what an agent/CLI token whose scope doesn’t cover issues, or a transient token problem, looks like) alongside a retry action, rather than presenting a board with zero issues. See hooks/use-issues-list.ts for the implementation and the full reasoning.

Response fields

Field	Type	Description
`id`	string	Issue ID (same as underlying mission ID)
`workspace_id`	string	Workspace ID
`crew_id`	string	Crew ID
`crew_name`	string	Crew display name
`crew_slug`	string	Crew slug
`number`	integer	Sequential issue number within the crew
`identifier`	string	Human-readable identifier (e.g., `ENG-42`)
`title`	string	Issue title
`description`	string?	Issue description
`status`	string	Current status
`priority`	string	Priority level
`assignee_type`	string?	`"user"` or `"agent"` — legacy compatibility projection, kept for existing clients during the migration to `owner`/`delegate` below. Still written on every assignment path
`assignee_id`	string?	Assignee ID — same compatibility projection as `assignee_type`
`assignee_name`	string?	Resolved assignee name
`owner`	object?	The issue’s human owner: `{id, name}`. Independent of `delegate` — delegating an issue to an agent never changes this field (invariant: human owner, agent delegate). Omitted when nobody owns the issue
`delegate`	object?	The agent an issue’s work has been delegated to: `{id, name}`. Independent of `owner`. Omitted when no agent has been delegated
`created_by`	object?	Who created the issue: `{type, id, name}` where `type` is `"user"` (created via the API/UI) or `"agent"` (created by an agent tool call). `name` is resolved at read time like `assignee_name`. Omitted on issues that predate creator attribution
`authored_via`	string?	Creation channel: `"user_api"` (human via API/UI/slash command) or `"agent_tool_call"` (agent via sidecar). Omitted on legacy issues
`due_date`	string?	Due date
`sort_order`	number	Manual sort order for board views
`mission_type`	string	Always `"issue"` for issues
`lead_agent_id`	string	Crew’s lead agent ID
`labels`	array	Array of label objects
`project_id`	string?	Parent project ID
`estimate`	integer?	Effort/points estimate
`parent_issue_id`	string?	Parent issue ID for sub-issues
`milestone_id`	string?	Associated milestone ID
`sub_issues_count`	integer	Count of child issues with `parent_issue_id` = this issue
`routine_id`	string?	Bound pipeline ID for `/run-routine` (omitted if unbound)
`routine_slug`	string?	Slug of the bound pipeline (denormalized for UI)
`routine_name`	string?	Name of the bound pipeline (denormalized for UI)
`comment_count`	integer	Number of comments
`created_at`	string	ISO 8601 timestamp
`updated_at`	string	ISO 8601 timestamp
`completed_at`	string?	When issue was completed/cancelled/marked duplicate
`work_mode`	string	Who is working the issue right now: `agent` (automatic runs may start) or `human` (a person holds it; Start answers `409` until it is handed back). See Transfer Issue Work
`work_revision`	integer	Compare-and-set counter for the work contract. Every accepted `work`, `review-policy` and human take-over bumps it; pass it back as `revision`
`worker_user_id`	string?	The person holding the issue while `work_mode` is `human`. Omitted otherwise
`worker_name`	string?	Resolved name of `worker_user_id`. Omitted otherwise
`work_note`	string	The note carried by the last hand-off, take-over or submission (`""` when none)
`work_stopping`	boolean	`true` while the issue is held by a human but a run or routine started before the take-over has received cancellation and not yet finished. Hand-back and submit wait for it to clear
`client_review_required`	boolean	Get only (List rows carry `false`). Whether a person must approve before the issue counts as done (default `true`). Set with Set Issue Review Policy
`brief_revision`	integer?	Get only. Counter bumped every time the brief (title/description) changes; Review compares it against the revision the work was produced for. Omitted while `0`
`execution`	object?	Get only. The latest execution of the work contract (the thing a Lead reviews), `{id, stage, attempt, reviewer, note, routine_run_id?, workers[]}`. Omitted until the issue has been started under the contract. `workers[]` items are `{assignment_id, name, status, outcome, run_id?, review}` — `review: true` marks the Lead’s review run; `status` reads `PREPARING` for a run claimed but not yet exec’d

execution.stage is the execution’s place in the work→Lead-review→correction loop:

Stage	Meaning
`working`	Workers are running (or a bound routine is)
`reviewing`	The Lead’s review run is live
`accepted`	The Lead verified the work; the issue moves to `REVIEW` (or straight to `DONE` when `client_review_required` is `false`)
`changes_requested`	Either the Lead sent the work back to a worker (a new `working` execution with `attempt` + 1 starts at once; after the second attempt the Lead must escalate instead) or a person answered Review with `request_changes` on an `accepted`/`needs_human` execution (the issue returns to `TODO`; the next Start opens a new execution)
`needs_human`	The Lead asked for a human decision, approved despite a failed worker, or ran out of attempts; the issue is in `REVIEW` with an inbox notification
`failed`	A worker, the Lead review or the routine failed to produce a usable result; the issue is `FAILED`
`superseded`	Made moot by a take-over, hand-off, brief change or stop while it was `working`/`reviewing`

Only one execution per issue can be working or reviewing at a time. The narrative is in the guide: Work, hand-offs and Lead review.

Get Issue (Workspace-scoped)

GET /api/v1/issues/{identifier}?workspace_id={workspaceId}

Get an issue by its identifier (e.g., ENG-42) across the entire workspace. No crew ID needed. Request: identifier is required; workspace_id selects the workspace. No request body. Response: 200 OK — full issue object with labels and comment count.

Status	Condition
`404`	Issue not found

Create Issue

POST /api/v1/crews/{crewId}/issues?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role The crew must have a LEAD agent. The issue identifier is auto-generated from the crew’s issue_prefix (or first 3 characters of the slug) and an auto-incrementing counter. Request Body:

Field	Type	Required	Default	Description
`title`	string	Yes	—	Issue title
`description`	string	No	`null`	Issue description
`priority`	string	No	`"none"`	Priority: `none`, `low`, `medium`, `high`, `urgent`
`status`	string	No	`"BACKLOG"`	Starting status. Validated like a transition from `BACKLOG`, so only `BACKLOG`, `TODO`, `IN_PROGRESS`, `CANCELLED` or `DUPLICATE` are accepted; a terminal start stamps `completed_at`
`assignee_type`	string	No	`null`	`"user"` or `"agent"`. Decides which typed slot `assignee_id` fills: `user` writes the human owner (`owner_user_id`), `agent` writes the agent delegate (`delegate_agent_id`). Required when `assignee_id` is set
`assignee_id`	string	No	`null`	A workspace member’s user ID (`user`) or an agent ID (`agent`) in this workspace; anything else is `400`
`due_date`	string	No	`null`	Due date (YYYY-MM-DD)
`project_id`	string	No	`null`	Parent project ID
`estimate`	integer	No	`null`	Effort/points estimate
`parent_issue_id`	string	No	`null`	Parent issue ID for sub-issues (validated against current workspace)
`milestone_id`	string	No	`null`	Associated milestone ID
`labels`	string[]	No	`[]`	Array of label IDs to attach
`routine_id`	string	No	`null`	Pipeline ID to bind for `/run-routine` (must exist in workspace)
`routine_inputs`	object	No	`{}`	JSON object of routine input values; rejected with 400 if set without `routine_id`

{
  "title": "Fix authentication token refresh",
  "description": "Tokens are not being refreshed before expiry",
  "priority": "high",
  "assignee_type": "agent",
  "assignee_id": "agent_789",
  "labels": ["label_bug"]
}

Response: 201 Created — issue object with generated number and identifier.

Status	Condition
`400`	Missing title, crew has no lead agent, `status` not a legal starting status, `routine_inputs` set without `routine_id`, `routine_id`/`parent_issue_id` not in workspace, or `routine_inputs` not valid JSON
`403`	Insufficient role
`404`	Crew not found

WebSocket event: issue.created on workspace:{workspaceId}

Get Issue (Crew-scoped)

GET /api/v1/crews/{crewId}/issues/{identifier}?workspace_id={workspaceId}

Get an issue by its identifier within a specific crew. Includes labels and comment count. Request: crewId and identifier are required path parameters; workspace_id selects the workspace. No request body. Response: 200 OK — full issue object.

Update Issue

PATCH /api/v1/crews/{crewId}/issues/{identifier}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body: All fields optional.

Field	Type	Description
`title`	string	Issue title
`description`	string	Issue description
`status`	string	New status (must be valid transition)
`priority`	string	Priority level
`assignee_type`	string	`"user"` or `"agent"` — routes `assignee_id` to the owner or the delegate slot (see below). May be omitted when `assignee_id` is set: the server then resolves it by looking the ID up as a member first, then as an agent
`assignee_id`	string	New owner (`user`) or delegate (`agent`). `""` clears both `owner_user_id` and `delegate_agent_id` (the legacy pair goes `null` too)
`due_date`	string	Due date
`project_id`	string	Project ID (empty string to unlink)
`estimate`	integer \| null	Effort/points estimate; `null` clears it, a non-number is a `400`
`parent_issue_id`	string	Parent issue ID; empty string unlinks; cannot equal the issue itself
`milestone_id`	string	Milestone ID; empty string unlinks
`sort_order`	number	Manual sort order
`labels`	string[]	Replace all labels with this set of label IDs
`routine_id`	string	Pipeline ID to bind; empty string clears binding (also resets `routine_inputs`)
`routine_inputs`	object	Full-replacement JSON object for routine inputs

Owner and delegate are independent (#2297, invariant “human owner, agent delegate”): a user write never touches delegate_agent_id and an agent write never touches owner_user_id. The only way to empty a slot is the explicit unassign, which empties both. The legacy assignee_type/assignee_id pair is always written alongside as a compatibility projection of the last write. The CLI: crewship issue update <id> --assignee <email|agent> --assignee-type user|agent. Status Transitions:

From	Allowed To
`BACKLOG`	`TODO`, `IN_PROGRESS`, `CANCELLED`, `DUPLICATE`
`TODO`	`IN_PROGRESS`, `BACKLOG`, `CANCELLED`, `DUPLICATE`
`IN_PROGRESS`	`REVIEW`, `DONE`, `FAILED`, `CANCELLED`, `TODO`, `DUPLICATE`
`REVIEW`	`DONE`, `TODO`, `IN_PROGRESS`, `FAILED`, `CANCELLED`, `DUPLICATE`
`DONE`	`BACKLOG`
`FAILED`	`BACKLOG`, `TODO`, `IN_PROGRESS`
`CANCELLED`	`BACKLOG`, `TODO`
`DUPLICATE`	(none — terminal)

When status changes to DONE, CANCELLED, or DUPLICATE, completed_at is automatically set. Significant changes (status, assignee, priority) are logged as activity entries.

Work package B11 (docs/prd/PRD-ISSUES-AND-ROUTINES-2026.md §10.4, #2368): the terminal-children rule.

The terminal-children rule. A transition to DONE or REVIEW is refused with a 409 while the issue has a non-terminal sub-issue (parent_issue_id pointing at this issue, status not yet DONE/CANCELLED/DUPLICATE) or a non-terminal plan task (mission_tasks row, status not yet COMPLETED/FAILED/CANCELLED/SKIPPED). The 409 body names every blocker. Add ?force=true to the query string to proceed anyway — the transition then commits and the status-change activity/event entry (both List Activity and List Events) records forced: true and the list of children that were still open, alongside the usual actor fields, as the receipt: no separate approval step, no new table, just the same audit row every other status change writes, with two more facts on it. A FAILED sub-issue still counts as a blocker — a failure is not the same thing as the work being finished. Response: 200 OK — updated issue object.

Status	Condition
`400`	Invalid status transition, no fields to update, `parent_issue_id` equals issue itself, `parent_issue_id`/`routine_id` not in workspace, or `routine_inputs` not valid JSON
`404`	Issue not found
`409`	Transition to `DONE`/`REVIEW` blocked by a non-terminal sub-issue or plan task; retry with `?force=true`

WebSocket event: issue.updated on workspace:{workspaceId}

Delete Issue

DELETE /api/v1/crews/{crewId}/issues/{identifier}?workspace_id={workspaceId}

Hard-deletes the issue. Only issues in BACKLOG or CANCELLED status can be deleted.

Request: crewId and identifier are required path parameters; workspace_id selects the workspace. No request body. Auth: OWNER, ADMIN, or MANAGER role Response: 204 No Content

Status	Condition
`400`	Issue is not in BACKLOG or CANCELLED status
`404`	Issue not found

WebSocket event: issue.deleted on workspace:{workspaceId}

Lifecycle Actions

Drive an issue through agent execution: start, stop, and review.

Transfer Issue Work

POST /api/v1/crews/{crewId}/issues/{identifier}/work?workspace_id={workspaceId}

Changes the current worker while preserving the accountable owner. Human handoffs pause automatic assignments and create a targeted in-product Inbox message. Agent handoffs prepare a new step for an explicit Start work. Auth: authenticated workspace OWNER, ADMIN, or MANAGER (create). Request body:

Field	Type	Required	Description
`operation_id`	string	Yes	Stable ID for retries, at most 100 characters
`revision`	integer	Yes	Current `work_revision` returned by Get Issue
`action`	string	Yes	`take_over`, `handoff_human`, `handoff_agent`, or `submit`
`target_id`	string	For handoff	User or agent ID in this workspace
`note`	string	Except takeover	Result, verification or next instructions, at most 20,000 bytes

{"operation_id":"review-handoff-1","revision":3,"action":"handoff_human","target_id":"user_123","note":"Please verify the attached report."}

Response: 200 OK — {"revision":4,"status":"TODO"}. A replay of the same request returns {"revision":4,"replayed":true} without repeating its effects. Human submit returns status REVIEW. Read the issue again for work_mode, worker_user_id, worker_name, work_note, work_revision, and work_stopping. While stopping is true, active runs have received cancellation but have not yet finished; handing back or submitting must wait.

Status	Condition
`400`	Invalid action, missing note/target, oversized input, or target outside the workspace
`401`	Not authenticated
`403`	Role cannot change work
`404`	Issue not found in this crew and workspace
`409`	Stale revision, reused operation ID with different content, closed issue, held target agent, or active runs preventing handback/submission
`500`	Transaction could not be committed

The work state, cancellation, comment and audit receipt commit together. WebSocket events: issue.updated; human handoff also emits inbox.updated. CLI: crewship issue work.

Set Issue Review Policy

PUT /api/v1/crews/{crewId}/issues/{identifier}/review-policy?workspace_id={workspaceId}

Sets whether a person has to accept the work before the issue counts as done. The policy is part of the issue’s work contract, so it can change only while the issue has not started: TODO or BACKLOG, with no assignment still running. Auth: authenticated workspace OWNER, ADMIN, or MANAGER (create). Request body:

Field	Type	Required	Description
`revision`	integer	Yes	Current `work_revision` returned by Get Issue
`client_review_required`	boolean	Yes	`true` requires human acceptance, `false` drops it

{"revision":3,"client_review_required":true}

Response: 200 OK — {"revision":4,"client_review_required":true}. The revision is the issue’s new work_revision; pass it to the next call that pins one.

Status	Condition
`400`	`revision` or `client_review_required` missing
`401`	Not authenticated
`403`	Role cannot change work
`409`	Stale revision, work already started, or the issue is no longer `TODO`/`BACKLOG`
`500`	Update could not be committed

The CAS on revision is what stops a stale browser from silently removing acceptance that was added to newer work. WebSocket event: issue.updated. CLI: crewship issue review-policy.

Start Issue

POST /api/v1/crews/{crewId}/issues/{identifier}/start?workspace_id={workspaceId}

Starts execution of a BACKLOG or TODO issue. The issue must have an agent delegate — delegate_agent_id (or an assignee resolved from the legacy assignee_type='agent' pair), naming a live, non-held agent. A human owner with no delegate is not enough (F62: existence of any assignee used to be sufficient; it is not anymore — the delegate must specifically be an executable agent). This: Start takes one of two paths, chosen by whether the issue has a bound routine (routine_id): Mission path (no routine bound). This:

Creates a synthetic chat session for the mission
Creates or resets unfinished tasks to PENDING; completed and skipped history stays intact
Transitions status to IN_PROGRESS
Starts the MissionEngine asynchronously

Routine path (routine_id set, #2448). The bound routine runs instead of the mission engine, under the caller’s own identity and the routine’s public execution gates (the same checks as running the routine directly). The server records an issue_executions row in stage working for the Lead to review, moves the issue to IN_PROGRESS, and answers 202 with the run ID. Stored routine_inputs_json are the run’s inputs; a required input with no value and no default is refused before anything is written. A routine start the routine gate rejects is proxied back with that gate’s status and body, and the execution is marked failed. Missing delegate is not a condition on this path. Auth: OWNER, ADMIN, or MANAGER role Response (mission path): 200 OK

{
  "status": "IN_PROGRESS",
  "identifier": "ENG-42"
}

Response (routine path): 202 Accepted

{
  "status": "IN_PROGRESS",
  "identifier": "ENG-42",
  "run_id": "cm1x9k2p40000abcdef123456"
}

run_id is the routine run to follow (crewship routine records); it is also the execution.routine_run_id on Get Issue.

Status	Condition
`400`	Issue not in BACKLOG/TODO; or (mission path) no agent delegate (`"Issue must have an agent delegate before starting"`); or the delegate is not an executable agent — soft-deleted or `PENDING_REVIEW` (`"Issue delegate is not an executable agent"`); or (routine path) the bound routine is not in this workspace, its stored inputs are not a JSON object, or its definition no longer parses
`404`	Issue not found
`409`	Issue was already started by another request, or work is held by a human (`work_mode` = `human` — hand it back first)
`422`	Routine path: `"Missing required routine input: <name>"`
`503`	Routine path: `"Routine execution is unavailable"` — the server runs without a routine executor

WebSocket event: issue.started on workspace:{workspaceId}

Stop Issue

POST /api/v1/crews/{crewId}/issues/{identifier}/stop?workspace_id={workspaceId}&hard={true|false}

Stop ships in two tiers (§10.3), both reachable from this one endpoint.Tier 1 — cooperative, always applied. When the issue is IN_PROGRESS or REVIEW, this happens in one transaction: every PENDING/IN_PROGRESS/BLOCKED mission task is marked CANCELLED, every assignment for the issue that has not reached a terminal state — running, pending, or still queued behind a busy agent or the crew budget — gets cancel_requested_at stamped, and the issue itself moves to CANCELLED. An assignment that hasn’t started its exec yet sees the stamp first and never starts. Without hard=true, one already mid-exec finishes that exec, and only then is recorded — as CANCELLED, never COMPLETED or FAILED, even if it reports success or a late failure after Stop was called; the stamp always wins. No further step is scheduled for the issue.Tier 2 — hard, opt in with ?hard=true. After the Tier 1 stamp above has committed, every assignment it reached that is RUNNING gets its own tmux session ended — tmux kill-session -t agent-{slug}, run as a brand-new exec into the same container the run lives in — escalating to a direct kill -KILL on that session’s own pane process group if the run hasn’t exited within a short grace period. Most agent runs own a tmux session named for their own agent slug (the same session a web terminal attaches to), a container-visible identity: ending it ends exactly that agent’s process tree. This never runs a container-level kill and never signals by OS pid: the crew’s container is shared by every agent on the crew, and a pid resolved from outside the container (ExecInspect’s host-namespace pid) is not safe to signal from inside it — #2365 found exactly that bug in the pre-fix mechanism, live on dev1. A sibling agent’s own session is a different name and is never touched, by construction. A run whose exec bypassed tmux entirely (an oversized prompt delivered via stdin, or a container without tmux installed) has no session to end; Tier 2 confirms that first (listing the session’s pane pids before touching it) and reports NOT_FOUND immediately rather than sending a signal that would reach nothing. Bounded to a few seconds. What was signalled and the result (TERMINATED_TERM, TERMINATED_KILL, ALREADY_EXITED, NOT_FOUND, UNSUPPORTED, or ERROR) is written to assignments.hard_stop_result (and hard_stop_at) and to an assignment.hard_stopped journal entry — independent of, and in addition to, the Tier 1 CANCELLED terminal write, which always lands regardless of what the signal achieved. UNSUPPORTED means there is no container-visible identity to signal by at all (no container configured, or the assignee is not an agent); the run is still CANCELLED by Tier 1 either way.An @mention can dispatch a run on an issue that was never started (BACKLOG/TODO) — that run is attributed to the issue the same way a mission-task run is. Stop reaches it too: when the issue is not IN_PROGRESS/REVIEW but has at least one live attributed assignment, Stop stamps cancel_requested_at on it (and, with hard=true, signals it the same way if it is already RUNNING) and leaves the issue’s own status unchanged (it does not move the issue to IN_PROGRESS or CANCELLED). Stop only refuses with 400 when the issue is neither IN_PROGRESS/REVIEW nor has any live attributed run.

Request: crewId and identifier are required path parameters; workspace_id selects the workspace; hard (optional, default false) opts into Tier 2. No request body. Auth: OWNER, ADMIN, or MANAGER role Response: 200 OK

{
  "status": "CANCELLED",
  "identifier": "ENG-42",
  "runs_stopped": 1,
  "hard": false
}

status is CANCELLED when the issue was IN_PROGRESS/REVIEW; otherwise it echoes the issue’s unchanged status (e.g. BACKLOG) for the mention-dispatched-run case above. runs_stopped is the number of assignment rows stamped by Tier 1. hard echoes whether ?hard=true was requested — it does not report per-target Tier 2 results, which live on each assignment row and in the journal instead.

Status	Condition
`400`	Issue not in IN_PROGRESS or REVIEW status, and no live run is attributed to it
`404`	Issue not found

Review Issue

POST /api/v1/crews/{crewId}/issues/{identifier}/review?workspace_id={workspaceId}

Submit a review decision for an issue in REVIEW or IN_PROGRESS status. Auth: OWNER, ADMIN, or MANAGER role Request Body:

Field	Type	Required	Description
`action`	string	Yes	`"approve"` or `"request_changes"`
`comment`	string	No	Review comment
`reassign_to`	string	No	Agent slug to reassign to (for `request_changes`)
`revision`	integer	No	The `work_revision` you reviewed. When set, a mismatch is `409` (#2448)
`brief_revision`	integer	No	The `brief_revision` you reviewed. Same rule

{
  "action": "request_changes",
  "comment": "The error handling needs improvement",
  "reassign_to": "backend-dev",
  "revision": 4,
  "brief_revision": 2
}

approve: Transitions issue to DONE, adds approval comment and activity
request_changes: Transitions issue to TODO, optionally reassigns, adds comment and activity, and moves a Lead-accepted (or needs_human) execution to changes_requested with the comment as its note

The review is a compare-and-set against the work contract. Nothing changes on a 409:

`409` message	Meaning
`The issue changed. Refresh before reviewing.`	`revision` or `brief_revision` was sent and does not match the row
`Work or Lead review is still running. Stop it or wait for the result before reviewing.`	A run is live on the issue, or an execution is still `working`/`reviewing`
`The brief changed after submission. Submit an updated result before approving.`	`approve` on human work whose `submitted_brief_revision` is older than the current brief
`The result belongs to an older brief. Run the updated work before approving.`	`approve` on agent work whose latest execution was produced for an older `brief_revision`

Response: 200 OK

{
  "status": "ok",
  "action": "request_changes"
}

Status	Condition
`400`	Invalid action, issue not in reviewable status, or `reassign_to` is not an available agent in this workspace
`404`	Issue not found
`409`	One of the four compare-and-set refusals above

CLI: crewship issue review sends both revisions from the issue it just read; --revision/--brief-revision pin them.

Bulk

Apply one set of field updates across many issues from the board/list multi-select toolbar.

Bulk Update

PATCH /api/v1/issues/bulk

Apply a single set of field updates to up to 100 issues at once. Used by the board/list views’ multi-select toolbar. Each issue is processed in its own statement — partial success is possible: a request touching 50 ids where 3 have invalid status transitions returns {"updated": 47} rather than rolling back. Auth: OWNER, ADMIN, or MANAGER role (create permission). Request Body:

Field	Type	Required	Description
`ids`	string[]	Yes	1-100 mission ids. Ids outside the caller’s workspace are skipped silently.
`updates.status`	string	No	New status. Invalid transitions are skipped per-issue (not 400). When `DONE`, `CANCELLED`, or `DUPLICATE`, `completed_at` is set automatically.
`updates.priority`	string	No	Priority level.
`updates.assignee_type`	string	No	`"user"` or `"agent"`.
`updates.assignee_id`	string	No	Assignee id.
`updates.project_id`	string	No	Project id; empty string unlinks.
`updates.labels`	string[]	No	Replace all labels on each issue with this set of label ids.

{
  "ids": ["issue_abc", "issue_def", "issue_ghi"],
  "updates": {
    "status": "TODO",
    "priority": "high",
    "labels": ["label_bug", "label_blocker"]
  }
}

Response: 200 OK

{ "updated": 3 }

Field	Type	Description
`updated`	integer	Count of issues that successfully applied at least one field. Issues whose `updates` resolved to a no-op are excluded.

Status	Condition
`400`	Invalid JSON, missing `ids`, or `ids` length > 100.
`403`	Caller lacks the `create` permission for the workspace.

When updated > 0, an issues.bulk_updated WebSocket event is broadcast on workspace:{workspaceId} with the count. Per-issue status changes additionally produce activity entries (status_changed, details suffixed with (bulk)).

Sub-issues

Issues can nest via parent_issue_id. List the children of one parent.

List Sub-issues

GET /api/v1/crews/{crewId}/issues/{identifier}/subtasks

Returns the children of one parent issue — rows where parent_issue_id equals the resolved parent id. Ordered by sort_order ASC, created_at ASC so the response matches the order operators see in the UI’s nested list. Path parameters:

Param	Description
`crewId`	Crew id (used to disambiguate identifiers across crews).
`identifier`	Human-readable identifier (e.g. `ENG-42`) or raw mission id of the parent.

Response: 200 OK — array of full issue objects matching the GET /api/v1/issues shape. Empty array (never null) when the parent has no sub-issues.

Status	Condition
`404`	Parent issue not found in the supplied crew + workspace.
`500`	DB read failure.

Activity

A read-only audit trail of significant issue changes.

List Activity

GET /api/v1/crews/{crewId}/issues/{identifier}/activity?workspace_id={workspaceId}

Returns the activity log for an issue (status changes, assignments, reviews). Limited to 50 most recent entries. Response: 200 OK

[
  {
    "id": "act_abc",
    "mission_id": "issue_123",
    "actor_type": "user",
    "actor_id": "user_456",
    "actor_name": "John Doe",
    "action": "status_changed",
    "details": "TODO -> IN_PROGRESS",
    "created_at": "2024-01-15T10:00:00Z"
  }
]

Activity Actions: created, status_changed, assignee_changed, priority_changed, description_changed, parent_changed, relation_added, commented, mentioned (an @mention in a comment was recorded for dispatch — the row is the only user-visible trace of the delivery besides the inbox item), attachment_added, attachment_removed, code_link_added, code_link_removed, review_approved, review_changes_requested, task_completed, task_failed, task_cancelled (Stop reached a task or a live run), inbox_acted (a person acted on the issue’s NEEDS_HUMAN inbox card — the receipt names the action, the card, the session’s agent_version and, for an answer, the delivery and run it produced; see Acting on a card) description_changed records that the description was rewritten, never the text itself — details carries only lengths (description updated (128 → 342 chars)). An issue description is unbounded user input, and an audit row is not a revision store; if you need the previous text, read the issue history in your own tooling before you PATCH. Every action above also writes a Crew Journal entry, which is what notifications are routed from — including the ones an agent produces through the internal API. A client that reads the activity list sees the same events a Slack/ntfy subscriber does.

List Events

Work package B11 of the Issues & Routines architecture (docs/prd/PRD-ISSUES-AND-ROUTINES-2026.md §14.1/§17, #2368). This is the read side of the B1 event log (mission_activity, work package B1) — the SAME rows List Activity above returns, ordered by seq (not created_at) and not capped at 50.

GET /api/v1/crews/{crewId}/issues/{identifier}/events?workspace_id={workspaceId}&after_seq={n}

Exists for one reason: the realtime allowlist (hooks/use-realtime.tsx) only guards which event TYPES a client accepts — it says nothing about whether every frame of an accepted type actually arrived. The server’s WebSocket hub sends non-blocking and silently drops a frame when a client’s send buffer is full. issue.delivery.acked (work package B2) is the one realtime type today whose payload carries a seq; a client that notices its next seq isn’t exactly one more than the last calls this endpoint with after_seq set to the last seq it has confirmed, and gets back everything in between — instead of staying stale until someone reloads the tab.

One call is not guaranteed to return the whole gap: a response is capped at 500 rows regardless of how large the range between after_seq and the mission’s current seq is. A caller that needs everything must keep requesting with after_seq set to the last row’s own seq (not the response’s latest_seq) until the returned events is empty or a returned row’s seq reaches latest_seq. crewship issue events and the board’s client-side gap resync (hooks/use-issue-event-gap-resync.ts) both page this way; treating the first page as the whole answer silently drops everything past row 500.

Query param	Type	Description
`after_seq`	integer	Only return events with `seq` greater than this. Omitted or `0` returns the full history. Must be a non-negative integer.
`before_seq`	integer	Page backwards: return the newest `limit` events with `seq` below this, still in `seq` order. `0` means “from the newest”. Cannot be combined with `after_seq`. The response then carries `before_seq` and `has_older` — whether events exist below the returned page. Activity reads an issue’s history this way, newest first, with “Load older”.
`limit`	integer	Page size, 1–500 (default and cap 500).

The path’s {identifier} also accepts the issue’s id, as does GET /api/v1/issues/{identifier}, for issues known only by id. Response: 200 OK

{
  "events": [
    {
      "id": "act_abc",
      "mission_id": "issue_123",
      "seq": 42,
      "actor_type": "user",
      "actor_id": "user_456",
      "actor_name": "John Doe",
      "action": "status_changed",
      "details": "TODO -> IN_PROGRESS (forced past 1 open child item(s))",
      "payload_json": "{\"action\":\"status_changed\",\"from\":\"TODO\",\"to\":\"DONE\",\"forced\":true,\"open_children\":[\"issue ENG-5 (IN_PROGRESS)\"]}",
      "source_kind": null,
      "source_id": null,
      "created_at": "2024-01-15T10:00:00Z"
    }
  ],
  "after_seq": 41,
  "latest_seq": 42
}

Field	Type	Description
`events`	array	The page, ordered oldest-first, `seq > after_seq`. Capped at 500 rows.
`after_seq`	integer	Echoes the request’s cursor.
`latest_seq`	integer	The issue’s current high-water mark — lets a caller with an empty `events` array tell “caught up” from “server has never heard of this issue”.

payload_json carries the same action/from/to shape the journal entry gets, plus forced/open_children on a status change that bypassed the terminal-children rule with ?force=true — the receipt naming which children were still open. It is null on a row from before this column existed. Auth: any authenticated workspace member (read).

Status	Condition
`400`	`after_seq` is not a non-negative integer
`404`	Issue not found in the supplied crew + workspace

Get Full Run Result

GET /api/v1/crews/{crewId}/issues/{identifier}/runs/{runId}/result?workspace_id={workspaceId}

Returns the full stored result on demand. runId is the assignment id from List Runs, not its trace ID. The assignment must belong to the supplied issue. The list exposes result_truncated for a shortened preview and result_stale when its recorded brief revision predates the current issue brief. Auth: any authenticated workspace member (read). No request body. Query parameter: workspace_id selects the authenticated workspace. Response: 200 OK

{"result_summary":"All findings and their evidence…","outcome":"SUCCEEDED","status":"COMPLETED"}

result_summary is the stored agent-authored text and may be empty. The endpoint does not invent a deliverable or confirm acceptance of the issue.

Status	Condition
`401`	Not authenticated
`403`	Workspace access denied
`404`	Run is absent or belongs to another issue/crew/workspace
`500`	Stored result could not be read

CLI: crewship issue result.

Runs

The agent executions behind an issue. Issues run on the mission engine (not pipelines), so a “run” is a mission task backed by an assignments row.

List Runs

GET /api/v1/crews/{crewId}/issues/{identifier}/runs?workspace_id={workspaceId}

Lists every run attributed to an issue — not just mission tasks joined to their assignments row, but also mention-dispatched runs (an agent tagged in a comment) and delegation-hop runs (a sub-agent assigned further work via /assign mid-mission). Newest-first. Pages like every list: limit (default 100, max 500) and offset, with the total in the X-Total-Count, X-Limit and X-Offset response headers. Each row is one assignment (an agent task-run) and carries:

Field	Meaning
`id`	The assignment id — the row’s identity in this list
`run_id`, `trace_id`	The journal run the assignment produced (one value, `trace_id == run id`); both absent when the assignment never reached a run
`agent_id`, `agent_slug`, `agent_name`	The agent that ran it — the slug is what its page is keyed on
`status`, `task`, `started_at`, `ended_at`, `duration_ms`, `result_summary`, `error_message`	The execution
`outcome`	The §9.6 routing decision — see Outcome below
`hard_stop_result`, `hard_stop_at`	What a Tier 2 hard stop did to this run, and when — see Stop Issue’s Tier 2 paragraph above. Absent on a run that was never hard-stopped

Request: crewId and identifier are required path parameters; workspace_id selects the workspace. No request body. Auth: any authenticated workspace member (read). Response: 200 OK — a JSON array (never null).

[
  {
    "id": "m_1a0864071c85b082f6adb2c",
    "status": "completed",
    "agent_name": "Backend Dev",
    "task": "Refresh token handling",
    "started_at": "2026-01-15T10:00:00Z",
    "ended_at": "2026-01-15T10:04:12Z",
    "duration_ms": 252000,
    "result_summary": "Patched refresh path and added a regression test.",
    "error_message": "",
    "mission_id": "issue_123",
    "source": "task",
    "outcome": "SUCCEEDED"
  }
]

hard_stop_result/hard_stop_at are omitted here — this run was never hard-stopped. A run Tier 2 reached instead carries them, e.g. "hard_stop_result": "TERMINATED_TERM", "hard_stop_at": "2026-09-04T10:00:05Z".

Field	Type	Description
`id`	string	Assignment (run) ID
`status`	string	Assignment status
`agent_name`	string?	Resolved name of the assigned agent (omitted when empty)
`task`	string?	Task text (omitted when empty)
`started_at`	string?	Start timestamp (omitted when empty)
`ended_at`	string?	Finish timestamp (omitted when empty)
`duration_ms`	integer	Elapsed time in ms; `0` when timing can’t be derived
`result_summary`	string?	Agent-authored result prose, truncated for the list (omitted when empty)
`error_message`	string?	Failure detail, truncated for the list (omitted when empty)
`mission_id`	string?	The issue this run is attributed to (`assignments.mission_id`, #2256). Nil on a legacy row written before that column existed, never touched by the backfill, and found here only via the `mission_tasks` join
`source`	string	Why this run is attributed to the issue: `task` (the issue’s own `mission_tasks` plan), `mention` (an `@mention` dispatch, via `mission_comment_mentions`), or `delegation` (a sub-agent’s own further `/assign` call mid-mission, found only via `mission_id`)
`outcome`	string?	The §9.6 routing decision (work package B6, #2349) — see Outcome below. Omitted on a run that predates the `outcome` column
`hard_stop_result`	string?	Tier 2 hard termination’s own result (work package B7b, #2365) — `TERMINATED_TERM`, `TERMINATED_KILL`, `ALREADY_EXITED`, `UNSUPPORTED`, `NOT_FOUND`, `ERROR`, or `PENDING_EXEC`. Omitted on a run that was never hard-stopped
`hard_stop_at`	string?	When the hard-stop attempt above was recorded. Omitted alongside `hard_stop_result`

Status	Condition
`404`	Issue not found in the supplied crew + workspace

Outcome

Work package B6 of the Issues & Routines architecture (docs/prd/PRD-ISSUES-AND-ROUTINES-2026.md §9.6). status (above), outcome and runverdict answer three different questions and are easy to conflate — see docs/guides/routines.mdx’s “Status, outcome and verdict” section for the full comparison.

Every finished run — an issue-session assignment or a routine (pipeline_runs) run — carries an outcome, the deterministic routing decision the runner reports, distinct from its technical status:

Outcome	Meaning	§9.6’s intended routing
`NO_CHANGE`	Ran, nothing to do	History only
`SUCCEEDED`	Did the work, nothing further needed	History
`WORK_CREATED`	Produced or updated an issue	History (+ an issue comment, once wired — see note)
`PARTIAL`	Some done, some failed, no human needed yet	History (+ an issue comment, once wired — see note)
`NEEDS_HUMAN`	Blocked on a decision, missing input, or a credential	Inbox (`run_needs_human`), with an action contract — see below
`FAILED`	The run failed, or reported no outcome at all	Inbox once retries are exhausted (not yet wired — no retry counting exists)
`CANCELLED`	Stopped by a human (Tier 1 stop) or superseded	History

What this table describes vs. what is wired today. NEEDS_HUMAN’s inbox routing and the session-state transition below are real, outcome-driven effects — this PR (B6) added them. The ”+ an issue comment” cells for WORK_CREATED/PARTIAL are §9.6’s stated intent, not yet a real, outcome-gated effect: an issue-session assignment already gets a mission comment posted on completion (finishAssignment), but that path predates outcome and fires for ANY non-empty, non-error result — a SUCCEEDED or NO_CHANGE run with output gets one too, and a routine (pipeline_runs) run gets no issue comment at all regardless of outcome, since no comment-posting path exists for that run shape yet. Gating the comment on outcome specifically (and adding one for routine runs) is a follow-up, not part of this PR.

outcome is parsed from the agent’s existing structured hand-off — the ---CHECKPOINT--- block a session-bearing run is instructed to emit (§11.3), or the ---HANDOFF--- block a mission-task run emits — never a second, invented block. A run that ends cleanly (no execution error) but reports no recognised outcome is recorded FAILED, with error_message set to "no outcome reported" — an absent outcome is treated as a bug, not a silent success. That default applies wherever somebody could have reported one: an agent run always could, and so could a routine holding an agent_run (or a call_pipeline, whose target may hold one). A routine with no agent step at all — an agentless: true probe, or one built only from script / transform / notify / crewship steps — could never report one, so a clean run there is recorded SUCCEEDED with an empty error_message rather than being flagged for a hand-off that was impossible by construction. A run stopped by Stop (Tier 1 cooperative cancellation) or superseded always gets CANCELLED, regardless of what its own hand-off said. NEEDS_HUMAN is the only outcome that creates an inbox item — exactly one, keyed on the run id, so a retried terminal write can never double it. The item’s payload_json carries a §12 action contract:

{
  "attention_class": "input",
  "thread_key": "run:m_1a0864071c85b082f6adb2c",
  "who_can_act": ["user:usr_123"],
  "actions": [
    {"id": "take_over", "label": "Take over", "effect": "Opens the issue for you to continue", "irreversible": false}
  ],
  "context": {"issue": "ENG-42", "run": "m_1a0864071c85b082f6adb2c"}
}

For a session-bearing assignment, NEEDS_HUMAN also moves the issue’s session to awaiting_input (see Sessions, below) — the transition that needed this column to exist before it could be reached at all. WebSocket event: run.outcome on workspace:{workspaceId} — {mission_id, identifier, assignment_id, status, outcome} (work package B11, #2368). Fired once the outcome above is decided, for a run attributed to an issue; not fired for a run with no mission_id (a root /assign).

Sessions

Session lifecycle: issue_agent_sessions is work package B1 (event log + session foundations) of the Issues & Routines architecture (docs/prd/PRD-ISSUES-AND-ROUTINES-2026.md), extended by B3 (#2339, the run-admission guarantee: at most one assignments row may be PENDING/QUEUED/RUNNING for a given session at a time, a partial unique index rather than a read-then-write check), B4 (#2343) and B6 (#2349, the outcome contract): state genuinely moves with its runs — pending → active when a run wins the admission CAS, then, once that run settles, resolved through its outcome — active → idle for NO_CHANGE/SUCCEEDED/WORK_CREATED/PARTIAL/CANCELLED, active → error for FAILED, and active → awaiting_input for NEEDS_HUMAN (the transition B4 could not reach until outcome existed) — with active_run_id populated for as long as a run is live, cleared once it settles. What is still NOT wired: the 14-day idle → stale sweep. An ephemeral agent that expires mid-session is reconciled onto error (was active) or closed (otherwise) rather than left rendered active over a ghost.

The durable, per-(issue, agent) cursor a mention resolves or creates. UNIQUE(mission_id, agent_id) on the underlying table means mentioning the same agent on the same issue twice never creates a second session — the second mention finds and reuses the first’s row. UNIQUE on assignments.session_id (partial, live statuses only) means a session backs at most one live run: a mention that lands while the session’s run is already going does not start a second one — its delivery is left unclaimed and is folded into exactly one new run once the live one finishes, rather than being marked seen by a run that never read it. See docs/guides/issue-mentions.mdx’s “Known limits in 1.0” for the full account. WebSocket event: issue.session.state on workspace:{workspaceId} — {mission_id, identifier, session_id, agent_id, state} (work package B11, #2368). Fired on every landed transition above; not fired for a transition the row’s own guard refused (e.g. activating a closed session).

List Sessions

GET /api/v1/crews/{crewId}/issues/{identifier}/sessions?workspace_id={workspaceId}

Lists every issue_agent_sessions row for this issue, newest-updated first. Request: crewId and identifier are required path parameters; workspace_id selects the workspace. No request body. Auth: any authenticated workspace member (read). Response: 200 OK — a JSON array (never null).

[
  {
    "id": "sess_abc",
    "mission_id": "issue_123",
    "agent_id": "agent_456",
    "agent_name": "Backend Dev",
    "state": "pending",
    "last_consumed_seq": 0,
    "agent_version": 3,
    "last_activity_at": "2026-09-04T10:00:00Z",
    "created_at": "2026-09-04T10:00:00Z",
    "updated_at": "2026-09-04T10:00:00Z"
  }
]

Field	Type	Description
`id`	string	Session ID
`mission_id`	string	The issue this session belongs to
`agent_id`	string	The agent this session belongs to
`agent_name`	string?	Resolved name of the agent (omitted when empty)
`state`	string	One of `pending`, `active`, `awaiting_input`, `idle`, `error`, `stale`, `closed`. `pending → active` on a claimed run; when it ends, the outcome routes it (B6, #2358): `NO_CHANGE`/`SUCCEEDED`/`WORK_CREATED`/`PARTIAL`/`CANCELLED → idle`, `FAILED → error`, `NEEDS_HUMAN → awaiting_input`. An inbox `answer`, `take_over` or `dismiss` on the card moves `awaiting_input → idle`. Only the 14-day `idle → stale` sweep is not wired yet — nothing writes `stale`
`last_consumed_seq`	integer	The cursor into `mission_activity.seq` — everything above it is unread for this session. `0` for a session that has read nothing
`active_run_id`	string?	The live run this session is waiting on, when one exists (omitted when empty)
`agent_version`	integer?	The `agent_config_history.version` this session was opened under, stamped once at creation (omitted when the agent has no config history)
`last_activity_at`	string?	Last time this session saw activity (omitted when empty)
`created_at`	string	Session creation timestamp
`updated_at`	string	Last update timestamp

Status	Condition
`404`	Issue not found in the supplied crew + workspace

List Checkpoints

Work package B5 of the Issues & Routines architecture (docs/prd/PRD-ISSUES-AND-ROUTINES-2026.md §9.5, #2345). A checkpoint is the structured state a session-bearing run reports at the end of every run (done/plan/facts/blockers/next_step/confidence), so the next run on the same session can resume without rediscovering it. It is what the §11.1 context pack’s “latest checkpoint” section is built from — see Sessions, checkpoints and the context pack.

GET /api/v1/crews/{crewId}/issues/{identifier}/sessions/{sessionId}/checkpoints?workspace_id={workspaceId}

Lists every agent_session_checkpoints row for one session, newest-first — the session’s full resumable history, not just its current cursor (GET .../sessions already reports last_consumed_seq). WebSocket event: issue.checkpoint.written on workspace:{workspaceId} — {mission_id, identifier, session_id, agent_id} (work package B11, #2368). Fired when a new row lands here, so an open session panel can refresh without polling. Request: crewId, identifier and sessionId are required path parameters; workspace_id selects the workspace. sessionId must belong to the named issue, or the request 404s. No request body. Auth: any authenticated workspace member (read). Response: 200 OK — a JSON array (never null).

[
  {
    "id": "chk_abc",
    "session_id": "sess_abc",
    "run_id": "run_789",
    "seq_at_write": 42,
    "done": "Implemented the parser and its tests",
    "plan": "Wire the parser into the dispatch path next",
    "next_step": "Add the acceptance test",
    "confidence": "high",
    "parsed": true,
    "created_at": "2026-09-04T10:00:00Z"
  }
]

Field	Type	Description
`id`	string	Checkpoint ID
`session_id`	string	The session this checkpoint belongs to
`run_id`	string?	The run that wrote it (omitted when empty — deliberately no foreign key; see the migration)
`seq_at_write`	integer	The mission’s `mission_activity.seq` high-water mark at write time (bookkeeping only)
`done`	string?	What the run finished — read this first when resuming
`plan`	string?	The run’s understanding of the path to the goal
`facts`	string?	Identifiers, decisions and constraints worth carrying forward
`blockers`	string?	What is stopping progress, if anything
`next_step`	string?	The single next action to take
`confidence`	string?	`low`, `medium` or `high`
`parsed`	boolean	`false` when the run ended without a valid `---CHECKPOINT---` block — every other field is then empty, and this is how that is told apart from a run that genuinely reported nothing
`created_at`	string	Write timestamp

Status	Condition
`404`	Issue not found in the supplied crew + workspace, or `sessionId` does not belong to this issue

Comments

Threaded discussion on an issue, ordered oldest-first.

List Comments

GET /api/v1/crews/{crewId}/issues/{identifier}/comments?workspace_id={workspaceId}

Returns comments on an issue in chronological order. Legacy reads without page_size return all comments. Set page_size=100 for the latest page (maximum 100) and pass its oldest comment ID as before_id to read older messages. X-Has-More: true indicates another page. The stable timestamp + ID cursor is not shifted by a newly posted comment. Request: crewId and identifier are required path parameters; workspace_id selects the workspace. No request body. Response: 200 OK

[
  {
    "id": "comment_abc",
    "mission_id": "issue_123",
    "author_type": "user",
    "author_id": "user_456",
    "author_name": "John Doe",
    "body": "This looks good, just fix the edge case",
    "created_at": "2024-01-15T10:00:00Z",
    "updated_at": "2024-01-15T10:00:00Z"
  }
]

Create Comment

POST /api/v1/crews/{crewId}/issues/{identifier}/comments?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body:

Field	Type	Required	Description
`body`	string	Yes	Comment text

{
  "body": "This looks good, just fix the edge case"
}

Response: 201 Created — comment object with author_type: "user".

Relations

Link issues to one another (blocks, relates to, duplicate of). Relation types are flipped when viewed from the target side.

List Relations

GET /api/v1/crews/{crewId}/issues/{identifier}/relations?workspace_id={workspaceId}

Returns all relations for an issue. Relation types are flipped when viewed from the target side (e.g., blocks becomes blocked_by). Request: crewId and identifier are required path parameters; workspace_id selects the workspace. No request body. Response: 200 OK

[
  {
    "id": "rel_abc",
    "source_id": "issue_123",
    "target_id": "issue_456",
    "relation_type": "blocks",
    "target_identifier": "ENG-43",
    "target_title": "Deploy auth service",
    "target_status": "BACKLOG",
    "created_at": "2024-01-15T10:00:00Z"
  }
]

Create Relation

POST /api/v1/crews/{crewId}/issues/{identifier}/relations?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body:

Field	Type	Required	Description
`target_identifier`	string	Yes	Target issue identifier (e.g., `ENG-43`)
`relation_type`	string	Yes	`blocks`, `blocked_by`, `relates_to`, or `duplicate_of`

{
  "target_identifier": "ENG-43",
  "relation_type": "blocks"
}

Internally, blocked_by is stored as blocks with source/target swapped for normalization. Response: 201 Created

Status	Condition
`400`	Invalid relation_type, self-relation
`404`	Source or target issue not found
`409`	Relation already exists

Delete Relation

DELETE /api/v1/relations/{relationId}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request: relationId is a required path parameter and workspace_id selects the workspace. No request body. Response: 200 OK with {"status": "ok"}

Status	Condition
`404`	Relation not found

Code links

Attach the pull request / merge request that resolves an issue. The provider is recognised from the URL’s path grammar (/pull/<n> → GitHub, /-/merge_requests/<n> → GitLab), so github.com, gitlab.com and self-hosted instances of either all work. State is fetched through the provider’s REST API using a stored GITHUB / GITLAB credential — see Git links for how the credential is chosen and how private-network forges are allowed.

List code links

GET /api/v1/crews/{crewId}/issues/{identifier}/code-links?workspace_id={workspaceId}

Response: 200 OK

[
  {
    "id": "cmsezurje0003d5e624ad",
    "mission_id": "issue_123",
    "provider": "GITHUB",
    "host": "github.com",
    "owner": "acme",
    "repo": "thing",
    "number": 7,
    "kind": "pull_request",
    "url": "https://github.com/acme/thing/pull/7",
    "title": "Add the widget",
    "state": "OPEN",
    "author": "octocat",
    "source_branch": "feat/widget",
    "target_branch": "main",
    "remote_merged_at": null,
    "credential_id": "cred_abc",
    "last_synced_at": "2026-08-04T18:31:03Z",
    "last_sync_error": null
  }
]

state is OPEN, DRAFT, MERGED or CLOSED — normalised across both providers. A merged GitHub pull request reports closed with a merged_at; Crewship records it as MERGED.

Attach a code link

POST /api/v1/crews/{crewId}/issues/{identifier}/code-links?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body:

Field	Type	Required	Description
`url`	string	Yes	The pull-request / merge-request web URL

{ "url": "https://github.com/acme/thing/pull/7" }

Response: 201 Created — the stored link, the same object shape List code links returns.

{
  "id": "cmsezurje0003d5e624ad",
  "mission_id": "issue_123",
  "provider": "GITHUB",
  "host": "github.com",
  "owner": "acme",
  "repo": "thing",
  "number": 7,
  "kind": "pull_request",
  "url": "https://github.com/acme/thing/pull/7",
  "title": "Add the widget",
  "state": "OPEN",
  "author": "octocat",
  "source_branch": "feat/widget",
  "target_branch": "main",
  "remote_merged_at": null,
  "credential_id": "cred_abc",
  "last_synced_at": "2026-08-04T18:31:03Z",
  "last_sync_error": null
}

The state is fetched before the row is written, so a 201 means the link was reachable. Errors are application/problem+json (RFC 7807) with a stable type URI under https://crewship.ai/problems/code-link/ and a code member, because several failures share a status:

Status	`code`	Condition
`400`	`invalid-body`	The request body is not valid JSON
`400`	`unsupported-url`	Not a recognised pull-request / merge-request URL
`403`	—	Caller lacks the MANAGER floor
`404`	`issue-not-found`	No such issue in this crew/workspace
`404`	`pull-request-not-found`	Provider returned 404 (or the credential cannot see a private repo)
`409`	`already-linked`	That pull request is already attached to this issue
`412`	`no-credential`	No ACTIVE credential for that provider can reach that host
`422`	`blocked-host`	The forge is on a private/internal address and the opt-in is off
`429`	`rate-limited`	Provider throttled; `Retry-After` is set when known
`502`	`credential-rejected`	Provider returned 401 — token revoked or expired
`502`	`credential-forbidden`	Token valid but lacks repository read access
`502`	`provider-unavailable`	Provider returned 5xx or did not answer
`502`	`cross-host-redirect`	The provider redirected off its own host; not followed, because the request carries a credential

Refresh a code link

POST /api/v1/crews/{crewId}/issues/{identifier}/code-links/{linkId}/refresh?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body: none. The link is addressed by the linkId path parameter; workspace_id is the only query parameter. Re-reads the link from its provider and returns the updated object. State is never polled in the background; this is the only refresh path. Response: 200 OK — the refreshed link, the same object shape List code links returns, with last_synced_at moved forward and last_sync_error cleared.

Status	`code`	Condition
`200`	—	Re-fetched; the row now reflects the provider
`403`	—	Caller lacks the MANAGER floor
`404`	`issue-not-found`	No such issue in this crew/workspace
`404`	`link-not-found`	No such link on this issue
`412`	`no-credential`	No ACTIVE credential for that provider can reach that host
`429`	`rate-limited`	Provider throttled; `Retry-After` is set when known
`502`	`credential-rejected` / `credential-forbidden` / `provider-unavailable`	The provider refused or did not answer

A failed refresh keeps the previously fetched state and records the reason on the row (last_sync_error), then returns the same problem document the attach path would.

Delete a code link

DELETE /api/v1/crews/{crewId}/issues/{identifier}/code-links/{linkId}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body: none. The link is addressed by the linkId path parameter; workspace_id is the only query parameter. Response: 200 OK with {"status": "ok"} Hard delete — the row goes, the way a mission_relation does. Nothing about the pull request on the forge changes.

Status	`code`	Condition
`200`	—	Removed
`403`	—	Caller lacks the MANAGER floor
`404`	`link-not-found`	Link not found on this issue

Attachments

Attach files to an issue — a crash log, a screenshot, a repro bundle, a diff. Everything an agent working the issue needs to see and, before this surface existed, had to be pasted into a comment. Three properties are worth knowing before you use it:

The type is decided by the file’s extension, against an allowlist. The request’s own Content-Type is discarded. That header is chosen by whoever is uploading, and honouring it is how a stored file becomes stored XSS served from your own origin. Allowed today: .txt .log .md .csv .tsv .json .yaml .yml .toml .xml .diff .patch .png .jpg .jpeg .gif .webp .avif .pdf .zip .gz .tgz. .html, .svg and anything executable are absent deliberately, not by oversight.
Files are stored by content. Two issues carrying identical bytes share one stored copy, and attaching the same file to the same issue twice is the same attachment — the second call returns 200 with the existing record rather than 201 or 409, so a retry is safe. “The same file” means the same bytes under the same name: crash-before-fix.log and crash-after-fix.log can be byte-identical and mean opposite things, so both are attached and both get 201, sharing one stored copy.
The uploaded filename is a label, never a path. The stored location is derived entirely from the SHA-256 digest, so a filename of ../../../etc/passwd is recorded as passwd and the bytes land where every other attachment’s do.

Agents reach the same files through the sidecar — see Attachments an agent can read.

List attachments

GET /api/v1/crews/{crewId}/issues/{identifier}/attachments?workspace_id={workspaceId}

Auth: any workspace member (session or CLI token). The workspace is taken from the authenticated session, so an issue in another workspace is a 404. Request: workspace_id is the required workspace query parameter. No request body. Response: 200 OK — newest first.

[
  {
    "id": "cmsf1a2b30001d5e6aa11",
    "workspace_id": "ws_abc",
    "owner_type": "issue",
    "owner_id": "issue_123",
    "filename": "crash.log",
    "content_type": "text/plain; charset=utf-8",
    "size_bytes": 20481,
    "sha256": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "uploaded_by_user_id": "user_1",
    "uploaded_by_agent_id": null,
    "uploaded_by_name": "Ada Lovelace",
    "created_at": "2026-08-06T19:22:41Z"
  }
]

sha256 is part of the contract: it lets a client verify what it downloaded, and lets an agent decide it has already read this exact file. The on-disk storage key is deliberately not exposed.

Status	Condition
`200`	Listed (possibly empty)
`400`	No workspace resolved for the caller
`404`	Issue not found in this workspace

Upload an attachment

POST /api/v1/crews/{crewId}/issues/{identifier}/attachments?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body: multipart/form-data with one part.

Field	Type	Required	Description
`file`	file	Yes	The file. Maximum 25 MiB. Its extension must be on the allowlist above

curl -X POST \
  -H "Authorization: Bearer $CREWSHIP_TOKEN" \
  -F "file=@./crash.log" \
  "https://crewship.example.com/api/v1/crews/crew_1/issues/ENG-4/attachments?workspace_id=ws_abc"

Response: 201 Created — the stored record, the same object shape List attachments returns. 200 OK instead of 201 means this exact file — these bytes, under this filename — was already attached to this issue: no second record was created, no second timeline entry was written, and the returned object is the one that already existed. The same bytes under a different filename are a different attachment and get 201.

Status	Condition
`201`	Attached
`200`	Already attached — the same bytes under the same filename, on the same issue
`400`	Malformed multipart form, missing `file` part, or a filename that sanitises to nothing
`403`	Caller lacks the MANAGER floor
`404`	Issue not found in this workspace
`413`	Larger than 25 MiB
`415`	Extension not on the allowlist — the response lists what is allowed
`503`	This instance has no storage provider configured

Download an attachment

GET /api/v1/crews/{crewId}/issues/{identifier}/attachments/{attachmentId}?workspace_id={workspaceId}

Auth: any workspace member. Request: workspace_id is the required workspace query parameter. The file is addressed by the attachmentId path parameter. No request body. Response: 200 OK — the raw bytes, with three headers that matter:

Header	Value
`Content-Type`	The type Crewship resolved from the extension, never the uploader’s
`X-Content-Type-Options`	`nosniff`
`Content-Disposition`	`attachment; filename="crash.log"`

An attachment belonging to a different issue — even one in the same workspace — is a 404 through this issue’s URL, not a 403.

Status	Condition
`200`	The file
`404`	Not found on this issue, or its stored bytes are missing (for example after a metadata-only restore)
`503`	This instance has no storage provider configured

Delete an attachment

DELETE /api/v1/crews/{crewId}/issues/{identifier}/attachments/{attachmentId}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request Body: none. The file is addressed by the attachmentId path parameter; workspace_id is the only query parameter. Response: 200 OK with {"status": "ok"} Hard delete of the record, and of the stored bytes — but the bytes only when no other issue, comment or chat in this workspace still references them. Removing a file from one issue never removes it from another that carries the same file.

Status	Condition
`200`	Removed
`403`	Caller lacks the MANAGER floor
`404`	Not found on this issue

Labels

Labels are workspace-scoped and can be attached to any issue.

List Labels

GET /api/v1/labels?workspace_id={workspaceId}

Request: workspace_id is the required workspace query parameter. No request body. Response: 200 OK

[
  {
    "id": "label_abc",
    "name": "bug",
    "color": "#ef4444",
    "label_group": null
  }
]

Create Label

POST /api/v1/labels?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request: workspace_id selects the workspace. The JSON body requires name and color; label_group is optional.

Field	Type	Required	Description
`name`	string	Yes	Label name
`color`	string	Yes	Color hex code
`label_group`	string	No	Grouping category

Response: 201 Created

Update Label

PATCH /api/v1/labels/{labelId}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role Request: labelId is required, workspace_id selects the workspace, and the JSON body may contain name, color, and/or label_group. All fields optional: name, color, label_group. Response: 200 OK — updated label.

Status	Condition
`400`	No fields to update
`404`	Label not found

Delete Label

DELETE /api/v1/labels/{labelId}?workspace_id={workspaceId}

Auth: OWNER or ADMIN role Request: labelId is a required path parameter and workspace_id selects the workspace. No request body. Response: 204 No Content

Status	Condition
`404`	Label not found

Projects

Projects group related issues together with tracking metadata.

List Projects

GET /api/v1/projects?workspace_id={workspaceId}

Query Parameters:

Parameter	Type	Description
`status`	string	Comma-separated status filter
`sort`	string	Sort column: `name` (default), `created_at`, `updated_at`

Response: 200 OK

[
  {
    "id": "proj_abc",
    "workspace_id": "ws_123",
    "name": "Q1 Backend Overhaul",
    "slug": "q1-backend-overhaul",
    "description": "Major backend refactoring",
    "icon": "rocket",
    "color": "blue",
    "status": "started",
    "priority": "high",
    "health": "on_track",
    "lead_type": "user",
    "lead_id": "user_123",
    "lead_name": "John Doe",
    "start_date": "2024-01-01",
    "target_date": "2024-03-31",
    "created_at": "2024-01-01T00:00:00Z",
    "updated_at": "2024-01-15T10:00:00Z",
    "issue_count": 12,
    "done_count": 8,
    "progress": 66
  }
]

Create Project

POST /api/v1/projects?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role

Field	Type	Required	Default	Description
`name`	string	Yes	—	Project name
`description`	string	No	`null`	Description
`icon`	string	No	`null`	Lucide icon name
`color`	string	No	`"blue"`	Palette color
`status`	string	No	`"backlog"`	Project status
`priority`	string	No	`"none"`	Priority level
`lead_type`	string	No	`null`	`"user"` or `"agent"`
`lead_id`	string	No	`null`	Lead person/agent ID
`start_date`	string	No	`null`	Start date
`target_date`	string	No	`null`	Target date

Response: 201 Created

Get Project

GET /api/v1/projects/{projectId}?workspace_id={workspaceId}

Response: 200 OK — project with computed issue_count, done_count, and progress fields.

Update Project

PATCH /api/v1/projects/{projectId}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role All fields optional: name, description, icon, color, status, priority, health, lead_type, lead_id, start_date, target_date. Response: 200 OK — updated project.

Delete Project

DELETE /api/v1/projects/{projectId}?workspace_id={workspaceId}

Auth: OWNER or ADMIN role

Unlinks all issues from the project before deletion.

Response: 204 No Content

Project Stats

GET /api/v1/projects/{projectId}/stats?workspace_id={workspaceId}

Returns breakdown data: counts by status, by assignee, by label, and crew list. Response: 200 OK

{
  "total_issues": 12,
  "completed_issues": 8,
  "by_status": {
    "BACKLOG": 1,
    "TODO": 2,
    "IN_PROGRESS": 1,
    "DONE": 8
  },
  "by_assignee": [
    {
      "agent_id": "agent_abc",
      "agent_name": "Backend Dev",
      "total": 5,
      "completed": 4
    }
  ],
  "by_label": [
    {
      "label_name": "bug",
      "color": "#ef4444",
      "count": 3
    }
  ],
  "crews": ["crew_abc"]
}

Milestones

Milestones belong to projects and expose progress counts for the issues linked to them. All routes are workspace-scoped through the project or milestone.

List Milestones

GET /api/v1/projects/{projectId}/milestones?workspace_id={workspaceId}

Request: projectId is a required path parameter and workspace_id selects the workspace. No request body. Returns 200 OK with an array ordered by position, then creation time. Each item contains id, project_id, name, nullable description and target_date, status, position, issue_count, done_count, created_at, and updated_at. A project outside the workspace returns 404.

Create Milestone

POST /api/v1/projects/{projectId}/milestones?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role. The request requires name; optional fields are description, target_date, and status (default active). The response is 201 Created with the full milestone object and its next position.

Update Milestone

PATCH /api/v1/milestones/{milestoneId}?workspace_id={workspaceId}

Auth: OWNER, ADMIN, or MANAGER role. Any of name, description, target_date, status, and position may be updated; at least one field is required. Returns 200 OK with the updated milestone, or 400 for invalid JSON/no fields and 404 when it is not in the workspace.

Delete Milestone

DELETE /api/v1/milestones/{milestoneId}?workspace_id={workspaceId}

Auth: OWNER or ADMIN role. Returns 204 No Content, or 404 when the milestone is not in the workspace.

Reference

Issue Statuses

Status	Description
`BACKLOG`	Not yet prioritized
`TODO`	Planned for work
`IN_PROGRESS`	Agent is actively working
`REVIEW`	Waiting for human review
`DONE`	Completed and approved
`FAILED`	Agent encountered unresolvable error
`CANCELLED`	Cancelled by user
`DUPLICATE`	Marked as duplicate (no transitions out)

Priority Levels

Value	Description
`none`	No priority set
`low`	Low priority
`medium`	Medium priority
`high`	High priority
`urgent`	Urgent priority

​Endpoints

​Issues CRUD

​List Issues (Workspace)

​Get Issue (Workspace-scoped)

​Create Issue

​Get Issue (Crew-scoped)

​Update Issue

​Delete Issue

​Lifecycle Actions

​Transfer Issue Work

​Set Issue Review Policy

​Start Issue

​Stop Issue

​Review Issue

​Bulk

​Bulk Update

​Sub-issues

​List Sub-issues

​Activity

​List Activity

​List Events

​Get Full Run Result

​Runs

​List Runs

​Outcome

​Sessions

​List Sessions

​List Checkpoints

​Comments

​List Comments

​Create Comment

​Relations

​List Relations

​Create Relation

​Delete Relation

​Code links

​List code links

​Attach a code link

​Refresh a code link

​Delete a code link

​Attachments

​List attachments

​Upload an attachment

​Download an attachment

​Delete an attachment

​Labels

​List Labels

​Create Label

​Update Label

​Delete Label

​Projects

​List Projects

​Create Project

​Get Project

​Update Project

​Delete Project

​Project Stats

​Milestones

​List Milestones

​Create Milestone

​Update Milestone

​Delete Milestone

​Reference

​Issue Statuses

​Priority Levels

Endpoints

Issues CRUD

List Issues (Workspace)

Get Issue (Workspace-scoped)

Create Issue

Get Issue (Crew-scoped)

Update Issue

Delete Issue

Lifecycle Actions

Transfer Issue Work

Set Issue Review Policy

Start Issue

Stop Issue

Review Issue

Bulk

Bulk Update

Sub-issues

List Sub-issues

Activity

List Activity

List Events

Get Full Run Result

Runs

List Runs

Outcome

Sessions

List Sessions

List Checkpoints

Comments

List Comments

Create Comment

Relations

List Relations

Create Relation

Delete Relation

Code links

List code links

Attach a code link

Refresh a code link

Delete a code link

Attachments

List attachments

Upload an attachment

Download an attachment

Delete an attachment

Labels

List Labels

Create Label

Update Label

Delete Label

Projects

List Projects

Create Project

Get Project

Update Project

Delete Project

Project Stats

Milestones

List Milestones

Create Milestone

Update Milestone

Delete Milestone

Reference

Issue Statuses

Priority Levels