Aperçu de l'API

RouteAPI fournit aux entreprises une capacité d’accès unifiée aux API d’IA, en regroupant les capacités de modèles OpenAI, Claude, Gemini, Azure, AWS Bedrock et d’autres dans un ensemble d’interfaces stable, observable et mesurable. Les systèmes métier n’ont qu’à s’intégrer à RouteAPI pour appeler différents services de modèles avec une authentification, des ID de modèle et des journaux unifiés.

Démarrage en trois étapes

Si vous utilisez déjà un SDK compatible OpenAI, il suffit de modifier deux paramètres pour que tout fonctionne :

curl https://api.routeapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $ROUTEAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "messages": [{ "role": "user", "content": "你好" }]
  }'

Remplacez la Base URL par https://api.routeapi.ai/v1.
Remplacez l’API Key par votre Token RouteAPI (créé sur la page API Keys de la console).
Remplacez model par un ID de modèle disponible sur votre compte, à consulter via GET /v1/models.

Pour la procédure complète de bascule d’une application OpenAI existante, voir Migrer depuis OpenAI.

Points d’entrée de protocole pris en charge

RouteAPI prend en charge simultanément trois protocoles courants : OpenAI compatible, Claude Messages et Google Gemini. Vous pouvez continuer à utiliser votre SDK ou client existant ; il suffit de remplacer la Base URL et l’API Key par celles de RouteAPI.

Protocole	Interfaces typiques	Cas adaptés
OpenAI compatible	`/v1/chat/completions`, `/v1/responses`, `/v1/embeddings`	OpenAI SDK, Cursor, OpenCode, LangChain, LiteLLM et autres clients compatibles
Claude Messages	`/v1/messages`	Claude Code, Anthropic SDK, clients au format natif de messages Claude
Google Gemini	`/v1beta/models/{model}:generateContent`	Google GenAI SDK, clients Gemini REST

Les requêtes arrivant par différents protocoles sont adaptées au format nécessaire à l’intérieur de RouteAPI. Côté métier, il est préférable de choisir en priorité le protocole pris en charge nativement par le client actuel : un protocole natif ne passe pas par une conversion et son comportement est le plus prévisible. Pour les règles de correspondance et les limites connues des appels inter-protocoles (par exemple appeler un modèle Claude au format OpenAI), voir Conversion de protocole.

Adresses de base

Les protocoles OpenAI compatible et Claude Messages utilisent par défaut :

https://api.routeapi.ai/v1

Le protocole Google Gemini utilise par défaut :

https://api.routeapi.ai/v1beta

En-têtes de requête communs

Authorization: Bearer sk-your-routeapi-token
Content-Type: application/json

Tous les protocoles utilisent le même type de Token RouteAPI. Conservez le Token côté serveur ; ne l’exposez pas dans un navigateur, une application mobile ou un dépôt public. Pour le détail des permissions de clé, des quotas et des erreurs d’authentification, voir Authentification.

Le protocole Claude Messages accepte aussi l’en-tête x-api-key habituellement utilisé par le SDK Anthropic ; avec ce SDK, il suffit donc généralement de changer la Base URL.

Index des interfaces et capacités

Choisissez le point d’entrée selon ce que vous voulez faire :

Ce que je veux faire	Quelle interface utiliser	Documentation
Conversation multi-tours classique	`/v1/chat/completions`	Chat Completions
Agents de codage, clients de nouveau protocole	`/v1/responses`	Responses
Recherche vectorielle, recherche sémantique, RAG	`/v1/embeddings`	Embeddings
Consulter les modèles et capacités disponibles	`/v1/models`	Models
Faire appeler des fonctions externes par le modèle	paramètre `tools`	Appel d’outils
Faire produire une sortie JSON à structure fixe	paramètre `response_format`	Sorties structurées
Transmettre des images à comprendre par le modèle	`content` multimodal	Entrée multimodale
Retour mot par mot, réduire la latence du premier caractère	`stream: true`	Streaming
Génération musicale par IA	Suno REST API	Suno API

Périmètre de compatibilité des protocoles

RouteAPI conserve autant que possible l’expérience d’appel native de chaque protocole, tout en transférant la requête vers un service de modèle adapté. Les capacités réellement disponibles dépendent du modèle, des fonctions du service et des paramètres de la requête :

Capacité	Description
Chat Completions	Interface de chat de base recommandée, adaptée à la plupart des clients compatibles OpenAI SDK
Responses	Adapté aux clients et agents de codage qui prennent en charge le protocole OpenAI Responses
Embeddings	Utilisé pour la recherche vectorielle, la recherche sémantique et le RAG
Streaming	Retourne le contenu incrémental avec SSE
Claude Messages	Prend en charge la structure de messages native Claude, adaptée à Claude Code et Anthropic SDK
Google Gemini	Prend en charge les requêtes de style Gemini `generateContent`
Tool Calling	Dépend de la prise en charge des appels d’outils par le modèle
Structured Outputs	Dépend de la prise en charge du JSON mode ou de JSON Schema par le modèle
Vision / Multimodal	Dépend de la prise en charge des images ou des entrées multimodales par le modèle

Les capacités sont fournies par modèle et non par plateforme : la même interface peut perdre la prise en charge des appels d’outils ou des entrées image si vous changez de model. Testez avec le modèle cible avant la mise en production, ou consultez les champs de capacités renvoyés par Models.

Conventions de stabilité des interfaces

Les paramètres de requête sont conservés autant que possible et transférés selon le protocole.
Si des paramètres scalaires optionnels sont explicitement transmis avec 0 ou false, RouteAPI les traite comme des valeurs explicites et ne les supprime pas comme des valeurs par défaut.
Les paramètres non pris en charge par certains modèles peuvent être adaptés, ignorés ou produire une erreur selon les règles de compatibilité du modèle.
En production, il est recommandé de figer les ID de modèle et de prévoir une stratégie de secours pour les flux métier critiques.
Pour les capacités optionnelles comme les appels d’outils, les sorties structurées, les entrées visuelles et les statistiques d’utilisation en streaming, validez d’abord en environnement de test avant la mise en production.

Recommandations pour l’intégration entreprise

Encapsulez les Tokens RouteAPI côté serveur afin d’éviter que le frontend métier ne détienne directement les clés.
Utilisez des Tokens différents pour les différents systèmes métier afin de faciliter les limites indépendantes, l’audit et le diagnostic.
Figez les ID de modèle et les chemins de protocole ; ne dépendez pas d’alias temporaires ni de noms d’affichage.
Enregistrez l’ID de requête, l’ID de modèle, le code d’état, la durée et l’utilisation de tokens pour faciliter l’analyse des latences et des coûts anormaux.
Pour les activités métier critiques, activez des délais d’attente de streaming, des reprises en cas d’échec et des modèles de remplacement afin de réduire l’impact d’une anomalie d’un service de modèle unique.

Et ensuite

Authentification — créer des Tokens, configurer les quotas et permissions.
Erreurs et débogage — signification des codes d’état et ordre de diagnostic.
Migrer depuis OpenAI — liste de vérification de bascule pour les applications existantes.
Intégration client — configuration spécifique pour Cursor, Claude Code, LangChain, etc.
Facturation et quotas — statistiques d’utilisation et conventions de facturation.