Capabilities
Work Items & Board
Read canonical Execute work items, transition history, and board projections without exposing legacy tickets or making board coordinates authoritative.
Interfaces
Read-only REST endpoints are available for canonical work items, transition history, and board projections.
MCP can now read canonical work-item lists, board projections, single-item detail, and transition history through the same governed public API surface.
GraphQL can read canonical work-item lists, single-item detail with children/transitions, transition history, and read-only board projections through the same Work Items service as REST.
Webhooks emit minimal lifecycle events when canonical Execute work items are created, edited, or transitioned. Board projections remain read-only and do not emit.
Required scopes
work-items:readAPI key scoperequiredExamples
List work items — view in REST API reference
curl -X GET "https://www.digitalstack360.com/api/v1/work-items" \
-H "Authorization: Bearer $DS_API_KEY"Get work-item board projection — view in REST API reference
curl -X GET "https://www.digitalstack360.com/api/v1/work-items/board" \
-H "Authorization: Bearer $DS_API_KEY"Retrieve a work item — view in REST API reference
curl -X GET "https://www.digitalstack360.com/api/v1/work-items/EA-1650?project_id=proj_01k2..." \
-H "Authorization: Bearer $DS_API_KEY"List work-item transitions — view in REST API reference
curl -X GET "https://www.digitalstack360.com/api/v1/work-items/work_01k2.../transitions" \
-H "Authorization: Bearer $DS_API_KEY"GraphQL examples
work-items:readRead one canonical work item, its children, and recent transitions through the governed Work Items graph.
query WorkItemDetail($id: ID!) {
workItem(id: $id) {
id
key
title
kind
statusBucket
flowStateId
sprintId
assigneeUserId
parentId
children {
id
key
title
statusBucket
}
recentTransitions(first: 10) {
id
fromBucket
toBucket
actorUserId
at
}
}
}work-items:readRead board columns as a projection over canonical status, not as mutable board coordinates.
query WorkItemBoard($teamId: ID!, $sprintId: ID) {
workItemBoard(teamId: $teamId, sprintId: $sprintId) {
projection {
sourceOfTruth
coordinatePolicy
flowStateLayer
}
columns {
id
title
statusBucket
items {
id
key
title
assigneeUserId
}
}
}
}Webhook emits
work_item.createdAvailableA canonical Execute work item was created.
Resource: work_item
work_item_idteam_idsprint_idkindstatus_bucketcreated_atwork_item.updatedAvailableCanonical editable work-item fields changed. Changed values are fetched through the authorized API.
Resource: work_item
work_item_idchanged_fieldsupdated_atwork_item.status_changedAvailableA canonical flow-state transition changed the work item status bucket.
Resource: work_item
work_item_idfrom_state_idto_state_idfrom_bucketto_buckettransition_idoccurred_atAll webhook events use the shared v1 envelope, signed delivery, and minimal payload rule. Fetch by resource id for expanded data.
System boundaries
Systems commonly integrated with this capability. Each row states the boundary and its native status; it does not transfer canonical authority to the connected system.
DigitalStack owns
- • Canonical Execute work-item identity, hierarchy, status bucket, and transition history
- • Read-only board projections derived from execute_work_item.status_bucket
- • DigitalStack-native visibility and scope checks for the resolved workspace
Source systems own
- • Legacy ticket records until explicitly bridged into canonical Execute work items
- • Provider-native issue semantics from Jira, GitHub, Azure DevOps, Linear, and similar systems
- • External board placement, ranking, and workflow rules until governed mapping exists
Typical integration patterns
DigitalStack ExecuteJiraGitHub / Azure DevOps / Linear