Connect Open WebUI to a custom OpenAI-compatible endpoint.

Quick answer: one connection in Admin Settings.

As an admin, open Admin Settings, go to Connections, and under the OpenAI API section click to add a connection. Two fields matter: the URL, set to https://api.apisrouter.com/v1, and the API key. Save, and Open WebUI queries the endpoint's /v1/models listing to populate the model selector; verify with the connection's check control, then pick any catalog id in a new chat. Connections added this way are workspace-wide: every user of your Open WebUI instance sees the models, subject to whatever model-access controls you configure. The same values can ship as environment variables at deploy time instead, OPENAI_API_BASE_URL and OPENAI_API_KEY, which is the cleaner path when the instance is provisioned by compose files rather than clicked into shape.

URL:      https://api.apisrouter.com/v1
API Key:  sk-YOUR-APISROUTER-KEY

Save → models auto-populate from /v1/models
(optional) Model IDs allowlist to curate the selector

How Open WebUI uses OpenAI connections.

Open WebUI (around 145K GitHub stars) is the default self-hosted AI chat front end: a full-featured web client with users and permissions, RAG and knowledge collections, tool calling, and model management, classically paired with Ollama for local models but equally at home speaking to remote APIs. Its connection model is additive. The Ollama section covers local runtimes; the OpenAI API section covers any endpoint speaking the standard chat-completions dialect, and you can add several connections side by side. Each connection contributes its model list to the shared selector, each has its own key, and each can be toggled off without deleting its configuration. Requests carry the model id as a plain string to whichever connection serves it. That design means a gateway connection does not displace anything: your local models keep running through Ollama at no per-token cost, while claude-sonnet-4-6, gpt-5.5, gemini-3.5-flash, and deepseek-v4-pro become selector entries for the conversations that need frontier quality. One key covers all of them, and admin-side usage stays readable because cloud traffic exits through exactly one place.

Deploy-time setup: environment variables.

For docker-compose and Kubernetes deployments, the connection can be part of the manifest. OPENAI_API_BASE_URL takes the endpoint and OPENAI_API_KEY the key; the instance comes up with the connection already present. Multiple endpoints are supported through the plural forms (OPENAI_API_BASE_URLS and OPENAI_API_KEYS with semicolon-separated values) if you run more than one remote source. Two operational notes. First, values set through the UI persist in Open WebUI's database and take precedence over environment defaults after first boot, a documented behavior that regularly surprises operators who change the env and see nothing happen; adjust existing connections in Admin Settings, or set ENABLE_PERSISTENT_CONFIG=false if you want the environment to stay authoritative. Second, if the endpoint's model listing is large, use the connection's Model IDs allowlist to curate what your users see; a four-item selector gets used, a two-hundred-item one gets scrolled past. Version note: menu wording has drifted across the project's fast release cadence (Settings vs Admin Settings, section names within Connections), so on older builds look for the OpenAI API base URL and key pair wherever connections live.

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OPENAI_API_BASE_URL=https://api.apisrouter.com/v1
      - OPENAI_API_KEY=sk-YOUR-APISROUTER-KEY
    ports:
      - "3000:8080"

Choosing models for a multi-user workspace.

With every cloud model billing through one key, A/B testing is a selector choice. Run the same team workload two weeks apart on two candidate defaults and let the per-model usage view in the APIsRouter console referee, per model and per day, rather than guessing from benchmarks.

• Default-model choice does the most work in a shared instance. claude-haiku-4-5-20251001 or gemini-3.5-flash as the workspace default keeps the per-conversation cost of casual use flat.
• claude-sonnet-4-6 and gpt-5.5 belong in the selector for drafting, analysis, and code questions; users step up when the task earns it.
• RAG pipelines multiply input tokens: every answer carries retrieved chunks. deepseek-v4-pro is worth testing as the RAG workhorse, where long-context handling per token spent is the decisive trait.
• Keep truly private material on local models through Ollama and route everything else through the gateway; the selector holds both lanes honestly.
• Use the Model IDs allowlist as policy: what is not in the selector cannot surprise you on the usage log.

Pay-as-you-go · transparent per-model pricing

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Failure modes specific to Open WebUI.

No models appearing after adding the connection is the most common report. The causes rank: the key failed against /v1/models (check it with the connection's verify control), the URL is missing its /v1 suffix, or the connection toggle is off. Open WebUI builds the selector from what the listing returns, so an empty selector means the listing call failed or returned nothing. Environment changes that seem ignored are the persistent-config rule described above: after first boot, the database wins over the environment for settings the UI manages. Edit the connection in Admin Settings or disable persistent config explicitly. A model that lists but errors on chat is usually an id the listing exposes but your key cannot use, or a typo introduced by hand-editing the Model IDs allowlist; compare against the raw /v1/models output. And keep the lanes straight when debugging: Ollama connection problems and OpenAI connection problems look identical from the chat window. The Connections page shows which lane a model belongs to; test the failing lane directly before assuming the whole instance is down.

Who routes Open WebUI through a gateway.

• Teams self-hosting one chat front end for everyone who want frontier models available without issuing vendor keys to individual users.
• Ollama users who keep local models for private work but want Claude and GPT quality in the same selector for the conversations that need it.
• Admins who need the cloud bill legible: one connection, one key, and a per-model usage log instead of receipts from four vendors.
• Operators in regions where some vendor sign-ups are painful; top-up based access with no card requirement removes the per-provider dependency.
• Homelabbers running Open WebUI for the household, where a single prepaid balance is easier to reason about than any subscription.

Verify the endpoint and debug the first chat.

Prove the endpoint from the server first, especially in containerized deployments where the container's network is not your laptop's. A models listing and one chat completion from inside the host confirm the gateway half before Open WebUI enters the picture. Then add the connection and watch the selector populate. Authentication errors are the key field; an empty selector is the listing call; a doubled path (/v1/v1/...) in server logs means the URL field already carried a /v1 and something appended another, so read the URL exactly as saved. Once chats flow, the APIsRouter console shows per-request model, token counts, and spend. For a multi-user instance this is the number that matters: which models your users actually pick, and what a week of the workspace really costs, per model, per day, on one page.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

FAQ