Migrer une intégration OpenRouter vers une autre passerelle API

Choisir le scénario

• Rester sur OpenRouter si intégration, facturation, modèles et exploitation satisfont les besoins.
• Ajouter un secours testé si une seconde route apporte une valeur indépendante.
• Lancer un canary de migration si protocole et modèles conviennent et qu’une comparaison contrôlée est possible.

BetterToken ne transfère ni clés ni solde OpenRouter. Utilisez votre propre compte, une clé de test et les exigences/Model ID actuels de Workspace ou des Docs.

Matrice des exigences

Les modèles et prix sont dynamiques ; consultez catalogue et rate card au moment du test.

Trois scénarios

1. Rester sur OpenRouter

Sans lacune concrète, ne migrez pas. Placez Base URL, clé et Model ID dans la configuration, documentez les champs consommés, séparez les headers, ajoutez des tests de contrat et désignez le responsable du rollback.

2. Ajouter un secours testé

Gardez les configurations séparées. Définissez les erreurs éligibles au fallback : erreurs d’authentification, Model ID invalide, méthode non prise en charge ou requête mal formée ne doivent généralement pas changer de fournisseur. Limitez retry et timeout, respectez l’idempotence et ne dupliquez jamais une mutation sans mécanisme vérifié.

3. Migrer avec un canary

Envoyez une faible part de trafic non critique et conservez OpenRouter. Définissez avant le test : schéma parseable, streaming/outils corrects, erreurs classifiables, usage rapprochable, seuils respectés et aucun effet manquant ou dupliqué.

Procédure en cinq étapes

Étape 1 : inventorier le contrat

Notez protocole, SDK, méthode, Base URL, Model ID, variable d’authentification, headers, streaming, outils, timeouts, retries, erreurs, request ID et usage. Ne copiez pas les clés.

Étape 2 : isoler la configuration candidate

Créez une clé de test distincte. Pour BetterToken, prenez le Model ID et les exigences actuels dans Workspace ou la documentation API. N’écrasez pas OpenRouter.

Étape 3 : définir la Base URL du protocole

TEST_API_KEY=your_test_api_key_here
TEST_BASE_URL=https://www.bettertoken.ai/v1?utm_source=blog&utm_medium=organic_content&utm_campaign=SEO-088&utm_content=analog-openrouter-v-rossii-vybor-i-perenos-api
TEST_MODEL_ID=current_model_id_from_provider_catalog

Pour Anthropic-compatible, utilisez https://bettertoken.ai sans /v1 et le contrat correspondant. Vérifiez si le client ajoute lui-même le chemin.

Étape 4 : exécuter les mêmes tests

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TEST_API_KEY"],
    base_url=os.environ["TEST_BASE_URL"],
)

response = client.chat.completions.create(
    model=os.environ["TEST_MODEL_ID"],
    messages=[{"role": "user", "content": "Reply with: gateway test passed"}],
    max_tokens=32,
)

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

Les placeholders sont volontaires. Testez ensuite streaming, outils, authentification invalide et Model ID invalide. Conservez heure, statut, request ID, schéma et usage sans secrets.

Étape 5 : comparer le canary

Comparez succès/erreurs, latence, timeouts, retries et Retry-After, schémas, fin du stream, input/cached input/output, statut et charge du fournisseur, effets manquants ou dupliqués. N’étendez que si toutes les exigences dures passent.

Validation et rollback

Un HTTP réussi ne prouve ni équivalence ni routage. Déclenchez des erreurs contrôlées et comparez statut, corps, request ID, métadonnées de retry et comportement du client. La référence des erreurs OpenRouter reste un contrat distinct.

Rapprochez usage SDK, log applicatif et compte fournisseur. BetterToken Dashboard affiche heure, modèle, statut, input, output, cache et charge, sans impliquer le stockage du prompt/résultat complet. Testez séparément streaming, déconnexion et tool calls en lecture seule.

Rollback immédiat si schéma illisible, stream incomplet, outils corrompus, usage non rapprochable, seuil dépassé ou mutation incertaine :

1. arrêter l’expansion ;
2. renvoyer les nouvelles requêtes vers OpenRouter ;
3. ne pas rejouer automatiquement une mutation incertaine ;
4. conserver heures, IDs, statuts et logs expurgés ;
5. isoler puis révoquer la clé candidate si inutile.

Ne supprimez l’ancienne configuration qu’après fenêtre d’observation, test de rollback et rapprochement.

Coûts et décision finale

Ne fixez aucun prix. Vérifiez rate cards actuelles, modèles, input/cached input/output, exigences du compte, limites, timeouts, export, rotation et support. Pour BetterToken, utilisez les tarifs actuels et Workspace.

Restez sans lacune concrète, ajoutez un backup seulement après tests équivalents, et migrez uniquement après canary, rapprochement et rollback validés. Commencez avec la documentation API BetterToken.

Sources

• OpenRouter quickstart
• OpenRouter errors and debugging
• OpenRouter model catalog
• BetterToken API reference