URL de base de l’API OpenAI (2026) : endpoints directs et compatibles

URL de base de l’API OpenAI (2026) : endpoints directs et compatibles

Réponse rapide : l’URL de base officielle de l’API OpenAI est https://api.openai.com/v1. Utilisez-la comme base_url ou baseURL du SDK, puis laissez le SDK ajouter le chemin de ressource. Les endpoints complets courants sont https://api.openai.com/v1/responses et https://api.openai.com/v1/chat/completions.

Pour la passerelle compatible OpenAI de Flatkey, utilisez https://router.flatkey.ai/v1 comme URL de base. L’endpoint correspondant pour les complétions de chat est https://router.flatkey.ai/v1/chat/completions. Ne collez pas le chemin complet /chat/completions dans un champ de SDK qui attend uniquement une URL de base.

Tableau des URL de base de l’API OpenAI

URL de base ou endpoint : quelle différence ?

Une URL de base est le préfixe partagé configuré une seule fois dans un SDK. Un endpoint est le chemin complet d’une opération d’API. Les confondre entraîne les échecs d’intégration les plus fréquents :

• 404 Not Found : vous avez fourni un chemin incorrect ou dupliqué /v1.
• 401 Unauthorized : la clé n’appartient pas à l’URL de base que vous appelez.
• /v1/v1/... : l’URL de base configurée et le code client ont tous deux ajouté /v1.
• .../chat/completions/chat/completions : un endpoint complet a été transmis là où le SDK attendait uniquement l’URL de base.

Utilisez une source unique de vérité pour l’URL de base, conservez les clés dans des variables d’environnement et exécutez une petite requête /models ou de chat avant de migrer le trafic de production.

Ce que change une passerelle d’API compatible OpenAI

Le changement principal est opérationnel, pas conceptuel.

C’est pourquoi les équipes recherchent avant tout une openai compatible api gateway. Elles ne demandent pas un nouveau format de prompt. Elles cherchent à réduire le risque de réécriture.

Utilisez cette checklist de migration avant de modifier la production

La manière la plus sûre d’adopter une openai compatible api gateway consiste à la traiter comme un changement d’intégration contrôlé, et non comme un projet d’abstraction généralisé.

1. Listez les endpoints OpenAI exacts que vous utilisez aujourd’hui. La plupart des équipes pensent utiliser « l’API OpenAI », alors qu’elles n’utilisent en réalité qu’un sous-ensemble plus restreint, comme les complétions de chat, les réponses, les embeddings ou la génération d’images.
2. Confirmez quels appels doivent rester inchangés dans le code de l’application. Cela maintient un périmètre réaliste et protège la promesse de « migration minimale ».
3. Vérifiez si votre SDK actuel prend déjà en charge une URL de base personnalisée. Les clients Python et Node officiels actuels d’OpenAI le permettent.
4. Choisissez d’abord un workflow de préproduction. Commencez par la route qui correspond déjà à une forme de requête OpenAI standard.
5. Vérifiez que les modèles cibles sont disponibles avant le déploiement. Ne vous fiez pas à d’anciennes captures d’écran ni à des hypothèses fondées sur un catalogue obsolète.
6. Documentez la règle de repli. Les réviseurs doivent savoir si la route peut changer de modèle, échouer de manière fermée ou mettre en file d’attente.
7. Approuvez la réserve de compatibilité. Votre formulation publiée doit indiquer « compatible OpenAI » pour la surface de requête prise en charge, et non « entièrement identique à OpenAI ».

Cette checklist rend une openai compatible api gateway crédible lors d’une revue de production.

Exemples de code avec changements minimaux

Les SDK officiels actuels d’OpenAI documentent déjà la prise en charge d’URL de base personnalisées. C’est la raison mécanique pour laquelle une openai compatible api gateway peut constituer une migration fluide lorsque la passerelle préserve la forme de requête de type OpenAI que vous utilisez déjà.

Exemple Python

from openai import OpenAI

client = OpenAI(
    api_key="sk-fk-your-flatkey-key",
    base_url="https://router.flatkey.ai/v1",
)

response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Return a one-line health check."},
    ],
)

print(response.choices[0].message.content)

Exemple Node

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-5.4-mini",
  messages: [
    { role: "system", content: "You are a concise assistant." },
    { role: "user", content: "Return a one-line health check." },
  ],
});

console.log(response.choices[0].message.content);

Exemple cURL

curl -X POST "https://router.flatkey.ai/v1/chat/completions" \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [
      { "role": "user", "content": "Return a one-line health check." }
    ]
  }'

Pour de nombreuses équipes, c'est la première preuve qu'une passerelle API compatible avec OpenAI ne nécessite pas de réécrire le client. La contrainte importante est que le workflow choisi doit correspondre à la surface de requêtes prise en charge.

Ce qu'il faut vérifier avant d'affirmer que la migration est « immédiate »

C'est là que la plupart des pages sur les passerelles API compatibles avec OpenAI deviennent imprécises. « Immédiate » est trop vague si vous ne définissez pas le périmètre.

