GetAPI.ONE

Migrer une intégration du SDK OpenAI vers GetAPI.ONE

Inventoriez le contrat de requête existant, modifiez les identifiants et l’URL de base derrière une configuration, associez un modèle exact du catalogue ONE, testez les deux chemins en canari et conservez un retour arrière.

Inventorier avant de modifier le trafic

Consignez la version actuelle du SDK, la famille de points de terminaison, l’identifiant du modèle, les champs de requête, le comportement du streaming, les délais, les tentatives et l’analyseur de sortie.
Préparez une clé ONE distincte et limitée, puis choisissez un modèle exact du catalogue actuel appartenant à la même famille de points de terminaison déclarée.
Définissez des mesures de réussite du canari et un retour arrière limité à la configuration.

text

Keep unchanged: request semantics → validation → output parsing
Change by configuration: API key + base URL + verified model mapping

Effectuer le plus petit changement réversible

Placez l’URL du fournisseur, la clé et l’association du modèle dans une configuration propre à l’environnement.
Définissez Python base_url ou Node.js baseURL sur https://www.getapi.one/v1 et utilisez GETAPI_ONE_API_KEY.
Conservez la famille de points de terminaison existante. Ne supprimez que les champs réellement facultatifs et inutiles ; si un comportement requis n’est pas pris en charge, arrêtez la migration et choisissez un modèle ou un chemin compatible.
Exécutez les deux chemins lors d’un canari contrôlé avec les mêmes jeux de données approuvés.
N’augmentez le trafic qu’après conformité de la qualité, des erreurs, de la latence et du coût observé aux critères d’acceptation.

python

client = OpenAI(
    api_key=os.environ["GETAPI_ONE_API_KEY"],
    base_url="https://www.getapi.one/v1",
    timeout=30.0,
    max_retries=0,
)

javascript

const client = new OpenAI({
  apiKey: process.env.GETAPI_ONE_API_KEY,
  baseURL: 'https://www.getapi.one/v1',
  timeout: 30_000,
  maxRetries: 0,
});

Examiner la matrice de compatibilité

Contrat	Contrôle de migration
Point de terminaison	Responses reste Responses ; Chat Completions reste Chat Completions sauf refonte distincte.
Modèle	Associez un identifiant exact du catalogue actuel au point de terminaison déclaré.
Paramètres	Vérifiez chaque comportement requis et chaque champ facultatif ; ne supposez pas un remplacement direct pour tous les paramètres.
Streaming	Vérifiez les noms d’événements, les résultats terminaux, la gestion des déconnexions et le comportement du proxy.
Erreurs et nouvelles tentatives	Conservez les identifiants de requête et évitez les tentatives qui dupliquent des effets secondaires.

Vérifier le canari

Les jeux de données approuvés produisent des sorties analysables qui respectent les mêmes critères d’acceptation de la tâche.
Les erreurs d’authentification, de point de terminaison, de débit, de délai et de modèle sont observables séparément.
L’utilisation observée et les tarifs en direct respectent le budget de migration avant toute augmentation du trafic.
Le retour à la configuration du fournisseur précédent restaure l’ancien chemin.

Diagnostiquer les régressions de migration

401 : confirmez que la clé ONE est utilisée uniquement avec l’URL de base ONE et qu’elle est activée.
404 : recherchez un /v1 dupliqué et vérifiez si la méthode du SDK correspond au point de terminaison du modèle sélectionné.
Échec de l’analyse : capturez une réponse expurgée, comparez-la à la structure documentée et revenez en arrière plutôt que d’accepter silencieusement des données mal formées.

Maintenir la migration isolée

Ne réutilisez jamais l’ancien identifiant du fournisseur comme identifiant ONE et n’exposez aucune des deux clés aux clients.
Utilisez des jeux de données expurgés proches de la production et limitez le trafic et les dépenses du canari.
Journalisez le fournisseur choisi, l’association du modèle, un identifiant de requête sûr et le résultat, sans secrets d’invite.