Spécification de l’API

Envoyez une première requête, sélectionnez un modèle dans le catalogue et conservez un identifiant de requête à des fins de diagnostic.

Envoyez une clé d’API dans un en-tête Bearer et séparez les identifiants de production de ceux du développement.

Utilisez des URL de base différentes pour les clients de type OpenAI et les clients Messages : ils ciblent une même spécification, mais composent les chemins différemment.

Configurez un client avec une clé, un modèle et une URL de base correspondant à son protocole ; conservez le secret dans l’environnement.

Réponses pratiques et concises sur les clés, les URL de base, les modèles, les coûts et le diagnostic des intégrations.

Construisez la sélection des modèles à partir des données du catalogue plutôt qu’à partir d’une liste codée en dur dans votre application.

Séparez les clés, les responsables, les budgets et les traces d’utilisation entre les applications et les espaces de travail.

Considérez les limites liées à la clé, à l’organisation, au modèle et au routage comme des éléments du flux de travail de l’utilisateur.

Reliez les métadonnées de réponse et vos propres journaux de requêtes aux actions réelles des utilisateurs.

Réduisez au minimum les données transmises, séparez l’identifiant de l’utilisateur final du contenu et contrôlez la conservation dans votre produit.

Créez des conversations à plusieurs tours dans le format messages habituel et sélectionnez un modèle pour chaque requête.

Utilisez le format Messages pour les conversations dotées d’une instruction system de niveau supérieur et d’une limite de sortie explicite.

Utilisez un seul objet input lorsque votre application tire parti du traitement des éléments de sortie et des actions dans un modèle de données unique.

Recevez les jetons et les deltas structurés via SSE sans attendre la réponse complète.

Décrivez les fonctions avec JSON Schema, exécutez l’appel dans votre application et renvoyez le résultat à la conversation.

Demandez un objet JSON ou un JSON Schema lorsque la réponse sera utilisée par un logiciel plutôt que par une personne.

Définissez l’effort de raisonnement pour chaque requête uniquement pour les modèles qui déclarent cette capacité.

Exprimez les exigences d’exécution dans les préférences relatives aux fournisseurs et conservez le résultat réel à des fins d’observabilité.

Séparez le contexte récurrent afin qu’un client puisse utiliser une mise en cache compatible lorsque le modèle choisi la prend en charge.

Récupérez des sources récentes au moyen d’une fonction `web_search` exécutée par le client et conservez les liens séparément du texte généré.

Téléversez un fichier au moyen d’une opération dédiée, conservez son ID et transmettez une référence dans une requête compatible ultérieure.

Créez des images via une seule route et sélectionnez les paramètres selon les capacités du modèle choisi.

Lancez la création de la vidéo comme une tâche asynchrone, conservez son ID et séparez la création de la lecture du résultat.

Utilisez des opérations distinctes pour la synthèse vocale, la transcription et l’entrée audio d’un modèle.

Transformez du texte ou des entrées compatibles en vecteurs pour la recherche, le regroupement et les recommandations.

Réordonnez un petit ensemble de candidats par rapport à une requête afin d’améliorer la précision de la récupération finale.

Traitez les opérations indépendantes en groupes contrôlés lorsque le flux de travail permet une livraison asynchrone.

Connectez un client d’IA aux outils, ressources et prompts autorisés au moyen d’une URL de connexion émise dans les réglages du compte.

Construisez le traitement autour du statut HTTP, d’un corps d’erreur structuré et de l’ID de requête, plutôt qu’autour du texte du message.