Drex 1.5 är Nace.AI:s modell för textbeslut. Den utvärderar angivna fakta mot slutna frågor och returnerar numeriska, typade svar i stället för ett öppet skrivet svar. En begäran kombinerar ett tillstånd med namngivna frågor, och resultatet identifierar varje svar med samma frågenamn. Det ger ett arbetsflöde en konkret kategori, sannolikhet eller position på en bedömningsmatris att använda, medan åtgärden som vidtas utifrån resultatet lämnas åt applikationen.
Tillståndet är den information som alla frågor gäller. Drex accepterar en JSON-sträng, ett objekt, en array, ett tal, ett booleskt värde eller null, och fältet state är obligatoriskt. Ange meningsfullt underlag även om null passerar producentens validering. En sträng passar för ett meddelande, ett dokument eller en transkription; ett objekt passar för fakta som redan är ordnade i fält. Behåll den information som påverkar beslutet och utelämna orelaterade fält när materialet är långt. Behåll ett stabilt indataformat när du tolkar sannolikhetströsklar, eftersom en ändrad representation kan ändra svaret.
Drex 1.5 läser endast text. Det dokumenterade gränssnittet avvisar bild-, ljud-, video- och PDF-innehåll i både tillståndet och frågorna, inklusive kodade media och medieinnehållsobjekt. Förbered en bildtext, igenkänd dokumenttext eller en transkription innan materialet används som underlag. En textadress är inte ett hämtat dokument eller en hämtad bild: modellen kan inte öppna den. För en supportförfrågan är det användbara tillståndet det faktiska meddelandet och relevant kontext, inte en hänvisning till material som modellen inte har tagit emot.
En noul-fråga frågar om ett villkor är uppfyllt och returnerar ett tal från 0 till 1 som representerar den uppskattade sannolikheten för ja. Definiera frågan genom instruktioner som inte är tomma eller minst ett icke-tomt sant/falskt-kriterium. Fråga till exempel om ett meddelande rapporterar en trasig funktion och definiera om långsamt beteende räknas som trasigt. Drex har ingen inbyggd gräns för ja/nej; det mottagande arbetsflödet väljer hur sannolikheten ska tolkas.
En choice-fråga väljer en angiven etikett ur en oordnad mängd och returnerar en sannolikhet för varje etikett. Kriterierna är ett objekt vars nycklar är de returnerade etiketterna, där varje beskrivning är en sträng eller null. Använd korta, stabila nycklar och beskriv kategorigränserna tydligt. En illustrativ routningsuppgift kan skilja mellan ett åtkomstproblem, ett produktfel och en allmän fråga, med en övrigt-kategori för meddelanden som inte passar. Den valda etiketten är användbar för routning; fördelningen hjälper till att identifiera fall där två alternativ fortfarande är svåra att skilja åt.
En score-fråga använder en ordnad array av nivåetiketter. Indexen börjar på 0, och den returnerade poängen är summan av varje nivåindex multiplicerat med dess sannolikhet. Den kan därför hamna mellan namngivna nivåer. För en allvarlighetsskala definierar du vad som skiljer ett kosmetiskt problem, ett problem med en tillfällig lösning och en helt blockerad uppgift. Resultatet innehåller nivåförklaringen och sannolikheterna samt den förväntade poängen. Behåll decimalpoängen för medelvärden eller trender; att välja den mest sannolika nivån och att avrunda den förväntade poängen besvarar olika frågor.
Producenten tillåter mellan en och 512 frågor om samma tillstånd. Ge varje fråga en icke-tom, meningsfull identifierare, till exempel category eller severity, så att motsvarande svar kan förstås utan att man behöver slå upp en numrerad fråga. Dela upp oberoende frågeställningar i egna frågor i stället för att kombinera flera krav i ett oklart kriterium. Ett enda meddelande kan stödja ett kategorival, en allvarlighetspoäng och en villkorskontroll, där var och en behåller sin egen betydelse.
Svar på choice- och score-frågor innehåller konfidens separat från sina sannolikhetsfördelningar. Producenten skiljer uttryckligen konfidens från den högsta alternativsannolikheten; beräkna inte det ena utifrån det andra. För ett ja/nej-beslut behåller du den råa sannolikheten tillsammans med det valda utfallet. För ett osäkert val granskar du de konkurrerande sannolikheterna i stället för att behandla enbart den vinnande etiketten som belägg för säkerhet. Definiera granskningströsklar utifrån konsekvenserna av ett felaktigt positivt eller negativt resultat och använd representativa märkta fall för att bedöma dem.
Drex 1.5 dokumenterar ett utrymme på 131 072 token för tillståndet och 139 264 token per rad. Radutrymmet gäller tillståndet plus den längsta enskilda frågan, inklusive dess instruktioner och alternativ; det är inte summan av alla frågor i begäran. Det serialiserade tillståndet och frågorna måste dessutom tillsammans rymmas inom 1 048 576 UTF-8-byte. En begäran kan uppfylla bytegränsen och ändå överskrida en tokengräns. Den äldre utgåvan 1.0 anger separat 32 768 token för både tillstånd och rad, så dess gränser ska inte överföras till 1.5.
Nace dokumenterar drex-v1.5 som en versionerad producentidentifierare, medan drex-latest är ett rörligt alias. Håll den avsedda utgåvan explicit när ett arbetsflöde är beroende av dess gränser. En felformad fråga, ett saknat tillstånd eller för stor indata är ett valideringsproblem som kräver korrigerad indata, inte en ändrad kategori eller ett gissat svar. Utforma kriterierna kring observerbart underlag och behåll det typade resultatet, de ursprungliga fakta och frågedefinitionen tillsammans. Då blir beslutet användbart för routning, prioritering eller granskning utan att en sannolikhet misstas för ett garanterat avgörande.
", "aboutText": "Drex 1.5 är Nace.AI:s modell för textbeslut. Den utvärderar angivna fakta mot slutna frågor och returnerar numeriska, typade svar i stället för ett öppet skrivet svar. En begäran kombinerar ett tillstånd med namngivna frågor, och resultatet identifierar varje svar med samma frågenamn. Det ger ett arbetsflöde en konkret kategori, sannolikhet eller position på en bedömningsmatris att använda, medan åtgärden som vidtas utifrån resultatet lämnas åt applikationen.\n\n### Förbereda tillståndet\n\nTillståndet är den information som alla frågor gäller. Drex accepterar en JSON-sträng, ett objekt, en array, ett tal, ett booleskt värde eller null, och fältet state är obligatoriskt. Ange meningsfullt underlag även om null passerar producentens validering. En sträng passar för ett meddelande, ett dokument eller en transkription; ett objekt passar för fakta som redan är ordnade i fält. Behåll den information som påverkar beslutet och utelämna orelaterade fält när materialet är långt. Behåll ett stabilt indataformat när du tolkar sannolikhetströsklar, eftersom en ändrad representation kan ändra svaret.\n\nDrex 1.5 läser endast text. Det dokumenterade gränssnittet avvisar bild-, ljud-, video- och PDF-innehåll i både tillståndet och frågorna, inklusive kodade media och medieinnehållsobjekt. Förbered en bildtext, igenkänd dokumenttext eller en transkription innan materialet används som underlag. En textadress är inte ett hämtat dokument eller en hämtad bild: modellen kan inte öppna den. För en supportförfrågan är det användbara tillståndet det faktiska meddelandet och relevant kontext, inte en hänvisning till material som modellen inte har tagit emot.\n\n### Ja/nej-sannolikhet, val eller poäng\n\nEn noul-fråga frågar om ett villkor är uppfyllt och returnerar ett tal från 0 till 1 som representerar den uppskattade sannolikheten för ja. Definiera frågan genom instruktioner som inte är tomma eller minst ett icke-tomt sant/falskt-kriterium. Fråga till exempel om ett meddelande rapporterar en trasig funktion och definiera om långsamt beteende räknas som trasigt. Drex har ingen inbyggd gräns för ja/nej; det mottagande arbetsflödet väljer hur sannolikheten ska tolkas.\n\nEn choice-fråga väljer en angiven etikett ur en oordnad mängd och returnerar en sannolikhet för varje etikett. Kriterierna är ett objekt vars nycklar är de returnerade etiketterna, där varje beskrivning är en sträng eller null. Använd korta, stabila nycklar och beskriv kategorigränserna tydligt. En illustrativ routningsuppgift kan skilja mellan ett åtkomstproblem, ett produktfel och en allmän fråga, med en övrigt-kategori för meddelanden som inte passar. Den valda etiketten är användbar för routning; fördelningen hjälper till att identifiera fall där två alternativ fortfarande är svåra att skilja åt.\n\nEn score-fråga använder en ordnad array av nivåetiketter. Indexen börjar på 0, och den returnerade poängen är summan av varje nivåindex multiplicerat med dess sannolikhet. Den kan därför hamna mellan namngivna nivåer. För en allvarlighetsskala definierar du vad som skiljer ett kosmetiskt problem, ett problem med en tillfällig lösning och en helt blockerad uppgift. Resultatet innehåller nivåförklaringen och sannolikheterna samt den förväntade poängen. Behåll decimalpoängen för medelvärden eller trender; att välja den mest sannolika nivån och att avrunda den förväntade poängen besvarar olika frågor.\n\n### Gemensamt underlag och tolkning av resultatet\n\nProducenten tillåter mellan en och 512 frågor om samma tillstånd. Ge varje fråga en icke-tom, meningsfull identifierare, till exempel category eller severity, så att motsvarande svar kan förstås utan att man behöver slå upp en numrerad fråga. Dela upp oberoende frågeställningar i egna frågor i stället för att kombinera flera krav i ett oklart kriterium. Ett enda meddelande kan stödja ett kategorival, en allvarlighetspoäng och en villkorskontroll, där var och en behåller sin egen betydelse.\n\nSvar på choice- och score-frågor innehåller konfidens separat från sina sannolikhetsfördelningar. Producenten skiljer uttryckligen konfidens från den högsta alternativsannolikheten; beräkna inte det ena utifrån det andra. För ett ja/nej-beslut behåller du den råa sannolikheten tillsammans med det valda utfallet. För ett osäkert val granskar du de konkurrerande sannolikheterna i stället för att behandla enbart den vinnande etiketten som belägg för säkerhet. Definiera granskningströsklar utifrån konsekvenserna av ett felaktigt positivt eller negativt resultat och använd representativa märkta fall för att bedöma dem.\n\n### Version och storleksgränser\n\nDrex 1.5 dokumenterar ett utrymme på 131 072 token för tillståndet och 139 264 token per rad. Radutrymmet gäller tillståndet plus den längsta enskilda frågan, inklusive dess instruktioner och alternativ; det är inte summan av alla frågor i begäran. Det serialiserade tillståndet och frågorna måste dessutom tillsammans rymmas inom 1 048 576 UTF-8-byte. En begäran kan uppfylla bytegränsen och ändå överskrida en tokengräns. Den äldre utgåvan 1.0 anger separat 32 768 token för både tillstånd och rad, så dess gränser ska inte överföras till 1.5.\n\nNace dokumenterar drex-v1.5 som en versionerad producentidentifierare, medan drex-latest är ett rörligt alias. Håll den avsedda utgåvan explicit när ett arbetsflöde är beroende av dess gränser. En felformad fråga, ett saknat tillstånd eller för stor indata är ett valideringsproblem som kräver korrigerad indata, inte en ändrad kategori eller ett gissat svar. Utforma kriterierna kring observerbart underlag och behåll det typade resultatet, de ursprungliga fakta och frågedefinitionen tillsammans. Då blir beslutet användbart för routning, prioritering eller granskning utan att en sannolikhet misstas för ett garanterat avgörande.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "13626b868359ae15c1ac435b93879d25c87574efcb78b88aac1ac2e1facddec2", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "sv", "methods": [ { "html": "nace-ai/drex-v1.5Drex 1.5 utvärderar angiven text eller JSON mot typade frågor och returnerar sannolikheter, en vald etikett eller en decimalpoäng enligt en bedömningsmatris. Nace.AI dokumenterar beslut som enbart bygger på text för klassificering, routning och prioritering, med versionsspecifika gränser för tillstånd och begäran.
Den här beskrivningen omfattar modellens förmågor. Tillgängliga indata, utdata och alternativ i Ailoot anges nedan för den valda metoden.
Drex 1.5 är Nace.AI:s modell för textbeslut. Den utvärderar angivna fakta mot slutna frågor och returnerar numeriska, typade svar i stället för ett öppet skrivet svar. En begäran kombinerar ett tillstånd med namngivna frågor, och resultatet identifierar varje svar med samma frågenamn. Det ger ett arbetsflöde en konkret kategori, sannolikhet eller position på en bedömningsmatris att använda, medan åtgärden som vidtas utifrån resultatet lämnas åt applikationen.
Tillståndet är den information som alla frågor gäller. Drex accepterar en JSON-sträng, ett objekt, en array, ett tal, ett booleskt värde eller null, och fältet state är obligatoriskt. Ange meningsfullt underlag även om null passerar producentens validering. En sträng passar för ett meddelande, ett dokument eller en transkription; ett objekt passar för fakta som redan är ordnade i fält. Behåll den information som påverkar beslutet och utelämna orelaterade fält när materialet är långt. Behåll ett stabilt indataformat när du tolkar sannolikhetströsklar, eftersom en ändrad representation kan ändra svaret.
Drex 1.5 läser endast text. Det dokumenterade gränssnittet avvisar bild-, ljud-, video- och PDF-innehåll i både tillståndet och frågorna, inklusive kodade media och medieinnehållsobjekt. Förbered en bildtext, igenkänd dokumenttext eller en transkription innan materialet används som underlag. En textadress är inte ett hämtat dokument eller en hämtad bild: modellen kan inte öppna den. För en supportförfrågan är det användbara tillståndet det faktiska meddelandet och relevant kontext, inte en hänvisning till material som modellen inte har tagit emot.
En noul-fråga frågar om ett villkor är uppfyllt och returnerar ett tal från 0 till 1 som representerar den uppskattade sannolikheten för ja. Definiera frågan genom instruktioner som inte är tomma eller minst ett icke-tomt sant/falskt-kriterium. Fråga till exempel om ett meddelande rapporterar en trasig funktion och definiera om långsamt beteende räknas som trasigt. Drex har ingen inbyggd gräns för ja/nej; det mottagande arbetsflödet väljer hur sannolikheten ska tolkas.
En choice-fråga väljer en angiven etikett ur en oordnad mängd och returnerar en sannolikhet för varje etikett. Kriterierna är ett objekt vars nycklar är de returnerade etiketterna, där varje beskrivning är en sträng eller null. Använd korta, stabila nycklar och beskriv kategorigränserna tydligt. En illustrativ routningsuppgift kan skilja mellan ett åtkomstproblem, ett produktfel och en allmän fråga, med en övrigt-kategori för meddelanden som inte passar. Den valda etiketten är användbar för routning; fördelningen hjälper till att identifiera fall där två alternativ fortfarande är svåra att skilja åt.
En score-fråga använder en ordnad array av nivåetiketter. Indexen börjar på 0, och den returnerade poängen är summan av varje nivåindex multiplicerat med dess sannolikhet. Den kan därför hamna mellan namngivna nivåer. För en allvarlighetsskala definierar du vad som skiljer ett kosmetiskt problem, ett problem med en tillfällig lösning och en helt blockerad uppgift. Resultatet innehåller nivåförklaringen och sannolikheterna samt den förväntade poängen. Behåll decimalpoängen för medelvärden eller trender; att välja den mest sannolika nivån och att avrunda den förväntade poängen besvarar olika frågor.
Producenten tillåter mellan en och 512 frågor om samma tillstånd. Ge varje fråga en icke-tom, meningsfull identifierare, till exempel category eller severity, så att motsvarande svar kan förstås utan att man behöver slå upp en numrerad fråga. Dela upp oberoende frågeställningar i egna frågor i stället för att kombinera flera krav i ett oklart kriterium. Ett enda meddelande kan stödja ett kategorival, en allvarlighetspoäng och en villkorskontroll, där var och en behåller sin egen betydelse.
Svar på choice- och score-frågor innehåller konfidens separat från sina sannolikhetsfördelningar. Producenten skiljer uttryckligen konfidens från den högsta alternativsannolikheten; beräkna inte det ena utifrån det andra. För ett ja/nej-beslut behåller du den råa sannolikheten tillsammans med det valda utfallet. För ett osäkert val granskar du de konkurrerande sannolikheterna i stället för att behandla enbart den vinnande etiketten som belägg för säkerhet. Definiera granskningströsklar utifrån konsekvenserna av ett felaktigt positivt eller negativt resultat och använd representativa märkta fall för att bedöma dem.
Drex 1.5 dokumenterar ett utrymme på 131 072 token för tillståndet och 139 264 token per rad. Radutrymmet gäller tillståndet plus den längsta enskilda frågan, inklusive dess instruktioner och alternativ; det är inte summan av alla frågor i begäran. Det serialiserade tillståndet och frågorna måste dessutom tillsammans rymmas inom 1 048 576 UTF-8-byte. En begäran kan uppfylla bytegränsen och ändå överskrida en tokengräns. Den äldre utgåvan 1.0 anger separat 32 768 token för både tillstånd och rad, så dess gränser ska inte överföras till 1.5.
Nace dokumenterar drex-v1.5 som en versionerad producentidentifierare, medan drex-latest är ett rörligt alias. Håll den avsedda utgåvan explicit när ett arbetsflöde är beroende av dess gränser. En felformad fråga, ett saknat tillstånd eller för stor indata är ett valideringsproblem som kräver korrigerad indata, inte en ändrad kategori eller ett gissat svar. Utforma kriterierna kring observerbart underlag och behåll det typade resultatet, de ursprungliga fakta och frågedefinitionen tillsammans. Då blir beslutet användbart för routning, prioritering eller granskning utan att en sannolikhet misstas för ett garanterat avgörande.
POST /v1/systemonetextdecisions| Fält | Typ | Krav | Värden & gränser | Standard |
|---|---|---|---|---|
Fältmodel | Typstring | KravObligatoriskt | Värden & gränser nace-ai/drex-v1.5 | Standard— |
Fältprovider | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältquestions | Typobject | KravObligatoriskt | Värden & gränser | Standard— |
Fältsession_id | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältstate | Typschema | KravObligatoriskt | Värden & gränser | Standard— |
Fälttrace | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältuser | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältquestions.<id>.type | Typstring | KravObligatoriskt | Värden & gränser noul, choice, score | Standard— |
Fältquestions.<id>.instructions | Typstring|object|array | KravObligatoriskt | Värden & gränser | Standard— |
Fältquestions.<id>.criteria | Typobject|array | KravValfritt | Värden & gränser Villkor: choice/score: obligatoriskt; noul: valfritt. Kriterier för choice är ett objekt; score är en array med minItems1. | Standard— |
Fältquestions.<id>.criteria.true | Typstring|object|array | KravObligatoriskt | Värden & gränser Gäller när: Ett kriterieobjekt för noul har angetts | Standard— |
Fältquestions.<id>.criteria.false | Typstring|object|array | KravObligatoriskt | Värden & gränser Gäller när: Ett kriterieobjekt för noul har angetts | Standard— |
noul · Krävs: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Krävs: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Krävs: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Avtal |
|---|---|
Parametercontent_type | Avtalapplication/json |
Parameterrequired | Avtalmodel, state, questions |
Parametermaterial_types | Avtaltext |
Parameteroptional_controls | Avtalprovider, session_id, trace, user |
Parametermultimodal_input_binding | Avtalnull |
Livscykel: synchronous
Skicka det exakta modell-ID:t och behåll hela svaret i leverantörens format.
Tariffuppgifter lägger inte till begäransalternativ. Parametrar som stöds anges för den valda metoden.
Matcha varje avgift mot de visade villkoren. Använd ett pris för varje uppsättning alternativa konfigurationer.
| Konfiguration | Prislista | Kontexttoken, fler än | Kontexttoken, upp till och med | Avgift |
|---|---|---|---|---|
| KonfigurationGrundpriser för token | PrislistaGrundpris | Kontexttoken, fler än— | Kontexttoken, upp till och medIngen övre gräns | Avgift Indata · Indatatoken $0.00008 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
| KonfigurationNivå 1 för förfrågans längd | Prislista— | Kontexttoken, fler än0 | Kontexttoken, upp till och medIngen övre gräns | Avgift Indata · Indatatoken $0.00008 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
Ailoot reserverar ett uppskattat belopp före en begäran. Efter resultatet slutregleras avgiften utifrån uppmätt förbrukning. Slutreglering för strömning använder den slutliga förbrukningsposten. Så fungerar reservation och slutreglering →
{\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
Behåll varje fullständigt returnerat svar, fil och innehållsdel.
Varje angivet svar för ett fråge-ID behålls med sin exakta typ, värdet noul/choice/score, konfidens, sannolikheter och teckenförklaring. Hela det ursprungliga JSON-svaret lagras och returneras först efter avräkning.
Bevara den ursprungliga operationen och hela eller det partiella svaret; upprepa inte POST.
| Fält | Typ |
|---|---|
Fältmodel | Typstring |
Fältid | Typstring |
Fältprovider | Typstring |
Fältanswers.<id>.type | Typstring |
Fältanswers.<id>.noul | Typnumber |
Fältanswers.<id>.choice | Typstring |
Fältanswers.<id>.score | Typnumber |
Fältanswers.<id>.confidence | Typnumber |
Fältanswers.<id>.probabilities | Typobject |
Fältanswers.<id>.legend | Typobject |
Fältusage.input_tokens | Typinteger |
Fältusage.output_tokens | Typinteger |
Fältusage.cost | Typnumber |
| Svar | Villkor | Nästa steg |
|---|---|---|
Svar400 · invalid_request_error | VillkorOgiltigt obligatoriskt fält, ogiltig representation eller ogiltigt värde | Nästa stegKorrigera det angivna fältet i begäran. |
Ailoot Ultra nace-ai/drex-v1.5
Använd metodsökvägarna som visas ovan.