Key points
- These routes are documented at contract depth: caller, purpose, and boundary, with no call samples.
- Calling them by hand corrupts run state rather than integrating with the platform.
logs/ingest, the task status route, andfinalizesit under/v1/runs/rather than/v1/internal/, so they look public in a route list while being agent-only.- The runtime-config watch is why a
PUT /v1/system/configtakes effect without restarting services. - The approval pause route is what makes a checkpoint durable: the run becomes a record rather than a held process.
- AI usage records reported here are the source of the numbers in the monitoring AI usage view.
Operations
GET/internal/v1/runtime-config/{service}Service token
Runtime configuration a platform service pulls at startup.
Notes
Called by aaa, dispatcher, git-bot, and the agent as they start. Not a public API: the shape follows whatever those services need and changes with them.
Side effects
- None. The caller reads its own configuration.
Proven by
services/nopsai/runtime_config_api.go
GET/internal/v1/runtime-config/{service}/watchService token
Long-lived watch that pushes runtime configuration changes to a service.
Notes
This is why a configuration change through PUT /v1/system/config takes effect without restarting services. Not a public API.
Streaming
text/event-stream - Long-lived connection; the service receives a message when its configuration changes.
Side effects
- Holds an open connection for the lifetime of the calling service.
Proven by
services/nopsai/runtime_config_api.go
POST/v1/internal/config/syncService token
Internal trigger for a configuration sync.
Notes
Used by platform components that need to force a sync. Operators should use POST /v1/system/config/sync instead, which is authorized and audited as an operator action.
Side effects
- Starts a configuration sync.
Proven by
services/nopsai/config_sync.go
GET/v1/internal/dispatcher/routingAuthenticated
Routing table the dispatcher uses to match work to runner scopes.
Notes
Read by the dispatcher. The operator-facing equivalents are GET /v1/system/dispatcher for the live fleet and GET /v1/system/dispatcher/scopes for advertised scopes.
Side effects
- None.
Proven by
services/nopsai/routes.goservices/nopsai/aaa_helpers.go
GET/v1/internal/git-bot/bootstrapService token
Bootstrap configuration git-bot needs to start handling provider webhooks.
Notes
Called by git-bot only. It carries GitHub App material, which is why it is service-gated rather than authorized.
Side effects
- None.
Proven by
services/nopsai/routes.godoc/git-apps.md
GET/v1/internal/git-bot/installationsService token
GitHub App installations git-bot may act for.
Notes
Called by git-bot when routing a delivery to the right installation. The operator-facing list is GET /v1/git-apps/github/installations.
Side effects
- None.
Proven by
services/nopsai/routes.godoc/git-apps.md
POST/v1/internal/runs/{runID}/ai-usageService token
Records the token usage of one LLM call against a run.
Notes
Reported by the per-run agent as it works. This is where the numbers in GET /v1/monitoring/ai-usage come from.
Side effects
- Appends an AI usage record to the run.
Proven by
services/nopsai/ai_usage_handlers.go
POST/v1/internal/runs/{runID}/approvals/pauseService token
Pauses a run at an approval checkpoint and releases its runner capacity.
Notes
Called by the agent when it reaches an approval step. This is the mechanism that makes a checkpoint durable: the run becomes a record rather than a held process.
Side effects
- Creates the pending approval and releases the runner slot the run held.
Proven by
services/nopsai/approval_handlers.go
GET/v1/internal/runs/{runID}/checkpoints/{checkpointID}Service token
Reads the checkpoint state an agent needs to resume after an approval.
Notes
Called by the agent when a paused run is picked up again, possibly by a different runner than the one that paused it.
Side effects
- None.
Proven by
services/nopsai/approval_handlers.go
GET/v1/internal/runs/{runID}/policy-revisionService token
The governance and knowledge policy revision pinned to a run.
Notes
Called by the agent so a long run keeps evaluating against the policy it started with rather than one edited mid-flight.
Side effects
- None.
Proven by
services/nopsai/routes.go
POST/v1/internal/runs/{runID}/steps/{stepName}/tasks/{taskName}/outputsService token
Records the runtime outputs a task produced.
Notes
Called by the agent after a task writes files under /nopsai/outputs. This is what makes $steps.<step>.<task>.outputs.<NAME> resolvable downstream.
Side effects
- Stores the output values, masking any declared sensitive.
Proven by
services/agent/internal/app/runtime_outputs.go
POST/v1/internal/runs/{runID}/task-outputs/resolveService token
Resolves outputs published by a synchronous child pipeline run.
Notes
Called by a parent run’s agent to read a child run’s outputs. It is the mechanism behind sync: true on a pipeline: include.
Side effects
- None.
Proven by
services/agent/nopsai_client.go
POST/v1/runs/{runID}/logs/ingestService token
Streams run log lines from the agent into durable storage.
Notes
Agent-only despite sitting under /v1/runs/ rather than /v1/internal/. Read logs with GET /v1/runs/{runID}/logs; writing them by hand corrupts a run’s record.
Side effects
- Appends log lines to the run, applying secret redaction on the way in.
Proven by
services/nopsai/run_internal_handlers.go
POST/v1/runs/{runID}/steps/{stepName}/tasks/{taskName}Service token
Reports a task’s status transition.
Notes
Agent-only, and the source of the per-step and per-task state shown in run detail. It sits under the public run path but is not part of the public surface.
Side effects
- Advances the run graph and may complete or fail the run.
Proven by
services/nopsai/run_handlers.go
POST/v1/runs/{runID}/finalizeService token
Closes a run and starts final output generation.
Notes
Agent-only. It is what moves a run to its terminal status and queues the deliverables; calling it by hand ends a run that has not finished.
Side effects
- Sets the terminal run status and queues final output generation.
Proven by
services/nopsai/run_handlers.go
How it works
Every route here has a public counterpart to reach for instead. Read logs with GET /v1/runs/{runID}/logs, not the ingest route. Sync configuration with POST /v1/system/config/sync, not the internal trigger. Inspect the fleet with GET /v1/system/dispatcher, not the routing table. The internal form exists for a component that already holds a service token and a specific job.
The three routes under /v1/runs/ are the ones worth knowing about, because a route list makes them look like part of the public API. They advance the run graph: ingesting logs, transitioning a task, and finalising a run. Calling any of them by hand ends up with a run whose recorded state does not match what happened.
This page exists so the surface is complete rather than to invite use. If an integration seems to need one of these routes, the public equivalent is almost always the right answer.
Implementation evidence
services/nopsai/run_internal_handlers.goAgent log ingest and run status reporting.
services/nopsai/runtime_config_api.goRuntime configuration pull and watch.
services/nopsai/aaa_helpers.goWhich internal paths are authenticated rather than authorized.

