Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue les faits fournis au regard de questions fermées et renvoie des réponses numériques typées plutôt qu’une réponse rédigée ouverte. Une requête combine un état unique avec des questions nommées, et le résultat identifie chaque réponse par le nom de la question correspondante. Un flux de travail dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille d’évaluation à exploiter, l’action à mener sur ce résultat restant du ressort de l’application.
L’état est l’information sur laquelle portent toutes les questions. Drex accepte une valeur JSON de type chaîne, objet, tableau, nombre, booléen ou null, le champ state étant obligatoire. Fournissez des éléments probants significatifs, même si null passe la validation de l’éditeur. Une chaîne convient à un message, un document ou une transcription ; un objet convient à des faits déjà organisés en champs. Conservez les informations qui influent sur la décision et omettez les champs sans rapport lorsque le contenu est long. Maintenez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car modifier la représentation peut modifier la réponse.
Drex 1.5 lit uniquement du texte. L’interface documentée rejette les contenus image, audio, vidéo et PDF dans l’état comme dans les questions, y compris les médias encodés et les objets de contenu multimédia. Préparez une légende, le texte reconnu d’un document ou une transcription avant d’utiliser ce contenu comme élément probant. Une adresse sous forme de texte n’est pas un document ou une image récupérés : le modèle ne peut pas l’ouvrir. Pour une demande d’assistance, l’état utile est le message réel et le contexte pertinent, et non une référence à un contenu que le modèle n’a pas reçu.
Une question noul demande si une condition est remplie et renvoie un nombre compris entre 0 et 1 représentant la probabilité estimée de oui. Définissez la question au moyen d’instructions non vides ou d’au moins un critère vrai/faux non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si la lenteur compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le flux de travail consommateur choisit comment interpréter la probabilité.
Une question de choix sélectionne une étiquette fournie dans un ensemble non ordonné et renvoie une probabilité pour chaque étiquette. Les critères forment un objet dont les clés sont les étiquettes renvoyées, chaque description étant une chaîne ou null. Utilisez des clés courtes et stables et décrivez clairement les frontières entre catégories. Une tâche de routage illustrative peut distinguer un problème d’accès, un défaut du produit et une question générale, avec une catégorie other pour les messages qui ne correspondent à aucune d’elles. L’étiquette sélectionnée est utile pour le routage ; la distribution aide à repérer les cas où deux options restent difficiles à départager.
Une question de score utilise un tableau ordonné d’étiquettes de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de niveau multipliés par leur probabilité. Il peut donc se situer entre deux niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème cosmétique, un problème disposant d’une solution de contournement et une tâche totalement bloquée. Le résultat comprend la légende des niveaux et les probabilités ainsi que le score attendu. Conservez le score fractionnaire pour les moyennes ou les tendances ; sélectionner le niveau le plus probable et arrondir le score attendu répondent à des questions différentes.
L’éditeur autorise entre une et 512 questions sur le même état. Donnez à chacune un identifiant non vide et explicite, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans avoir à retrouver une question numérotée. Séparez les préoccupations indépendantes en questions distinctes plutôt que de combiner plusieurs exigences dans un critère flou. Un seul message peut étayer un choix de catégorie, un score de gravité et une vérification de condition, chacun conservant sa propre signification.
Les réponses de choix et de score comportent une confiance distincte de leurs distributions de probabilités. L’éditeur distingue explicitement la confiance de la probabilité de l’option la plus élevée ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue retenue. Pour un choix incertain, examinez les probabilités concurrentes au lieu de considérer la seule étiquette gagnante comme une preuve de certitude. Définissez les seuils de revue en fonction des conséquences d’un faux positif ou d’un faux négatif et évaluez-les à l’aide de cas étiquetés représentatifs.
Drex 1.5 documente une capacité d’état de 131 072 tokens et une capacité par ligne de 139 264 tokens. La capacité par ligne porte sur l’état plus la question individuelle la plus longue, instructions et options comprises ; il ne s’agit pas de la somme de toutes les questions de la requête. L’état et les questions sérialisés doivent également tenir ensemble dans 1 048 576 octets UTF-8. Une requête peut respecter la limite en octets tout en dépassant une limite en tokens. L’ancienne édition 1.0 indique séparément 32 768 tokens pour l’état comme pour la ligne ; ses limites ne doivent donc pas être reportées sur la 1.5.
Nace documente drex-v1.5 comme un identifiant versionné de l’éditeur, tandis que drex-latest est un alias évolutif. Indiquez explicitement l’édition visée lorsqu’un flux de travail dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent un problème de validation qui appelle une entrée corrigée, et non une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et conservez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi exploitable pour le routage, la priorisation ou la revue, sans confondre une probabilité avec un verdict garanti.
", "aboutText": "Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue les faits fournis au regard de questions fermées et renvoie des réponses numériques typées plutôt qu’une réponse rédigée ouverte. Une requête combine un état unique avec des questions nommées, et le résultat identifie chaque réponse par le nom de la question correspondante. Un flux de travail dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille d’évaluation à exploiter, l’action à mener sur ce résultat restant du ressort de l’application.\n\n### Préparer l’état\n\nL’état est l’information sur laquelle portent toutes les questions. Drex accepte une valeur JSON de type chaîne, objet, tableau, nombre, booléen ou null, le champ state étant obligatoire. Fournissez des éléments probants significatifs, même si null passe la validation de l’éditeur. Une chaîne convient à un message, un document ou une transcription ; un objet convient à des faits déjà organisés en champs. Conservez les informations qui influent sur la décision et omettez les champs sans rapport lorsque le contenu est long. Maintenez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car modifier la représentation peut modifier la réponse.\n\nDrex 1.5 lit uniquement du texte. L’interface documentée rejette les contenus image, audio, vidéo et PDF dans l’état comme dans les questions, y compris les médias encodés et les objets de contenu multimédia. Préparez une légende, le texte reconnu d’un document ou une transcription avant d’utiliser ce contenu comme élément probant. Une adresse sous forme de texte n’est pas un document ou une image récupérés : le modèle ne peut pas l’ouvrir. Pour une demande d’assistance, l’état utile est le message réel et le contexte pertinent, et non une référence à un contenu que le modèle n’a pas reçu.\n\n### Probabilité oui/non, choix ou score\n\nUne question noul demande si une condition est remplie et renvoie un nombre compris entre 0 et 1 représentant la probabilité estimée de oui. Définissez la question au moyen d’instructions non vides ou d’au moins un critère vrai/faux non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si la lenteur compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le flux de travail consommateur choisit comment interpréter la probabilité.\n\nUne question de choix sélectionne une étiquette fournie dans un ensemble non ordonné et renvoie une probabilité pour chaque étiquette. Les critères forment un objet dont les clés sont les étiquettes renvoyées, chaque description étant une chaîne ou null. Utilisez des clés courtes et stables et décrivez clairement les frontières entre catégories. Une tâche de routage illustrative peut distinguer un problème d’accès, un défaut du produit et une question générale, avec une catégorie other pour les messages qui ne correspondent à aucune d’elles. L’étiquette sélectionnée est utile pour le routage ; la distribution aide à repérer les cas où deux options restent difficiles à départager.\n\nUne question de score utilise un tableau ordonné d’étiquettes de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de niveau multipliés par leur probabilité. Il peut donc se situer entre deux niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème cosmétique, un problème disposant d’une solution de contournement et une tâche totalement bloquée. Le résultat comprend la légende des niveaux et les probabilités ainsi que le score attendu. Conservez le score fractionnaire pour les moyennes ou les tendances ; sélectionner le niveau le plus probable et arrondir le score attendu répondent à des questions différentes.\n\n### Éléments partagés et lecture du résultat\n\nL’éditeur autorise entre une et 512 questions sur le même état. Donnez à chacune un identifiant non vide et explicite, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans avoir à retrouver une question numérotée. Séparez les préoccupations indépendantes en questions distinctes plutôt que de combiner plusieurs exigences dans un critère flou. Un seul message peut étayer un choix de catégorie, un score de gravité et une vérification de condition, chacun conservant sa propre signification.\n\nLes réponses de choix et de score comportent une confiance distincte de leurs distributions de probabilités. L’éditeur distingue explicitement la confiance de la probabilité de l’option la plus élevée ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue retenue. Pour un choix incertain, examinez les probabilités concurrentes au lieu de considérer la seule étiquette gagnante comme une preuve de certitude. Définissez les seuils de revue en fonction des conséquences d’un faux positif ou d’un faux négatif et évaluez-les à l’aide de cas étiquetés représentatifs.\n\n### Limites de version et de taille\n\nDrex 1.5 documente une capacité d’état de 131 072 tokens et une capacité par ligne de 139 264 tokens. La capacité par ligne porte sur l’état plus la question individuelle la plus longue, instructions et options comprises ; il ne s’agit pas de la somme de toutes les questions de la requête. L’état et les questions sérialisés doivent également tenir ensemble dans 1 048 576 octets UTF-8. Une requête peut respecter la limite en octets tout en dépassant une limite en tokens. L’ancienne édition 1.0 indique séparément 32 768 tokens pour l’état comme pour la ligne ; ses limites ne doivent donc pas être reportées sur la 1.5.\n\nNace documente drex-v1.5 comme un identifiant versionné de l’éditeur, tandis que drex-latest est un alias évolutif. Indiquez explicitement l’édition visée lorsqu’un flux de travail dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent un problème de validation qui appelle une entrée corrigée, et non une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et conservez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi exploitable pour le routage, la priorisation ou la revue, sans confondre une probabilité avec un verdict garanti.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "aa3465518f1cecca9e68e8d903df586436456d9dd6a1ec1cb4e4b5ceb549f9ff", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "nace-ai/drex-v1.5Drex 1.5 évalue un texte ou un JSON fourni au regard de questions typées et renvoie des probabilités, une étiquette choisie ou un score fractionnaire sur une grille d’évaluation. Nace.AI documente des décisions portant uniquement sur du texte pour la classification, le routage et la priorisation, avec des limites d’état et de requête propres à chaque version.
Cette description présente les capacités du modèle. Les entrées, sorties et options disponibles dans Ailoot pour la méthode sélectionnée figurent ci-dessous.
Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue les faits fournis au regard de questions fermées et renvoie des réponses numériques typées plutôt qu’une réponse rédigée ouverte. Une requête combine un état unique avec des questions nommées, et le résultat identifie chaque réponse par le nom de la question correspondante. Un flux de travail dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille d’évaluation à exploiter, l’action à mener sur ce résultat restant du ressort de l’application.
L’état est l’information sur laquelle portent toutes les questions. Drex accepte une valeur JSON de type chaîne, objet, tableau, nombre, booléen ou null, le champ state étant obligatoire. Fournissez des éléments probants significatifs, même si null passe la validation de l’éditeur. Une chaîne convient à un message, un document ou une transcription ; un objet convient à des faits déjà organisés en champs. Conservez les informations qui influent sur la décision et omettez les champs sans rapport lorsque le contenu est long. Maintenez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car modifier la représentation peut modifier la réponse.
Drex 1.5 lit uniquement du texte. L’interface documentée rejette les contenus image, audio, vidéo et PDF dans l’état comme dans les questions, y compris les médias encodés et les objets de contenu multimédia. Préparez une légende, le texte reconnu d’un document ou une transcription avant d’utiliser ce contenu comme élément probant. Une adresse sous forme de texte n’est pas un document ou une image récupérés : le modèle ne peut pas l’ouvrir. Pour une demande d’assistance, l’état utile est le message réel et le contexte pertinent, et non une référence à un contenu que le modèle n’a pas reçu.
Une question noul demande si une condition est remplie et renvoie un nombre compris entre 0 et 1 représentant la probabilité estimée de oui. Définissez la question au moyen d’instructions non vides ou d’au moins un critère vrai/faux non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si la lenteur compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le flux de travail consommateur choisit comment interpréter la probabilité.
Une question de choix sélectionne une étiquette fournie dans un ensemble non ordonné et renvoie une probabilité pour chaque étiquette. Les critères forment un objet dont les clés sont les étiquettes renvoyées, chaque description étant une chaîne ou null. Utilisez des clés courtes et stables et décrivez clairement les frontières entre catégories. Une tâche de routage illustrative peut distinguer un problème d’accès, un défaut du produit et une question générale, avec une catégorie other pour les messages qui ne correspondent à aucune d’elles. L’étiquette sélectionnée est utile pour le routage ; la distribution aide à repérer les cas où deux options restent difficiles à départager.
Une question de score utilise un tableau ordonné d’étiquettes de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de niveau multipliés par leur probabilité. Il peut donc se situer entre deux niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème cosmétique, un problème disposant d’une solution de contournement et une tâche totalement bloquée. Le résultat comprend la légende des niveaux et les probabilités ainsi que le score attendu. Conservez le score fractionnaire pour les moyennes ou les tendances ; sélectionner le niveau le plus probable et arrondir le score attendu répondent à des questions différentes.
L’éditeur autorise entre une et 512 questions sur le même état. Donnez à chacune un identifiant non vide et explicite, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans avoir à retrouver une question numérotée. Séparez les préoccupations indépendantes en questions distinctes plutôt que de combiner plusieurs exigences dans un critère flou. Un seul message peut étayer un choix de catégorie, un score de gravité et une vérification de condition, chacun conservant sa propre signification.
Les réponses de choix et de score comportent une confiance distincte de leurs distributions de probabilités. L’éditeur distingue explicitement la confiance de la probabilité de l’option la plus élevée ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue retenue. Pour un choix incertain, examinez les probabilités concurrentes au lieu de considérer la seule étiquette gagnante comme une preuve de certitude. Définissez les seuils de revue en fonction des conséquences d’un faux positif ou d’un faux négatif et évaluez-les à l’aide de cas étiquetés représentatifs.
Drex 1.5 documente une capacité d’état de 131 072 tokens et une capacité par ligne de 139 264 tokens. La capacité par ligne porte sur l’état plus la question individuelle la plus longue, instructions et options comprises ; il ne s’agit pas de la somme de toutes les questions de la requête. L’état et les questions sérialisés doivent également tenir ensemble dans 1 048 576 octets UTF-8. Une requête peut respecter la limite en octets tout en dépassant une limite en tokens. L’ancienne édition 1.0 indique séparément 32 768 tokens pour l’état comme pour la ligne ; ses limites ne doivent donc pas être reportées sur la 1.5.
Nace documente drex-v1.5 comme un identifiant versionné de l’éditeur, tandis que drex-latest est un alias évolutif. Indiquez explicitement l’édition visée lorsqu’un flux de travail dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent un problème de validation qui appelle une entrée corrigée, et non une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et conservez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi exploitable pour le routage, la priorisation ou la revue, sans confondre une probabilité avec un verdict garanti.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites nace-ai/drex-v1.5 | Par défaut— |
Champprovider | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions | Typeobject | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champsession_id | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champstate | Typeschema | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champtrace | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champuser | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions.<id>.type | Typestring | ExigenceObligatoire | Valeurs et limites noul, choice, score | Par défaut— |
Champquestions.<id>.instructions | Typestring|object|array | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champquestions.<id>.criteria | Typeobject|array | ExigenceFacultatif | Valeurs et limites Conditions: choice/score : obligatoires ; noul : facultatif. Les critères de choice forment un objet ; score est un tableau avec minItems égal à 1. | Par défaut— |
Champquestions.<id>.criteria.true | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
Champquestions.<id>.criteria.false | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
noul · Obligatoire : state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatoire : state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatoire : state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, state, questions |
Paramètrematerial_types | Contrattext |
Paramètreoptional_controls | Contratprovider, session_id, trace, user |
Paramètremultimodal_input_binding | Contratnull |
Cycle de vie : synchronous
Envoyez l’identifiant exact du modèle et conservez la réponse native complète.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
Associez chaque coût aux conditions indiquées. Utilisez un seul tarif pour chaque ensemble de configurations alternatives.
| Configuration | Barème tarifaire | Tokens de contexte, plus de | Tokens de contexte, jusqu’à la limite incluse | Coût |
|---|---|---|---|---|
| ConfigurationTarifs de base des tokens | Barème tarifaireTarif de base | Tokens de contexte, plus de— | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.00008 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
| ConfigurationPalier 1 de longueur de requête | Barème tarifaire— | Tokens de contexte, plus de0 | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.00008 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
{\n "model": "nace-ai/drex-v1.5",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='nace-ai/drex-v1.5'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Conservez chaque réponse, fichier et partie de contenu renvoyés dans leur intégralité.
Chaque réponse fournie pour un identifiant de question est conservée avec son type exact, sa valeur noul/choice/score, son degré de confiance, ses probabilités et sa légende. L’intégralité du JSON d’origine est enregistrée et renvoyée uniquement après le règlement.
Conservez l’opération d’origine et la réponse complète ou partielle ; ne rejouez pas le POST.
| Champ | Type |
|---|---|
Champmodel | Typestring |
Champid | Typestring |
Champprovider | Typestring |
Champanswers.<id>.type | Typestring |
Champanswers.<id>.noul | Typenumber |
Champanswers.<id>.choice | Typestring |
Champanswers.<id>.score | Typenumber |
Champanswers.<id>.confidence | Typenumber |
Champanswers.<id>.probabilities | Typeobject |
Champanswers.<id>.legend | Typeobject |
Champusage.input_tokens | Typeinteger |
Champusage.output_tokens | Typeinteger |
Champusage.cost | Typenumber |
| Réponse | Condition | Étape suivante |
|---|---|---|
Réponse400 · invalid_request_error | ConditionChamp obligatoire, représentation ou valeur non valide | Étape suivanteCorrigez le champ de requête indiqué. |
Ailoot Ultra nace-ai/drex-v1.5
Utilisez les chemins de méthode indiqués ci-dessus.