Connectez Open WebUI à un endpoint compatible OpenAI personnalisé.

Réponse rapide : une connexion dans Admin Settings.

En tant qu'administrateur, ouvrez Admin Settings, allez dans Connections, et sous la section OpenAI API cliquez pour ajouter une connexion. Deux champs comptent : l'URL, réglée sur https://api.apisrouter.com/v1, et la clé API. Enregistrez, et Open WebUI interroge le listing /v1/models de l'endpoint pour remplir le sélecteur de modèle ; vérifiez avec le contrôle de vérification de la connexion, puis choisissez n'importe quel id du catalogue dans un nouveau chat. Les connexions ajoutées de cette façon sont valables pour tout l'espace de travail : chaque utilisateur de votre instance Open WebUI voit les modèles, sous réserve des contrôles d'accès aux modèles que vous configurez. Les mêmes valeurs peuvent aussi être livrées comme variables d'environnement au moment du déploiement, OPENAI_API_BASE_URL et OPENAI_API_KEY, ce qui est la voie plus propre quand l'instance est provisionnée par des fichiers compose plutôt que configurée à la souris.

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

Comment Open WebUI utilise les connexions OpenAI.

Open WebUI (environ 145 000 étoiles GitHub) est l'interface de chat IA auto-hébergée par défaut : un client web complet avec utilisateurs et permissions, RAG et collections de connaissances, appel d'outils, et gestion de modèles, classiquement associé à Ollama pour les modèles locaux mais tout aussi à l'aise pour parler à des API distantes. Son modèle de connexion est additif. La section Ollama couvre les runtimes locaux ; la section OpenAI API couvre tout endpoint parlant le dialecte chat-completions standard, et vous pouvez ajouter plusieurs connexions côte à côte. Chaque connexion contribue sa liste de modèles au sélecteur partagé, chacune a sa propre clé, et chacune peut être désactivée sans supprimer sa configuration. Les requêtes portent l'id du modèle comme simple chaîne vers quelle que soit la connexion qui le sert. Cette conception signifie qu'une connexion de passerelle ne déplace rien : vos modèles locaux continuent de tourner via Ollama sans coût par token, tandis que claude-sonnet-4-6, gpt-5.5, gemini-3.5-flash et deepseek-v4-pro deviennent des entrées du sélecteur pour les conversations qui ont besoin de qualité frontier. Une seule clé les couvre tous, et l'usage côté administrateur reste lisible car le trafic cloud sort par exactement un seul endroit.

Configuration au déploiement : variables d'environnement.

Pour les déploiements docker-compose et Kubernetes, la connexion peut faire partie du manifeste. OPENAI_API_BASE_URL prend l'endpoint et OPENAI_API_KEY la clé ; l'instance démarre avec la connexion déjà présente. Plusieurs endpoints sont pris en charge via les formes plurielles (OPENAI_API_BASE_URLS et OPENAI_API_KEYS avec des valeurs séparées par des points-virgules) si vous faites tourner plus d'une source distante. Deux remarques opérationnelles. D'abord, les valeurs réglées via l'interface persistent dans la base de données d'Open WebUI et prennent le pas sur les défauts d'environnement après le premier démarrage, un comportement documenté qui surprend régulièrement les opérateurs qui changent l'environnement et ne voient rien se passer ; ajustez les connexions existantes dans Admin Settings, ou réglez ENABLE_PERSISTENT_CONFIG=false si vous voulez que l'environnement reste la référence. Ensuite, si le listing de modèles de l'endpoint est volumineux, utilisez la liste d'autorisation Model IDs de la connexion pour curer ce que voient vos utilisateurs ; un sélecteur de quatre éléments est utilisé, un de deux cents éléments se fait parcourir sans être vraiment utilisé. Remarque de version : le libellé des menus a dérivé au fil du rythme de sortie rapide du projet (Settings vs Admin Settings, noms de section au sein de Connections), donc sur les versions plus anciennes, cherchez la paire base URL et clé de l'API OpenAI là où vivent les connexions.

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"

Choisir des modèles pour un espace de travail multi-utilisateur.

Comme chaque modèle cloud facture via une seule clé, le test A/B se résume à un choix de sélecteur. Lancez la même charge de travail d'équipe à deux semaines d'intervalle sur deux défauts candidats et laissez la vue d'usage par modèle dans la console APIsRouter arbitrer, par modèle et par jour, plutôt que de deviner à partir de benchmarks.

