CRcraft
Work Items and OKRs

POST /item

Changed on

Create a work item

Request

  • Base URL
    https://api.craft.io
  • URL
    https://api.craft.io/item
  • Auth
    API key in header x-api-key

Request body

typestring required
workspaceIdstring
portfolioIdstring
titlestring required
descriptionstring nullable
storyPointsnumber double nullable
initiativeIdstring nullable
valuenumber double nullable
effortnumber double nullable
kanostring nullable
estimatedHoursnumber double nullable
labelsstring[]
actualStartDatestring date-time nullable
actualEndDatestring date-time nullable
assigneeunknown

Example request

{
  "assignee": {
    "team": "Team A",
    "user": "a@b.com"
  }
}

Response

The item’s metadata

idstring nullable
typestring

Workspace-facing type label — the workspace's custom terminology (e.g. "Subtask").

typeKeystring

Canonical type name (requirement/feature/idea/task/bug/epic/product/story/…) — the value the type filter and write endpoints accept, independent of workspace terminology.

workspaceIdstring
portfolioIdstring
shortIdstring
titlestring
descriptionstring nullable
creationTimestring date-time
updateTimestring date-time

When the item last changed in a way a person can see — the date of its latest activity-log entry. Machine touches that change nothing a reader would notice (integration sync passes, aggregation and inheritance recalculations, bulk maintenance) do not move it. Items whose last change predates this being recorded report the raw row-update date instead.

storyPointsnumber double
initiativeIdstring nullable
valuenumber double
effortnumber double
kanostring
estimatedHoursnumber double
labelsstring[]
actualStartDatestring date-time nullable
actualEndDatestring date-time nullable
webUrlstring

Canonical Craft.io app URL for this item. Computed in PublishService.

warningsstring[]

Non-fatal advisories about how THIS request was interpreted. Present only on a write, and only when there was something to say — never on a read, so it cannot bloat a list.

Today it carries one case: the id was a shortId that names a feedback item as well as a work item, and the write went to the work item. Both entities keep their own KEY-N sequence, so that collision is ordinary (40,613 shortIds across 699 accounts on pp4) and the resolution is deliberate — but a caller who meant the feedback item deserves to be told, rather than discovering it later.

commentCountnumber double

Changes

  • 6009bb084cb5Revision changes
    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

  • 0ded52245043Revision changes
    • info

      added the optional property to the response with the status