Management API
The management UI uses these endpoints itself. Use them directly when scripting Group and key management.
Authentication §
Protected endpoints under /api use Bearer authentication:
Authorization: Bearer your AUTH_KEY or AccessKey AUTH_KEY— grants administrative access to read and write configuration and perform sensitive operations such as Reveal- AccessKey — may only read its scoped home page, models, usage, and redacted request logs; it cannot change configuration or view upstream credentials
Use AUTH_KEY for write operations and route inspection.
Response Convention §
Responses use one structure; code distinguishes success from failure:
{
"code": 0,
"message": "success",
"data": { ... }
}{
"code": "Error identifier" ,
"message": "Human-readable instructions"
}On success, code is the number 0; on failure, it is a string identifier—check the type.
Main resources §
| Path | Purpose |
|---|---|
| /api/groups | CRUD for Groups |
| /api/groups/{id}/credentials | Credential management, includes batch import, viewing actual values, downloading |
| /api/access-keys | AccessKey, including quota and view real value |
| /api/models | Model information |
| /api/model-prices | Model pricing, including syncing and resetting |
| /api/logs | Request log query |
| /api/usage | Usage and cost statistics |
| /api/health | Health status |
| /api/settings | Runtime settings |
| /api/route/inspect | Route checking |
Endpoint parameters are not listed individually because the API is still evolving and hard-coded documentation goes stale. The most reliable approach is to open the browser developer tools. Perform the operation once in the management UI and inspect the request it sends; those parameters match the current version.
A few examples §
curl http://127.0.0.1:3001/api/groups \
-H "Authorization: Bearer $AUTH_KEY"curl http://127.0.0.1:3001/api/health \
-H "Authorization: Bearer $AUTH_KEY"curl -X POST http://127.0.0.1:3001/api/route/inspect \ -H "Authorization: Bearer $AUTH_KEY" \ -H "Content-Type: application/json" \ -d '{"protocol":"openai-completions","external_model":"gpt-4o","access_key_id":1}'
access_key_id is the numeric ID of the AccessKey in the management UI. Route inspection only evaluates candidates under the current configuration; it does not send a real upstream request.
Notes §
The management API can read the real values of all channel credentials (endpoints such as /reveal do this). A leaked AUTH_KEY exposes every upstream key.
The source must be restricted; see Security and production for configuration.
- Do not hardcode AUTH_KEY in the script — Use environment variables or a secrets manager.
- Interfaces will adjust with versions — Re-run validation after upgrading an automation script.
- Pay attention to idempotency during batch operations — For example, duplicate credentials in a repeated batch import are skipped automatically, but check before writing.