Note de l’auteur : si curl fonctionne mais que votre client renvoie une erreur 401, 404 ou 400, ou ne parvient pas à se connecter, suivez ces 7 points de contrôle dans l’ordre. Un tableau des codes d’erreur et une checklist de diagnostic en 10 minutes sont inclus.
Avec la même clé et le même modèle, une requête curl renvoie un code 200, mais Cherry Studio, Chatbox, Cursor, Cline, Claude Code ou Codex CLI affiche une erreur 401, 404 ou 400, ou encore expire ou renvoie une réponse vide. Dans ce cas, vérifiez d’abord la configuration du client plutôt que de changer de clé. Le succès de curl montre déjà que la clé est valide et que le réseau est accessible. Le problème vient probablement d’un décalage entre la requête réellement envoyée par le client et celle que vous pensez envoyer.
L’ordre de vérification recommandé est le suivant : Base URL → protocole et endpoint → en-tête d’authentification → ID du modèle → corps de la requête → réseau. Avant cela, vérifiez aussi que le client a bien pris en compte votre configuration modifiée. Cet article décompose le parcours de la requête en 7 points de contrôle, chacun présenté selon le même schéma : symptômes, causes, vérification et correction. L’objectif est de déterminer en 10 minutes si le problème vient du client, de la passerelle ou du service en amont.
Ce n’est pas un énième article sur les principes des API : c’est un guide de dépannage à suivre pas à pas.
Pourquoi curl fonctionne alors que le client ne se connecte pas : les points clés à vérifier
curl ne vérifie qu’une petite partie de la chaîne : la résolution DNS, la négociation TLS, l’accessibilité réseau, la validité de la clé et la disponibilité du seul point de terminaison appelé manuellement. Il ne vérifie pas si le client a bien chargé la configuration modifiée, comment il construit la Base URL, ni si les en-têtes et le corps de sa requête correspondent à ceux de curl.
Une requête envoyée par le client suit généralement ce chemin : configuration du client (variables d’environnement, fichier de configuration, interface graphique) → construction de la Base URL → protocole et point de terminaison → en-tête d’authentification → ID et correspondance du modèle → corps de la requête (messages, outils, multimodal, streaming) → proxy, TLS, réseau → passerelle → modèle en amont. Si curl fonctionne, cela signifie seulement que le chemin que vous avez défini manuellement fonctionne. Le client peut très bien en emprunter un autre.
| Point à vérifier | Symptôme typique | Vérification prioritaire |
|---|---|---|
| 1. Chargement de la configuration | Les modifications n’ont aucun effet, l’erreur reste la même | Examiner l’URL réelle de la requête dans les journaux du client |
| 2. Construction de la Base URL | Erreur 404, présence de /v1/v1 ou de // dans le chemin |
Comparer l’URL des journaux avec celle de curl |
| 3. Protocole et point de terminaison | Erreur 404 ou 400, échec de l’analyse du format de réponse | Vérifier le protocole utilisé par le client |
| 4. En-tête d’authentification | Erreur 401 alors que la clé fonctionne avec curl | Comparer les en-têtes des requêtes |
| 5. ID du modèle | Erreur 404 ou 400 indiquant que le modèle n’existe pas | Comparer caractère par caractère avec la liste des modèles de la passerelle |
| 6. Corps de la requête | Le texte seul fonctionne, mais l’ajout d’images ou d’outils provoque une erreur 400 | Ajouter les éléments progressivement pour reproduire le problème |
| 7. Réseau et streaming | Délai dépassé, stream disconnected, réponse vide | Désactiver le streaming pour comparer et vérifier le proxy |
Dépannage du service proxy API, points 1 et 2 : lecture de la configuration et assemblage de la Base URL
Point 1 : le client lit-il vraiment la configuration modifiée ?
Symptôme : vous avez remplacé la Base URL et la clé API, mais l’erreur reste exactement la même. Ou bien tout fonctionne dans un projet, mais pas dans un autre.
Cause : la plupart des clients peuvent lire leur configuration à plusieurs endroits. Par exemple, les paramètres de l’interface graphique peuvent prendre le dessus sur les variables d’environnement ; le fichier de configuration peut contenir plusieurs profils, et celui qui est actif n’est pas celui que vous avez modifié ; la configuration du projet peut remplacer la configuration globale ; ou encore un ancien processus peut toujours utiliser les valeurs chargées à son démarrage. Ce dernier cas est fréquent avec les outils en ligne de commande : vous modifiez une variable d’environnement dans le terminal, mais un IDE ou un processus d’agent déjà en cours d’exécution ne voit pas le changement.
Comment vérifier : consultez les journaux du client ou sa sortie de débogage et vérifiez que l’URL réellement utilisée et les premiers caractères de la clé API correspondent aux nouvelles valeurs. Si les journaux sont difficiles à consulter, remplacez temporairement la Base URL par une adresse manifestement incorrecte et regardez si l’erreur change : vous saurez ainsi si la configuration est prise en compte.
Comment corriger : commencez par vérifier l’ordre de priorité des configurations du client. En général, les paramètres de l’interface graphique ou du projet priment sur le fichier de configuration global, qui prime lui-même sur les variables d’environnement. Les règles varient toutefois d’un client à l’autre : consultez sa documentation. Modifiez ensuite uniquement la configuration la plus prioritaire, supprimez les valeurs contradictoires ailleurs, puis quittez complètement le processus du client avant de le redémarrer.
Point 2 : barre oblique finale, /v1 en double et préfixe de chemin dans la Base URL
Symptôme : vous obtenez une erreur 404 et l’URL dans les journaux contient /v1/v1/chat/completions, //chat/completions ou encore /v1/chat/completions/chat/completions.
Cause : les clients n’interprètent pas tous le champ Base URL de la même façon. Certains attendent l’adresse racine et ajoutent eux-mêmes /v1 ; d’autres attendent une adresse se terminant par /v1, puis ajoutent /chat/completions ; d’autres encore proposent deux champs distincts pour la Base URL et l’endpoint complet. Si vous saisissez https://api.apiyi.com/v1/chat/completions en entier dans un champ qui n’accepte qu’un préfixe, ou si vous ajoutez une barre oblique à une adresse qui contient déjà /v1, le chemin assemblé sera incorrect.
Comment vérifier : comparez caractère par caractère l’URL complète de la requête dans les journaux avec celle utilisée dans votre commande curl. Vérifiez surtout le nombre d’occurrences de /v1, la présence éventuelle d’une double barre oblique et l’ajout de segments de chemin en trop à la fin.
Comment corriger : renseignez l’adresse comme indiqué dans la documentation du client. Pour les clients compatibles avec OpenAI, on utilise généralement https://api.apiyi.com/v1, sans barre oblique finale. Si le client ajoute automatiquement /v1, retirez celui que vous avez saisi. Après la modification, vérifiez à nouveau l’URL dans les journaux : le chemin final doit respecter une forme standard comme https://api.apiyi.com/v1/chat/completions.
🎯 Conseil de configuration : l’adresse d’accès compatible avec OpenAI d’APIYI (apiyi.com) est
https://api.apiyi.com/v1, dans le même format que pour le SDK officiel OpenAI. Vous pouvez consulter la liste des modèles disponibles dans la console ou l’obtenir via l’interface de liste des modèles avec la même Base URL. Servez-vous-en d’abord pour confirmer que la clé API et l’adresse sont correctes, puis configurez le client.
Dépannage d’un service proxy API, points 3 et 4 : points de terminaison et en-têtes d’authentification
Point de contrôle 3 : le protocole et le point de terminaison correspondent-ils ?
Symptôme : la Base URL semble correcte, mais vous obtenez une erreur 404 ou 400. Ou encore, la requête aboutit, mais le client signale qu’il ne peut pas analyser la réponse ou renvoie un contenu vide.
Cause : les interfaces des grands modèles de langage utilisent aujourd’hui plusieurs protocoles. Votre client ne prend en charge que Chat Completions, mais vous le dirigez vers un point de terminaison qui ne propose que Responses. Claude Code utilise le protocole Anthropic Messages, et non OpenAI Chat Completions. Les chemins et les corps de requête diffèrent aussi complètement entre le format natif de Gemini et le format compatible OpenAI. Dans curl, vous avez saisi manuellement le bon point de terminaison, mais le client peut envoyer la requête selon son propre protocole par défaut.
| Type de protocole | Chemin typique du point de terminaison | Clients courants | Authentification |
|---|---|---|---|
| OpenAI Chat Completions | /v1/chat/completions |
De nombreux clients, comme Cherry Studio, Chatbox et Cline | Authorization: Bearer |
| OpenAI Responses | /v1/responses |
Outils récents de l’écosystème OpenAI | Authorization: Bearer |
| Anthropic Messages | /v1/messages |
Outils natifs Anthropic, comme Claude Code | x-api-key et anthropic-version |
| Gemini natif | Interface native dont le chemin contient le nom du modèle | SDK natif Gemini | Consultez la documentation officielle et celle de la passerelle |
Comment vérifier : dans les journaux du client, regardez la dernière partie du chemin de la requête pour déterminer le protocole utilisé. Vérifiez ensuite que le point de terminaison de la passerelle choisi prend en charge ce protocole. Si le client propose une liste déroulante « type de fournisseur » ou « format d’API », assurez-vous que l’option sélectionnée correspond au protocole souhaité.
Comment corriger : assurez-vous que le type de protocole du client, la Base URL et le modèle sont cohérents. Pour le format compatible OpenAI, choisissez un fournisseur de type OpenAI. Configurez les outils natifs comme Claude Code selon le protocole Anthropic. Si vous avez besoin des fonctionnalités natives de Gemini, utilisez le format Gemini. APIYI prend en charge à la fois le format compatible OpenAI et les formats d’API natifs comme Claude et Gemini. Pour connaître les adresses de connexion propres à chaque format natif, consultez la documentation sur docs.apiyi.com : ne composez pas les chemins de mémoire.
Point de contrôle 4 : les en-têtes d’authentification correspondent-ils au protocole ?
Symptôme : vous obtenez une erreur 401, alors que la même clé fonctionne parfaitement avec curl.
Cause : les interfaces compatibles OpenAI utilisent généralement Authorization: Bearer <Key> ; l’interface native Anthropic utilise généralement x-api-key avec anthropic-version ; certaines plateformes exigent aussi des en-têtes liés à l’organisation ou au projet. Dans curl, vous avez indiqué les bons en-têtes, mais le client a peut-être envoyé d’autres en-têtes selon un protocole différent, ou ajouté un en-tête d’organisation que la passerelle ne reconnaît pas, ce qui provoque l’échec de l’authentification.
Comment vérifier : comparez les en-têtes de curl avec ceux des journaux du client, en examinant notamment Authorization, x-api-key, Content-Type et OpenAI-Beta. Vérifiez aussi qu’il n’y a pas d’espaces, de retours à la ligne ou de guillemets en trop avant ou après la clé : c’est fréquent lors d’un copier-coller depuis une page Web.
Comment corriger : les en-têtes d’authentification dépendent du protocole. Si le bon protocole est sélectionné, la plupart des clients envoient automatiquement les bons en-têtes. Si le client permet de personnaliser les en-têtes, supprimez ceux liés à l’organisation ou au projet qui ne sont pas nécessaires. Collez à nouveau la clé en vérifiant qu’elle ne contient aucun caractère superflu.
Dépannage d’un service proxy API, points 5 à 7 : ID de modèle, corps de requête et flux réseau
Point de contrôle 5 : ID et correspondance des modèles
Symptôme : une erreur 404 ou 400 indique que le modèle n’existe pas ou n’est pas valide. Il arrive aussi qu’un seul modèle échoue alors que les autres fonctionnent.
Cause : l’ID du modèle doit correspondre exactement à celui de la liste de la passerelle. Les différences courantes concernent les majuscules et minuscules, les suffixes de version, les préfixes (par exemple sous la forme provider/model) et les alias. Un même modèle peut porter des noms différents selon la plateforme. Il se peut aussi que la liste de modèles intégrée au client ne contienne pas l’ID recherché : le client le remplace alors discrètement par une valeur par défaut.
Comment vérifier : copiez l’ID depuis l’interface de liste des modèles de la passerelle ou depuis sa console, puis comparez-le caractère par caractère au champ model du corps de la requête dans les journaux du client. Si un seul modèle échoue, vérifiez d’abord que son ID correspond au point de terminaison, puis que votre compte est autorisé à l’utiliser.
Comment corriger : ajoutez manuellement un modèle personnalisé dans le client et collez directement l’ID fourni par la passerelle, sans le saisir à la main. Si le client effectue une correspondance entre modèles, vérifiez que le nom obtenu est correct.
💡 Conseil pour les ID de modèles : si vous utilisez APIYI apiyi.com pour accéder aux modèles OpenAI, Claude, Gemini, DeepSeek, Qwen et d’autres fournisseurs avec une seule clé API, référez-vous à la liste des modèles dans la console. Un même modèle peut avoir un nom différent selon la plateforme : le copier depuis la console est le moyen le plus simple d’éviter les erreurs. Consultez également la console et la documentation pour vérifier sa disponibilité.
Point de contrôle 6 : corps de la requête et format multimodal
Symptôme : les échanges en texte seul fonctionnent, mais une erreur 400 apparaît dès que vous envoyez une image, utilisez un outil ou activez un paramètre de raisonnement.
Cause : les problèmes de compatibilité du corps de la requête se situent généralement à ces endroits : structure du tableau multimodal content, syntaxe du champ image_url, absence d’un préfixe MIME comme data:image/png;base64, pour une image encodée en base64 ; format des champs d’appel d’outil non conforme au protocole utilisé ; exigences différentes selon les modèles pour max_tokens et max_completion_tokens ; paramètres de raisonnement acceptés uniquement par certains modèles. Les paramètres ne sont pas entièrement interchangeables d’un fournisseur à l’autre.
Comment vérifier : ajoutez les variables progressivement. Envoyez d’abord du texte seul. Si cela fonctionne, activez le streaming, puis ajoutez un appel d’outil et enfin le contenu multimodal. Faites un test après chaque ajout : l’étape où la requête commence à échouer vous indique le champ en cause. Le message d’erreur précise généralement le champ concerné : pensez à consulter la réponse d’erreur complète.
Comment corriger : désactivez les paramètres avancés inutiles dans le client et ajustez les champs selon la documentation du modèle cible. Pour les images, utilisez un préfixe base64 conforme ou une URL accessible. Définissez les outils au format du protocole utilisé.
Point de contrôle 7 : réseau, proxy, TLS et mise en mémoire tampon du streaming
Symptôme : délai de connexion dépassé, stream disconnected, réponse vide après une longue attente, ou encore requête non streaming fonctionnelle mais requête en streaming en échec.
Cause : le client utilise peut-être le proxy système ou un proxy défini par des variables d’environnement, contrairement à curl, ou inversement. Un pare-feu d’entreprise, la vérification des certificats TLS, la résolution IPv6 ou le DNS peuvent également empêcher le client de se connecter. En streaming, certains proxys mettent la réponse en mémoire tampon et attendent de l’avoir reçue en entier avant de la transmettre. Ne recevant aucune donnée, le client considère alors que le délai est dépassé ou que le flux est interrompu.
Comment vérifier : commencez par distinguer une « connexion non établie » d’un « flux interrompu ». Dans le premier cas, cherchez une erreur TLS ou de connexion ; dans le second, une partie du contenu a généralement déjà été reçue. Désactivez le streaming et réessayez : si la requête fonctionne sans streaming, le problème vient probablement de la mise en mémoire tampon du proxy ou des paramètres de délai d’attente. Vérifiez aussi que les variables d’environnement du proxy sont identiques dans le client et dans le terminal.
Comment corriger : harmonisez les paramètres de proxy du client et de curl ; excluez les proxys qui mettent les réponses en mémoire tampon pour les requêtes en streaming ; augmentez si nécessaire le délai d’attente du client. En cas d’interruption ponctuelle en amont, vous pouvez réessayer un nombre limité de fois ou passer temporairement à un autre modèle pour vérifier si le problème concerne un seul fournisseur en amont.
Bien démarrer avec un service proxy API : tableau des codes d’erreur et liste de vérification client
Face à une erreur, commencez par utiliser son code pour cerner le problème, puis vérifiez chaque point de la liste de configuration.
Tableau des codes d’erreur
| Code d’erreur | Causes fréquentes | À vérifier en priorité |
|---|---|---|
| 401 | Clé invalide, expirée ou désactivée ; format incorrect de l’en-tête ; organisation ou projet incorrect | Points de contrôle 1 et 4 |
| 403 | Clé valide, mais accès refusé par une politique liée au modèle, à l’organisation ou à la région ; liste blanche d’adresses IP ; modèle non activé | Point de contrôle 5, autorisations du compte |
| 404 | Chemin de la Base URL incorrect ; endpoint ou ID de modèle inexistant ; route non implémentée par la passerelle | Points de contrôle 2, 3 et 5 |
| 400 | Corps de requête, paramètres, ID de modèle ou champs multimodaux invalides ; paramètres incompatibles avec le fournisseur | Points de contrôle 5 et 6 |
| 429 | Limite de débit atteinte ou quota insuffisant | Vérifier Retry-After, espacer les tentatives ou changer de modèle |
| 500/502/503/529 | Erreur du service en amont ou de la passerelle ; 529 indique souvent une surcharge | Limiter les nouvelles tentatives et consulter les journaux de la passerelle |
| Délai dépassé, stream disconnected | Interruption du réseau, du proxy, de TLS ou du service en amont | Point de contrôle 7 |
Liste de vérification de la configuration client
| Point à vérifier | Questions à se poser |
|---|---|
| Source de la configuration | La modification concerne-t-elle une variable d’environnement, un fichier de configuration ou une interface graphique ? Quelle source est prioritaire ? Plusieurs profils ou configurations de projet se remplacent-ils ? |
| Base URL | Inclut-elle /v1 ? Le client ajoute-t-il automatiquement /v1 ? Y a-t-il une barre oblique en trop à la fin ? |
| Type d’endpoint | Chat Completions, Responses, ou API native Claude ou Gemini ? La version du client le prend-elle en charge ? |
| En-tête d’authentification | S’agit-il de Authorization: Bearer ou de x-api-key ? Faut-il aussi fournir anthropic-version ? |
| ID du modèle | Correspond-il exactement à la liste des modèles de la passerelle, y compris la casse et le préfixe ? |
| Corps de la requête | Contient-il des outils, des images ou des paramètres de raisonnement ? Le champ max_tokens est-il adapté au modèle cible ? |
| Streaming et réseau | Le streaming est-il activé ? Le proxy met-il les données en mémoire tampon ? Les paramètres de proxy du client et de curl sont-ils identiques ? |
Reproduire le problème avec une requête minimale
La méthode la plus efficace consiste à comparer deux requêtes en gardant les mêmes paramètres : une même Base URL, une même clé, un même modèle et un même corps de requête. Envoyez d’abord la requête avec curl, puis avec le client. Voici les étapes :
- Vérifiez la clé et la Base URL avec l’interface de liste des modèles, par exemple en interrogeant
https://api.apiyi.com/v1/models; - Vérifiez l’endpoint et l’ID du modèle avec une requête de chat minimale en texte brut ;
- Activez le streaming pour vérifier le réseau et le proxy ;
- Ajoutez un appel d’outil ou des éléments multimodaux pour vérifier le corps de la requête ;
- À chaque étape, consultez à la fois les journaux du client et ceux de la passerelle.
🚀 Conseil de dépannage : la console APIYI permet de consulter les statistiques d’utilisation et les journaux détaillés des appels. Si le client signale une erreur mais que la console ne contient aucune trace de l’appel, la requête n’a pas atteint la passerelle : le problème vient de la configuration du client ou du réseau local. Si un appel est enregistré avec un message d’erreur, les journaux permettent de déterminer s’il s’agit d’un problème de paramètres ou d’un problème en amont.
Questions fréquentes (FAQ)
Q1 : Si curl fonctionne mais que le client ne se connecte pas, est-ce utile de changer de clé API ?
En général, non. Si curl fonctionne, cela prouve que la clé API est valide. Quand un changement de clé semble résoudre le problème, c’est souvent parce que le client a été redémarré ou que le profil a changé en même temps, ce qui a rechargé la configuration. Plutôt que de changer de clé, quittez complètement le client, redémarrez-le, puis vérifiez dans les journaux l’URL de base et la clé API réellement utilisées. Vous pouvez aussi vérifier l’état de la clé et son historique d’utilisation dans la console APIYI pour voir si elle présente réellement un problème.
Q2 : Pourquoi l’endpoint /models fonctionne-t-il alors que les requêtes chat échouent ?
L’endpoint de liste des modèles vérifie seulement l’authentification et la validité de base de l’URL de base. Il ne teste ni l’endpoint chat, ni l’identifiant du modèle, ni le corps de la requête. Si chat ne fonctionne pas, vérifiez dans l’ordre : si le protocole utilisé par le client correspond à l’endpoint (point de contrôle 3), si l’identifiant du modèle correspond exactement à celui de la liste (point de contrôle 5), et si le corps de la requête contient des paramètres non pris en charge par le modèle cible (point de contrôle 6).
Q4 : Un seul modèle échoue alors que tous les autres fonctionnent. Que vérifier en premier ?
Vérifiez d’abord l’identifiant du modèle et l’endpoint, puis les autorisations du compte. Les différences de casse, de préfixe ou d’alias dans l’identifiant sont les causes les plus fréquentes. Le modèle peut aussi nécessiter un protocole différent, par exemple son format natif. Ce n’est qu’ensuite qu’il faut envisager un problème d’autorisation ou de disponibilité. Avec APIYI, une seule clé API permet de passer d’un fournisseur de modèles à un autre : testez temporairement un modèle similaire pour déterminer rapidement si le problème concerne un seul modèle ou l’ensemble de la configuration.
Q5 : Comment savoir si le problème vient du client ou de la passerelle ?
Deux points sont essentiels : la passerelle a-t-elle reçu la requête, et la même requête réussit-elle avec curl ? Si la passerelle n’a aucune trace de la requête, le problème vient probablement du client ou du réseau local. Si la même requête réussit avec curl mais échoue avec le client, le problème vient probablement de la construction de la requête par le client ou de son corps. Si la même requête échoue aussi avec curl et que les journaux affichent une erreur 5xx, contactez l’assistance de la passerelle.
En résumé : diagnostic d’un service proxy API en 10 minutes et recours à l’assistance
Si curl fonctionne mais que le client n’arrive pas à se connecter, ne changez pas tout de suite de clé API. Parcourez plutôt cette liste en 10 minutes :
- Consultez les journaux du client : récupérez l’URL, les en-têtes et le corps de la requête réellement envoyée, puis vérifiez que la configuration a bien été prise en compte ;
- Vérifiez l’URL de base :
/v1ne doit apparaître qu’une fois, sans double barre oblique ni segment de chemin répété ; - Vérifiez le protocole du point de terminaison : Chat Completions, Responses, Claude Messages ou Gemini natif doit correspondre au type de client ;
- Vérifiez l’en-tête d’authentification :
Authorization: Beareroux-api-key. Supprimez les en-têtes d’organisation superflus et les espaces autour de la clé API ; - Vérifiez l’ID du modèle : comparez-le caractère par caractère à la liste des modèles de la passerelle ;
- Envoyez une requête minimale : avec la même clé API, le même modèle et le même corps de requête, faites un essai avec curl et un autre avec le client pour comparer ;
- Activez le streaming : en cas d’échec, vérifiez la mise en mémoire tampon du proxy et les délais d’expiration ;
- Ajoutez des outils ou du contenu multimodal : en cas d’échec, vérifiez les champs du corps de la requête ;
- Concluez le diagnostic : à partir des journaux de la passerelle, déterminez si le problème vient du client ou de la passerelle.
Quand s’agit-il d’un bug du client ? La passerelle n’enregistre aucun appel, ou curl réussit avec exactement la même URL, les mêmes en-têtes et le même corps de requête alors que le client échoue. Vous avez aussi vérifié que la configuration est correcte et que la version du client prend en charge le point de terminaison utilisé. Dans ce cas, mettez le client à jour ou signalez le problème au projet qui le développe.
Quand contacter l’assistance de la passerelle ? La même requête minimale échoue aussi avec curl, et les journaux de la passerelle montrent un appel ayant renvoyé une erreur 5xx. Autre cas : un modèle renvoie continuellement une erreur, tandis que les autres fonctionnent, et vous avez écarté un problème d’ID de modèle ou d’autorisations. Pour accélérer le diagnostic, transmettez à l’assistance l’heure de la requête, l’ID du modèle, le code d’erreur et le message d’erreur figurant dans les journaux.
Pour les outils d’équipe qui doivent rester fiables, disposer de plusieurs modèles et voies d’accès aide aussi au diagnostic : si l’un d’eux présente une anomalie, un test comparatif avec un autre modèle permet de cerner rapidement le problème. APIYI apiyi.com donne accès, avec une seule clé API, au format compatible OpenAI ainsi qu’aux formats natifs de Claude et Gemini. Les données d’utilisation et les journaux de la console facilitent les vérifications. Consultez la console et la documentation pour connaître les prix et les disponibilités.
Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site APIYI
