Skip to main content

API Reference

The Hill90 API provides endpoints for agent management, model access configuration, agent knowledge, user profiles, and platform health checks.

Base URL

https://api.hill90.com

Authentication

Most endpoints require a valid JWT bearer token issued by Keycloak. Include it in the Authorization header:
Authorization: Bearer YOUR_JWT_TOKEN
See Authentication for details on obtaining tokens.

Endpoint Groups

Health

EndpointAuthDescription
GET /healthNoneService health check

User

EndpointAuthDescription
GET /meBearerGet current user JWT claims
GET /profileBearerGet user profile
PATCH /profileBearerUpdate display name
POST /profile/avatarBearerUpload avatar image
GET /profile/avatarBearerGet avatar image
DELETE /profile/avatarBearerDelete avatar
POST /profile/passwordBearerChange password (not yet implemented)

Agents

EndpointAuthDescription
GET /agentsBearerList agents
POST /agentsBearerCreate agent
GET /agents/{id}BearerGet agent detail
PUT /agents/{id}BearerUpdate agent
DELETE /agents/{id}Bearer (admin)Delete agent
POST /agents/{id}/startBearer (admin)Start agent container
POST /agents/{id}/stopBearer (admin)Stop agent container
GET /agents/{id}/statusBearerGet agent status
GET /agents/{id}/logsBearer (admin)Get agent logs (JSON or SSE stream)

Knowledge

Browse and search agent knowledge entries. Agents write knowledge; humans browse it here.
EndpointAuthDescription
GET /knowledge/agentsBearerList agents with knowledge stats
GET /knowledge/entriesBearerList entries for an agent
GET /knowledge/entries/{agentId}/{path}BearerRead a specific entry
GET /knowledge/searchBearerFull-text search across entries
See Knowledge API for details on access scoping.

Provider Connections

Manage your own API key connections to LLM providers. Keys are encrypted at rest and never returned in responses.
EndpointAuthDescription
GET /provider-connectionsBearerList your provider connections
POST /provider-connectionsBearerCreate a provider connection
PUT /provider-connections/{id}BearerUpdate a provider connection
DELETE /provider-connections/{id}BearerDelete a provider connection
POST /provider-connections/{id}/validateBearerTest if a provider key is valid

User Models

Define models that reference your provider connections. Model names must not conflict with platform models.
EndpointAuthDescription
GET /user-modelsBearerList your models
POST /user-modelsBearerCreate a user model
PUT /user-models/{id}BearerUpdate a user model
DELETE /user-models/{id}BearerDelete a user model

Model Policies

Control which models an agent can access, with optional rate limits and token budgets. Users can create and manage their own policies; admins can also create platform-wide policies.
EndpointAuthDescription
GET /model-policiesBearerList policies (own + platform)
POST /model-policiesBearerCreate a model policy
GET /model-policies/{id}BearerGet policy detail
PUT /model-policies/{id}BearerUpdate a policy
DELETE /model-policies/{id}BearerDelete a policy

Usage

Query model usage statistics with filtering and grouping options. Users see their own usage; admins see all.
EndpointAuthDescription
GET /usageBearerQuery usage (filter by agent, model, date; group by agent, model, day)

Model Naming & Resolution

When an agent makes an inference request, the model name goes through a resolution chain:
  1. Requested model — the model name in the HTTP request body (body.model). May be an alias or a direct model name.
  2. Resolved model — after alias resolution. If the requested name is an alias defined in the agent’s model policy, it resolves to the target model name. Otherwise, the requested name passes through unchanged. Alias resolution is single-pass (no recursion).
  3. Provider model ID — after BYOK resolution. If the resolved model matches a user model backed by a provider connection, the provider-prefixed model ID (e.g., openai/gpt-4o-mini) is sent to the provider. This is the actual model identifier used for inference.
Usage records store all three values:
  • model_name — the resolved model name (step 2)
  • requested_model — the original request name (step 1, may equal model_name if no alias was used)
  • provider_model_id — the provider-side identifier (step 3, null for denial paths and pre-BYOK errors)
Model aliases are defined per policy via model_aliases (a JSON object mapping alias to real model name). Alias targets must be in the policy’s allowed_models list.

Auto-Generated Documentation

The endpoint pages in this section are auto-generated from the OpenAPI specification. Each endpoint page includes request/response schemas, parameter details, and example payloads.