• Le choix du modèle par défaut fait le plus gros du travail dans une instance partagée. claude-haiku-4-5-20251001 ou gemini-3.5-flash comme défaut de l'espace de travail garde le coût par conversation de l'usage occasionnel plat.
• claude-sonnet-4-6 et gpt-5.5 ont leur place dans le sélecteur pour la rédaction, l'analyse et les questions de code ; les utilisateurs montent en gamme quand la tâche le justifie.
• Les pipelines RAG multiplient les tokens d'entrée : chaque réponse porte des fragments récupérés. deepseek-v4-pro vaut la peine d'être testé comme cheval de bataille RAG, où la gestion du long contexte par token dépensé est le trait décisif.
• Gardez le matériel vraiment privé sur des modèles locaux via Ollama et routez tout le reste via la passerelle ; le sélecteur porte honnêtement les deux voies.
• Utilisez la liste d'autorisation Model IDs comme politique : ce qui n'est pas dans le sélecteur ne peut pas vous surprendre sur le journal d'usage.

Paiement à l'usage · en dessous du tarif officiel

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

Modes d'échec spécifiques à Open WebUI.

Aucun modèle qui apparaît après l'ajout de la connexion est le signalement le plus courant. Les causes se classent ainsi : la clé a échoué contre /v1/models (vérifiez-la avec le contrôle de vérification de la connexion), l'URL manque de son suffixe /v1, ou l'interrupteur de la connexion est désactivé. Open WebUI construit le sélecteur à partir de ce que renvoie le listing, donc un sélecteur vide signifie que l'appel de listing a échoué ou n'a rien renvoyé. Des changements d'environnement qui semblent ignorés relèvent de la règle de config persistante décrite plus haut : après le premier démarrage, la base de données l'emporte sur l'environnement pour les réglages que gère l'interface. Éditez la connexion dans Admin Settings ou désactivez explicitement la config persistante. Un modèle qui apparaît dans la liste mais échoue au chat est généralement un id que le listing expose mais que votre clé ne peut pas utiliser, ou une faute de frappe introduite en éditant à la main la liste d'autorisation Model IDs ; comparez à la sortie brute de /v1/models. Et gardez les voies bien séparées en déboguant : les problèmes de connexion Ollama et les problèmes de connexion OpenAI se ressemblent depuis la fenêtre de chat. La page Connections montre à quelle voie appartient un modèle ; testez directement la voie en échec avant de supposer que toute l'instance est en panne.

Qui route Open WebUI via une passerelle.

• Les équipes qui auto-hébergent une seule interface de chat pour tout le monde et veulent des modèles frontier disponibles sans distribuer de clés fournisseur aux utilisateurs individuels.
• Les utilisateurs d'Ollama qui gardent des modèles locaux pour le travail privé mais veulent la qualité de Claude et GPT dans le même sélecteur pour les conversations qui en ont besoin.
• Les administrateurs qui ont besoin d'une facture cloud lisible : une connexion, une clé, et un journal d'usage par modèle plutôt que des reçus de quatre fournisseurs.
• Les opérateurs dans des régions où certaines inscriptions fournisseur sont pénibles ; un accès basé sur la recharge, sans exigence de carte, supprime la dépendance par fournisseur.
• Les passionnés de homelab qui font tourner Open WebUI pour le foyer, où un seul solde prépayé est plus facile à raisonner que n'importe quel abonnement.

Vérifiez l'endpoint et déboguez le premier chat.

Prouvez d'abord l'endpoint depuis le serveur, en particulier dans les déploiements conteneurisés où le réseau du conteneur n'est pas celui de votre portable. Un listing de modèles et une completion de chat depuis l'intérieur de l'hôte confirment la moitié passerelle avant qu'Open WebUI n'entre en jeu. Ajoutez ensuite la connexion et observez le sélecteur se remplir. Les erreurs d'authentification renvoient au champ clé ; un sélecteur vide renvoie à l'appel de listing ; un chemin doublé (/v1/v1/...) dans les journaux serveur signifie que le champ URL portait déjà un /v1 et que quelque chose en a ajouté un autre, donc lisez l'URL exactement telle qu'enregistrée. Une fois que les chats circulent, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Pour une instance multi-utilisateur, c'est le chiffre qui compte : quels modèles vos utilisateurs choisissent réellement, et ce que coûte réellement une semaine de l'espace de travail, par modèle, par jour, sur une seule 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"}]}'

Questions fréquentes