REST API

Every module of the workspace over /api/v1, with the same permissions as the screens and an OpenAPI 3.1 contract to generate clients from.

Access

API access is part of the plan. Once enabled, the platform operator hands over the workspace's key; it acts as a service account to which the workspace administrator gives a role with only the permissions the integration needs. People can also use the API with their own session.

  • Calls go to the workspace's own address and carry the key in the Authorization header.
  • Another workspace's resources answer exactly as if they did not exist.
  • The live contract is available, authenticated, at /api/v1/openapi.json. 
curl -H "Authorization: Bearer $DEVGOB_API_KEY" \
  "https://acme.portaldevops.com/api/v1/workitems?project_id=$PROJECT&limit=50"

What it covers

  • Projects, teams, sprints, work items, comments, attachments, links, time and history.
  • Backlog, boards, support and the workflow of every type.
  • Validations: the checklist, its responsibles, scores, templates and its PDF report.
  • Deployments and Data Changes: phases, committee, tests, specification, authorizations, the consolidated report and the evidence package.
  • Business Case authorizations, reports, notifications, roles and settings.
  • GitHub, GitLab and Azure DevOps: connections, repositories and the links of each item.

Conventions

  • Lists are cursor-paginated: 50 per page by default, up to 200, and next_cursor leads to the next page.
  • Every request body is validated strictly: an unknown field is rejected, never ignored.
  • Errors share one format with a stable code; dates are UTC in ISO 8601.
  • Documents such as PDFs and evidence packages are never cached and every download is audited.

Next steps

Roles and permissions Who can do what, decided by role rather than by person. Security and data isolation How one workspace's information stays that workspace's information. Administration Everything a workspace administrator controls.