Utilisez ce tableau lors de la revue :

Une passerelle API compatible avec OpenAI est utile lorsque ces vérifications passent avec moins de friction que des migrations distinctes par fournisseur.

Une séquence de déploiement pratique

Voici le parcours de déploiement le plus simple pour une passerelle API compatible avec OpenAI lorsque vous souhaitez limiter les modifications de code :

1. Inventoriez le chemin d'appel actuel. Notez la version actuelle du SDK, la famille d'endpoints, les ID de modèles, les paramètres de streaming et les hypothèses de nouvelle tentative.
2. Modifiez une seule URL de base en préproduction. Conservez d'abord le même modèle de client. Ne combinez pas ce changement avec des modifications non liées de prompts ou de modèles.
3. Conservez un modèle approuvé pour le premier test. Le premier critère de réussite est la compatibilité du transport, et non une large couverture de modèles.
4. Effectuez des vérifications des formats de réponses et d'erreurs. Comparez les sorties, les codes d'état, les attentes de latence et le comportement de journalisation.
5. Examinez la politique de routage des modèles. Décidez si la route est fixée à un seul modèle, peut basculer vers une classe équivalente ou doit échouer sans solution de repli.
6. N'élargissez qu'après confirmation du catalogue disponible. Le 15 juillet 2026, le flux public de tarification de Flatkey affichait 170 lignes au total et 95 lignes disponibles, mais le déploiement en production exige toujours une validation exacte des modèles le jour de la mise en production.

Cette séquence fait d'une passerelle API compatible avec OpenAI une couche de contrôle de migration plutôt qu'une autre inconnue d'intégration.

En quoi cela diffère d'une migration directe vers un fournisseur

La documentation des fournisseurs montre déjà que la compatibilité de type OpenAI devient normale. Google documente l'accès à Gemini via des bibliothèques OpenAI. DeepSeek documente la compatibilité avec OpenAI et Anthropic. Mais chaque fournisseur conserve sa propre clé, son URL de base et son périmètre opérationnel.

C'est la lacune qu'une passerelle API compatible avec OpenAI comble. Au lieu d'apprendre à chaque équipe une nouvelle configuration propre à chaque fournisseur, vous pouvez centraliser la surface de migration et orienter le travail de revue vers l'approbation des modèles, l'observabilité et la politique de routage des modèles.

Cela explique aussi pourquoi le message actuel de Flatkey est plus convaincant que « cela fonctionne avec le SDK OpenAI ». L'avantage le plus important est qu'une passerelle API compatible avec OpenAI peut consolider l'accès et la revue sans imposer une réécriture immédiate de l'application.

Formulation de conformité que les réviseurs peuvent approuver

Utilisez une formulation comme celle-ci lors de la revue finale avant publication :

Évitez les formulations de ce type, sauf si les réviseurs peuvent les prouver :

Ces réserves rendent le discours sur la passerelle d’API compatible avec OpenAI plus crédible, et non plus faible.

Quand une passerelle d’API compatible avec OpenAI est le bon choix

Une passerelle d’API compatible avec OpenAI est généralement le bon choix lorsque :

• votre équipe s’appuie déjà sur des flux de client de type OpenAI et souhaite la voie de migration la moins perturbatrice
• plus d’une famille de modèles est déjà dans le périmètre
• vous avez besoin d’un point unique pour examiner les accès, l’utilisation et les routes approuvées
• les changements de modèles sont suffisamment fréquents pour justifier une politique de routage des modèles partagée
• vous souhaitez une migration contrôlée avant d’envisager des fonctionnalités de passerelle plus avancées

Si ces conditions ne sont pas réunies, une configuration directe avec le fournisseur peut rester plus simple. Cet article doit rester honnête quant à ce compromis.

Équipes AWS : l’URL de base compatible avec OpenAI de Bedrock

Si vos modèles s’exécutent sur AWS, Amazon Bedrock expose sa propre URL de base compatible avec OpenAI, https://bedrock-runtime.{region}.amazonaws.com/openai/v1, authentifiée avec des clés API Bedrock. Notre guide de l’API compatible avec OpenAI d’Amazon Bedrock couvre les endpoints, les clés, les ID de modèles et la limitation de /models.

Conclusion

La valeur d’une passerelle d’API compatible avec OpenAI ne réside pas dans l’invention d’un nouveau modèle d’API. Elle permet aux équipes de conserver une intégration familière de type OpenAI tout en plaçant le contrôle des accès, l’approbation des modèles et le contrôle du déploiement derrière une couche unique et vérifiable.

Pour Flatkey, l’affirmation la plus solide et vérifiable est simple : conservez le modèle de client que vous utilisez déjà, remplacez l’URL de base par https://router.flatkey.ai/v1, validez le workflow exact pris en charge et approuvez la politique de routage des modèles avant d’élargir le trafic. C’est la liste de contrôle de migration dont les développeurs ont réellement besoin.