DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

REST API

How the API is structured, what authenticates against it, and where the complete route list lives.

ReferenceDeveloperAutomation authorOperator

Key points

  • Every route is versioned under /v1, except the platform probes /healthz, /livez, /version, /metrics, and /favicon.ico.
  • Authenticate with a bearer token: a personal access token, a service account token, or a session token.
  • Every request passes the same chain: request ID, CORS, body limit, logging, recovery, audit, authentication, authorization.
  • /v1/setup/preflight is public by design so a stuck install can be diagnosed without a token. The rest of the setup surface needs one.
  • Routes under /v1/internal/ require an internal service token and are not part of the public surface.
  • The complete route list, grouped by area with access class, is on the REST API index.

Examples

Authenticate and start a runbash
export NOPSAI_URL=https://nopsai.example.com
export NOPSAI_TOKEN=<personal access token>

curl -s "$NOPSAI_URL/v1/auth/me" -H "Authorization: Bearer $NOPSAI_TOKEN"
curl -sX POST "$NOPSAI_URL/v1/run/platform%2Fdeploy-service" \
  -H "Authorization: Bearer $NOPSAI_TOKEN"
Replace before running
  • Create the token under Profile, then Personal access tokens.
Validate a pipeline before saving itbash
curl -sX POST "$NOPSAI_URL/v1/pipelines/validate" \
  -H "Authorization: Bearer $NOPSAI_TOKEN" \
  -H "Content-Type: application/yaml" \
  --data-binary @pipeline.yaml
Result

Validation errors name the exact step, task, or directive at fault.

How it works

Resource routes under /v1/resources/... are handler-authorized: the middleware defers, then the handler resolves the concrete resource and checks owner-level manage access before reading settings, changing visibility, or adding and removing use grants.

List endpoints are authorization-filtered rather than returning everything and hiding it client-side, so an empty list can legitimately mean "you have no access here".

Request bodies are size-limited platform-wide, and login is separately rate-limited.

Implementation evidence

  • services/nopsai/routes.go

    Every registered route and its handler.

  • doc/api.md

    Request and response shapes per area.