Router management API
The router management API provides health, classification, configuration,
storage, cache, compression, and replay operations. It listens on port 8080
by default and the local stack binds it to 127.0.0.1.
For model traffic, use the configured Envoy listener described in Router API.
Start with the live schema
The running router generates its endpoint discovery and OpenAPI document from the routes it has registered. Use these pages for exact request and response fields:
| Path | Purpose |
|---|---|
GET /api/v1 | Endpoint discovery |
GET /openapi.json | OpenAPI 3.0 document |
GET /docs | Interactive Swagger UI |
This page groups the API by user task. The live OpenAPI document is the field-level source of truth for the version you are running.
curl -sS http://localhost:8080/health
curl -sS http://localhost:8080/openapi.json
Access and authentication
The local CLI keeps the management port on loopback. For a remote router, prefer a private network or an SSH tunnel instead of publishing the port:
ssh -N -L 8080:127.0.0.1:8080 router-host
Management authentication is disabled unless configured. To require bearer
tokens, set global.services.management_api.auth.mode: bearer and define roles
and token sources in the management API configuration. Then send:
Authorization: Bearer <token>
GET /health remains public. Other routes enforce their assigned permission
when bearer authentication is enabled. Configuration and replay responses can
also redact sensitive fields unless the principal has the corresponding detail
permission.
Health and discovery
| Method | Path | Use |
|---|---|---|
GET | /health | Process liveness |
GET | /ready | Whether startup has completed |
GET | /startup-status | Startup and model-download progress |
GET | /api/v1 | Registered endpoint discovery |
GET | /openapi.json | Generated OpenAPI schema |
GET | /docs | Swagger UI |
Use /health for liveness and /ready for readiness. During model download or
runtime preparation, a process can be healthy while /ready still returns
503.
Inspect signals without an inference call
The classification endpoints are useful when tuning signals or diagnosing why a decision did not match. They do not call a generation backend.
curl -sS http://localhost:8080/api/v1/classify/intent \
-H 'Content-Type: application/json' \
-d '{"text":"Write a Python function that merges two sorted lists."}'
| Method | Path | Use |
|---|---|---|
POST | /api/v1/classify/intent | Evaluate intent/domain routing |
POST | /api/v1/classify/pii | Detect configured PII types |
POST | /api/v1/classify/security | Evaluate jailbreak and security classification |
POST | /api/v1/classify/fact-check | Decide whether text needs fact checking |
POST | /api/v1/classify/user-feedback | Classify user feedback |
POST | /api/v1/classify/combined | Run intent, PII, and security classification |
POST | /api/v1/classify/batch | Run a selected classifier over a batch |
POST | /api/v1/eval | Evaluate all configured signals |
POST | /api/v1/nli | Evaluate a premise/hypothesis pair |
POST | /api/v1/embeddings | Generate configured text or image embeddings |
POST | /api/v1/similarity | Compare a text pair |
POST | /api/v1/similarity/batch | Run batch similarity matching |
Names, scores, and matched rules depend on the active recipe. Use the live schema for each endpoint's supported input forms.
Inspect models and metrics
| Method | Path | Use |
|---|---|---|
GET | /info/models | Loaded model inventory |
GET | /info/classifier | Classifier configuration and status |
GET | /api/v1/embeddings/models | Loaded embedding models |
GET | /v1/models | OpenAI-compatible model list |
GET | /metrics/classification | Classification counters and timing |
Secrets in classifier information are redacted unless the caller has
secret_view.
Read and change router configuration
Read the current canonical document and its ETag before making a change:
curl -i http://localhost:8080/config/router \
-H "Authorization: Bearer ${VSR_MGMT_TOKEN}"
| Method | Path | Use |
|---|---|---|
GET | /config/router | Read the active canonical configuration |
POST | /config/router/validate | Validate and normalize without writing |
PATCH | /config/router | Merge, validate, persist, and hot-reload an update |
PUT | /config/router | Replace, validate, persist, and hot-reload the document |
GET | /config/router/versions | List configuration backups |
POST | /config/router/rollback | Restore a backup |
GET | /config/hash | Compare persisted, generated, and active hashes |
Recipe operations use the same canonical document:
| Method | Path | Use |
|---|---|---|
GET | /config/router/recipes | List default and named recipes and their entrypoints |
POST | /config/router/recipes/validate | Validate a recipe mutation without applying it |
GET | /config/router/recipes/{name} | Read one recipe |
PUT | /config/router/recipes/{name} | Create or replace one recipe |
DELETE | /config/router/recipes/{name} | Delete an unreferenced named recipe |
Recipe PUT and DELETE require If-Match. Config mutations validate before
writing, create a backup, and trigger reload; a successful HTTP response does
not mean upstream model backends themselves are healthy. Check /ready and
send a representative request after a change.
Manage knowledge bases and stored data
Knowledge-base configuration:
| Method | Path | Use |
|---|---|---|
GET, POST | /config/kbs | List or create managed knowledge bases |
GET, PUT, DELETE | /config/kbs/{name} | Read, update, or delete one knowledge base |
GET | /config/kbs/{name}/map/metadata | Read generated map metadata |
GET | /config/kbs/{name}/map/data.ndjson | Stream map data as NDJSON |
OpenAI-compatible storage and router memory:
| Resource | Base path | Operations |
|---|---|---|
| Long-term memory | /v1/memory | List and delete by scope; read or delete by id |
| Vector stores | /v1/vector_stores | Create, list, read, update, delete, and search |
| Vector-store files | /v1/vector_stores/{id}/files | Attach, list, inspect, and detach files |
| Files | /v1/files | Upload, list, inspect, download, and delete |
These routes return 503 when their required service is unavailable. File
upload uses multipart form data and accepts documents (.txt, .md, .json,
.csv, .html) for vector-store ingestion; upload an image (.png, .jpg,
.jpeg, .gif, .webp) with purpose=vision to reference it from a Response
API input_image part by file_id. Consult the live schema for limits and
fields.