Interfaces
GraphQL
GraphQL is available for promoted DigitalStack capabilities, including Context Engine, scope-enforced for API keys and delegated OAuth tokens.
Available for promoted capabilities, including Context Engine
API-key and OAuth calls are scope-enforced
Every query and mutation requires the same scope REST requires for the equivalent action; an unrecognized field is denied by default. Session-authenticated (in-product) calls are unaffected. Schema introspection is available in development but denied for API-key/OAuth callers in production.
Scopes grant permission to use an API capability. They do not grant visibility to every resource in the account. GraphQL results remain bounded by the authenticated principal's account, user, project, workspace, team, and engagement visibility, matching REST behavior.
| Operation | Required scope |
|---|---|
| Query.document / Query.documents | documents:read |
| Query.search | search:read |
| Query.workflowState / Document.workflow | workflow:read |
| Query.analytics | analytics:read |
| Mutation.transitionWorkflow | workflow:write |
| Mutation.addComment / .resolveCommentThread / .createSuggestion / Document.comments | comments:write / comments:read |
| Document.content | content:read |
| Query.notifications / Mutation.markNotificationRead | session only — no API-key scope yet |
| Query.timeEntries / Query.timeEntry | time:read_self |
| Mutation.createTimeEntry | time:write_self |
| Mutation.updateTimeEntry / Mutation.voidTimeEntry | time:write_self |
| Query.timeTimer | time:read_self |
| Mutation.*TimeTimer | time:write_self |
| Query.myTimeDay | time:read_self |
| Mutation.draftTimeDay / .applyTimeDraft | time:write_self |
| Mutation.submitTimeDay / .recallTimeDay | time:submit_self |
| Query.timeApprovalQueue | time:read_team |
| Mutation.decideTimeApproval | time:approve_team |
| Query.timeImports / Mutation.createTimeImport | time:import |
| Query.timeReconciliationFindings / related mutations | time:reconcile |
| Query.workItems / .workItem / .workItemTransitions / .workItemBoard | work-items:read |
| Query.workItemEnhancement* | work-item-enhance:read |
| Mutation.createWorkItemEnhancementRun / .runWorkItemEnhancementAction | work-item-enhance:run |
| Mutation.applyWorkItemEnhancementDrafts | work-item-enhance:apply |
| Query.myDay / Mutation.recordMyDayAttentionItemAction | agent:read |
| Query.sprintPlanning / Mutation.generateSprintPlanningSuggestions | sprints:read |
| Query.contextQuery / Query.contextEngine* | context-engine:read |
What it covers today
Documents
Fetch a document or a paginated list, with content, metadata, and status.
Workflow
Read workflow state and transition a document through its workflow.
Comments & suggestions
Read comment threads, add comments, resolve threads, and create suggestions.
Search & analytics
Run search queries and read document/workspace analytics.
Time management
Entries, timer, account-local day view, proposal/apply, submission/recall, eligible approvals, Timely imports, and reconciliation.
Work Items & Board
Canonical work-item lists, detail, transition history, and read-only board projections.
Work Item Enhance
Proposal-first enhancement runs, drafts, artifacts, action execution, and explicit apply.
Today & My Work
Typed daily-focus packages and confirmed attention-item actions that emit webhook lifecycle facts.
Sprints & Planning
Sprint-planning context, readiness, and proposal-only planning suggestions.
Context Engine
Evidence-backed queries plus governed package, evidence, provenance, freshness, coverage, and provider reads.
Status by domain
Query and mutate documents, workflow state, comments, suggestions, and search — the same domain the REST document endpoints already cover.
• A real, auth-wired GraphQL server exists (schema, resolvers, depth/complexity limits, session and API-key auth), but there is no published, versioned public schema reference yet, and it has not been broadly announced as a supported integration path.
Read and mutate self-scoped entries and the canonical timer; inspect and draft days; apply reviewed proposals; submit or recall time; decide eligible approvals; and administer imports and reconciliation through the same Work-domain services used by REST.
Create proposal-first enhancement runs, run named actions, list/retrieve runs, filter drafts/artifacts, and apply selected drafts through the same Execute-domain service used by REST.
Read operation context and apply named work-item commands for comments, transitions, assignment, dates, estimates, labels, dependencies, blockers, and focus through the same Execute command service used by REST.
Read canonical Execute work-item lists, single-item detail, transition history, and read-only board projections through the same Work Items service used by REST.
Read typed daily-focus packages and record confirmed attention-item actions through the same Context Package and webhook-outbox services used by REST.
Read advisory project-health snapshots and acknowledge health alerts through the same Agent Project Health and confirmed-command services used by REST.
Read sprint-planning context and readiness, and generate proposal-only planning suggestions through the same Execute planning services used by REST.
List, retrieve, create, update, archive, and administer project membership/settings through the same Projects service used by REST. Customer and Engagement nodes expose the ownership hierarchy read-only, with lazy customer/engagement/project traversal edges.
Read delivery timelines, milestones, workstreams, and run explicit milestone status/date/progress commands through the same Delivery services used by REST.
Run portfolio queries, target a project, or compose the visible projects linked to an engagement with a typed subjectRef; customer identity resolution remains coverage-honest. Package and provider reads support shared project/engagement filters.
Read estimates, immutable versions, version diffs, and change proposals; draft proposal-only changes through the same vSOW and estimate services used by REST. Baseline execution remains intentionally REST-only.
Querying broader sprint intelligence, risk, resource, or portfolio data through GraphQL.
• The real GraphQL schema covers documents, Time Management, Work Items & Board, Work Item Operations, Work Item Enhance, Today & My Work, Project Health, Projects & Engagements, Milestones & Workstreams, Sprints & Planning, Context Engine, and Estimates, Effort & Scope. Sprint intelligence, risk, resource, and portfolio types do not exist yet.
Restricting what a GraphQL-authenticated API key can do based on its granted scopes, the way REST does per endpoint.
• Every root query/mutation, plus the sensitive Document.content/comments/workflow fields, requires the same scope REST requires for the equivalent action, and unclassified fields are denied by default. Two operations — Query.notifications and Mutation.markNotificationRead — have no evidence-backed scope defined yet and remain session-only; API-key/OAuth callers are denied those two rather than silently granted them.
Build project-delivery integrations with REST or MCP
GraphQL is available for the promoted capability slices; broader project-delivery capability data is still REST/MCP-first.