← Back to Blog
openwebui apiOpen WebUIOpenAI-compatible APILinkModel API

Open WebUI API Setup: Connect an OpenAI-Compatible Model Provider

Set up the Open WebUI API with an OpenAI-compatible provider, troubleshoot model discovery, and connect a LinkModel chat model for local or hosted use.

2026-09-04

Open WebUI API Setup: Connect an OpenAI-Compatible Model Provider

Open WebUI can act as a chat interface in front of any provider that implements the OpenAI Chat Completions protocol. The setup is a provider base URL, a bearer key, and one or more model IDs. For LinkModel, use https://api.linkmodel.ai/v1 as the API root and select a chat model from the current LinkModel model catalog.

This distinction matters: Open WebUI is the interface and access layer; the model provider remains responsible for inference, limits, and billing. A successful Open WebUI login does not prove that the upstream model endpoint or model ID is valid.

What the Open WebUI API exposes

Open WebUI documents an OpenAI-compatible chat-completions route for models configured in the instance. A client can call its local endpoint like this:

curl -X POST "http://localhost:3000/api/chat/completions" \
  -H "Authorization: Bearer $OPENWEBUI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-open-webui-model-id",
    "messages": [{"role": "user", "content": "Say hello in one sentence."}]
  }'

The Open WebUI API key is separate from the upstream LinkModel key. Keep both on the server side. If your application should call LinkModel directly, use LinkModel's API root rather than adding an unnecessary Open WebUI hop.

For media generation, an Open WebUI chat interface is not a replacement for a media task API. Use the n8n workflow templates for AI media for automation patterns, or the LinkModel CLI when the job belongs in a terminal or CI workflow.

Step 1: Start Open WebUI

The official quick start provides a Docker command and exposes the interface on port 3000. Your installation may use a different port or reverse proxy, so substitute the public URL in the examples below. Create an administrator account, then open the admin connection settings.

Open WebUI's provider-agnostic design expects an OpenAI-compatible API. It may call /models to discover the upstream list. If a provider does not implement /models, the connection can fail verification even when chat completions would work; in that case add model IDs manually to the connection allowlist.

The official Open WebUI compatible-provider guide documents this discovery behavior and the connection fields. If you need a translation or routing layer for a provider with non-standard behavior, see the LiteLLM Proxy setup before adding custom middleware.

Step 2: Add LinkModel as the upstream provider

In Settings → Admin → Connections → Manage OpenAI API Connections, add a connection with:

URL:      https://api.linkmodel.ai/v1
API key:  your LinkModel API key
Provider: Default

Do not append /chat/completions to the URL. Open WebUI builds the endpoint path from the API root. LinkModel's current documentation lists bearer-authenticated POST /chat/completions and public GET /models endpoints beneath that root.

Next, filter the model list to the IDs your users need. For example, the current LinkModel reference lists chat models such as gpt-5.4-mini, gpt-5.4, claude-sonnet-4-6, and deepseek-v4-flash. Availability and capabilities can change, so treat these as examples to verify rather than a permanent allowlist.

An allowlist is safer than exposing every model. It reduces selector clutter, lowers the chance of users choosing a model with incompatible tool or image behavior, and makes cost policy easier to explain.

Step 3: Test discovery and a chat completion

First test the upstream models endpoint independently:

curl "https://api.linkmodel.ai/v1/models"

Then test the provider directly:

curl -X POST "https://api.linkmodel.ai/v1/chat/completions" \
  -H "Authorization: Bearer $LINKMODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [{"role": "user", "content": "Reply with the word ready."}]
  }'

If the direct request works but Open WebUI does not show a model, check the connection URL, model filter, and Open WebUI logs. If the direct request fails, fix the provider or credential before debugging the UI.

Using the Open WebUI API from Python

Once the connection is working, your application can call Open WebUI rather than the upstream provider:

import os
from openai import OpenAI
 
client = OpenAI(
    api_key=os.environ["OPENWEBUI_API_KEY"],
    base_url="http://localhost:3000/api",
)
 
response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[{"role": "user", "content": "Summarize this ticket in one sentence."}],
)
print(response.choices[0].message.content)

Use the model ID exactly as it appears in Open WebUI. Depending on your connection settings, Open WebUI may add a provider prefix or expose a filtered ID. Confirm the actual request in a development log before hard-coding it.

For application code that bypasses the Open WebUI front end, compare this request path with the LangChain OpenAI custom-base-URL example. For a complete n8n conversational layer, use the n8n AI chatbot architecture.

Tool calling and model compatibility

Open WebUI supports tools and can execute configured tool servers, but compatibility is not universal. A provider may support ordinary chat while returning a non-standard tool-call stream. Start with plain chat, then test one read-only tool and inspect the complete request and response.

For sensitive tools, require approval and enforce authorization in the tool server. The upstream model should never be able to create a refund, delete data, or send an email merely because a prompt asked it to do so.

Troubleshooting the Open WebUI API

Connection verification fails with 401: verify the upstream key, bearer format, and whether your reverse proxy is rewriting the Authorization header.

Verification fails but chat works: the provider may not implement /models in the form Open WebUI expects. Add the exact model IDs manually and test a completion.

No models appear: remove a trailing slash if the provider documentation requires an exact base URL, clear an old model filter, and restart or refresh the connection cache.

Blank replies with tools: disable tools temporarily to isolate the issue. Then compare the provider's tool-call streaming format with Open WebUI's compatibility notes and use a translation gateway if needed.

The client receives 404: decide whether the client is calling Open WebUI or LinkModel. Open WebUI's local API path and LinkModel's upstream API path are different; do not mix their base URLs.

Production checklist

Put Open WebUI behind authentication and TLS, restrict outbound provider access, rotate keys, and avoid using an administrator/master key for ordinary user traffic. Add model allowlists, usage tracking, request timeouts, and a fallback message. Log request IDs and model IDs, but redact prompts and credentials unless you have a documented reason to retain them.

Next step

Use Open WebUI when you want a self-hosted conversational front end over a compatible provider. Use LinkModel directly when you need an application API, and keep LinkModel CLI in mind for agent-operated media workflows. For the automation layer around images and videos, see n8n workflow templates for AI media.

Sources: Open WebUI OpenAI-compatible provider guide, Open WebUI API endpoints, LinkModel's first API call, and LinkModel's model reference.

Related Posts