Providers

Providers are the upstream AI services that the gateway routes requests to. The Providers page lets you register provider credentials, monitor health, and test connectivity.

This page is the deployment catalogue. There is exactly one provider record per slug, adding or editing one requires deployment scope, and every organization and department reads the same list. What one organization or department changes about an entry — its credential, its rate limits, whether it may use it at all — is a separate record; see Scope Overrides.

Provider List

The main view lists every provider in the catalogue in a table, showing its name, type, credential state, enabled state and health. Click a row to open its detail page.

If no providers are configured, an empty state prompts you to add your first one.

Adding a Provider

Click Add Provider to open the creation modal. Fill in the following fields:

Field	Required	Description
Name	Yes	A display name (e.g. “Production OpenAI”)
Type	Yes	The provider type — see supported types below
API Key	Yes	Your provider API key (stored encrypted)
Base URL	No	Custom endpoint URL; leave blank for the provider’s default

Supported Provider Types

The creation form’s Type dropdown offers a curated set of provider slugs, including:

• Frontier / cloud: openai, anthropic, google-gemini, azure-openai, xai, mistral, cohere, deepseek, moonshot, zhipu, dashscope
• Inference platforms: groq, together-ai, perplexity, fireworks, replicate, ai21, huggingface, cerebras, sambanova, deepinfra, cloudflare, lambda-labs
• Serverless open-model clouds: novita, siliconflow, nebius, baseten, hyperbolic, nvidia-nim
• Hyperscaler: bedrock, bedrock-anthropic (Claude), vertex, vertex-anthropic (Claude); meta: openrouter, minimax
• Embeddings / rerank / speech: jina, voyage, deepgram, cartesia
• Media: stability, comfyui, elevenlabs, assemblyai, whisper-local
• Self-hosted: ollama, vllm, lmstudio, localai, llamacpp
• Custom: custom-openai (OpenAI-compatible) and custom-anthropic (Anthropic-compatible) for non-standard endpoints

The gateway ships 49 provider adapters in total, and every one is selectable from the Type dropdown. For an endpoint not backed by a dedicated adapter, use the closest Custom (OpenAI-compatible / Anthropic-compatible) type with the appropriate base URL.

Provider Detail Page

The detail page opens with a health card, and below it two tabs.

Health

Shown above the tabs rather than inside them, because it is the thing you came to check:

• State — healthy, degraded, unhealthy, or unknown
• Last check — when the health worker last probed it, or “Never checked”
• Round-trip — how long that probe took
• Uptime — the proportion of recent checks that succeeded

If the provider has ever recorded a failure, the most recent one is shown and labelled as current or historic. Nothing clears a recorded error on a successful check, so an error sitting beside a healthy state is history rather than a live fault — saying which is the point of the label.

Settings tab

Edit the provider’s name, slug, base URL, authentication (key, header name, header prefix), priority, enabled state, and per-provider rate limits — requests per minute and per day, tokens per minute and per day. This tab also exposes free-tier configuration — enable a free allowance and set requests/day, tokens/day, and the reset cadence (a UTC cron expression) so free-tier-first routing can track remaining quota. Changes are saved via PUT /api/admin/providers/:id.

Priority orders this list and nothing else. Routing preference is set per rule on the Routing page; a provider’s own priority is not read when a chain is built.

Models tab

Lists all models registered under this provider, showing each model’s ID, capabilities (e.g. chat, embeddings, vision), and whether it is Reachable or Off. You can enable/disable all models in bulk (via POST /api/admin/models/bulk-update) and toggle each model’s free-tier eligibility here. Models are otherwise managed on the dedicated Models page.

Testing Connectivity

Each row in the pool has a Test action, and the detail page has a Test Connection control. Testing sends a lightweight probe request through the gateway to the provider and returns:

• success (boolean)
• latency (milliseconds)
• error (string, if the test failed)

Use this after adding a provider or rotating API keys to verify the connection before routing live traffic.

Enabled, and health

enabled is a boolean — the toggle reads Enabled on the form and In service on the detail page. There is no lifecycle beyond those two values.

State	Meaning
Enabled	Included in routing chains as soon as a rule or a request names it.
Disabled	Saved, but filtered out of every chain. Nothing reaches it until you enable it.

Disable a provider to remove it from routing without deleting its configuration — the credential and every other setting survive.

healthy / degraded / unhealthy / unknown are health values decided by the health worker (see the health card above the tabs), not states you set. An unhealthy provider is demoted in the chain, not removed from it.