Hoppa till huvudinnehåll
AI Chat v2 API (/aichat2/conversations) är den nya generationens konversationsgränssnitt och en omfattande uppgraderad version av AI Chat API. Utifrån v1:s enkla, hanterade flerrundskonversationer utökar det med:
  • Multimodala användarinmatningar: Skicka text + bild + filblock direkt via det strukturerade fältet message, utan att först bifoga dem indirekt med references.
  • Agentbaserade verktygsanrop: Inbyggd uppsättning verktyg för webbsökning, hämtning av webbsidor, filläsning med mera, samt möjlighet att ansluta MCP-servrar som användaren har godkänt (Google Drive, Notion, Slack, GitHub osv.). Modellen kan självständigt anropa verktyg över flera rundor i en enda begäran för att slutföra komplexa uppgifter.
  • Strukturerade strömmande händelser: Via accept: text/event-stream eller application/x-ndjson kan du få token-för-token-händelser som text_delta, tool_use, tool_result, thinking, citation, card, artifact med mera, vilket gör det enkelt att rendera dem separat i frontend enligt respektive typ.
  • Avbrytbar / återupptagbar: När modellen behöver att användaren kompletterar information skickar den en ask_user_question-händelse och pausar. Vid nästa anrop kan den fortsätta genom att fylla i svaret via tool_results.
  • Nya CRUD-åtgärder: Slutför retrieve / retrieve_batch / update / delete genom fältet action på samma endpoint, utan ytterligare API för konversationshantering.
  • En kontinuerligt uppdaterad modellista: Ansluter som standard till moderna modeller som GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 med flera.
Samtidigt är det på begärandetextnivå helt bakåtkompatibelt med v1: genom att bara skicka model + question (+ valfritt stateful / id / references / preset) kan du få ett {answer, id} JSON-svar som motsvarar v1. Därför behöver du inte skriva om klienten vid migrering från /aichat/conversations; byt bara sökvägen till /aichat2/conversations.
Om du för närvarande använder /aichat/conversations kommer den gamla endpointen fortfarande att behållas, så du kan migrera i din egen takt.

Ansökningsprocess

För att använda AI Chat v2 API går du först till Ace Data Cloud-konsolen för att hämta din API-token och spara den som reserv. Om du ännu inte har loggat in eller registrerat dig omdirigeras du automatiskt till inloggningssidan, där du uppmanas att registrera dig och logga in. När det är klart återgår du automatiskt till den aktuella sidan. En API-token kan anropa alla plattformens tjänster, utan att behöva ansöka separat för varje tjänst. Vid första ansökan får du en gratis kvot för kostnadsfri utvärdering; när kvoten är otillräcklig kan du fylla på det gemensamma saldot i konsolen.
📘 Fullständig dokumentation: AI Chat v2 API →

Grundläggande användning

Den enklaste användningen är exakt densamma som i v1: skicka model + question och få {answer, id}. CURL-exempel:
Returresultat:
Python-exempel:
Tillgängliga värden för model kan ses direkt i rullgardinsmenyn i Try-panelen till höger. Vanliga kategorier omfattar:
  • OpenAI: gpt-5.4-mini, gpt-5.4-nano, gpt-5.2-pro, gpt-5.1-all, gpt-5-all, gpt-4.1, gpt-4o, gpt-4o-image, o3, o4-mini osv.
  • Anthropic: claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-opus-4-5-20251101, claude-sonnet-4-6, claude-sonnet-4-5-20250929, claude-haiku-4-5-20251001 osv.
  • Google: gemini-3.1-pro-preview, gemini-3.1-pro-preview, gemini-3.1-flash-image, gemini-3.1-pro-preview, gemini-2.5-flash-lite osv.
  • xAI: grok-4 osv.
  • DeepSeek: deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528 osv.
  • Moonshot: kimi-k3.1-pro, kimi-k3, kimi-k2.6, kimi-k2.5 osv.
  • Zhipu: glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v osv.
För specifika debiteringsregler, se Pricing-kortet på tjänstesidan.

Flerrundskonversationer

Precis som i v1 skickar du stateful: true för att aktivera sparande av konversationen, och API:t returnerar ett id; i efterföljande begäranden behöver du bara skicka tillbaka id för att fortsätta konversationen, utan att själv behöva underhålla meddelandehistoriken. Första begäran:
Retur:
Andra begäran, med samma id:
stateful är som standard true; att utelämna det är likvärdigt med att uttryckligen skicka true. Om du inte vill att servern ska spara denna samtalsrunda kan du uttryckligen ange stateful: false.

Strömmande svar

v2 stöder två strömmande format, som väljs enligt accept-huvudet:

NDJSON-exempel

Varje rad i NDJSON är en strukturerad händelse, där den vanligaste är text_delta:

SSE-exempel

EventSource i webbläsaren stöder inte anpassade begärandekroppar, så det rekommenderas att använda fetch + manuell tolkning genom uppdelning på \n\n:

Typer av strömmande händelser

För klienter som endast bryr sig om det slutliga svaret är det likvärdigt att sammanfoga content från alla text_delta med answer i läget application/json.

Multimodal inmatning

Om användarinmatningen innehåller bilder eller filer ska du skicka message (en array) i stället för question. Varje arrayelement är ett innehållsblock:
Blocktyper som stöds:
  • text — Vanlig text, fältet text krävs.
  • image_url — Bild, image_url.url krävs.
  • file_url — Fil (PDF, CSV, TXT osv.), file_url.url krävs.

Relation till v1 references

För kompatibilitet med äldre klienter känner v2 fortfarande igen fältet references: ["https://...", ...]:
  • URL-suffixet är jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, konvertera automatiskt till ett image_url-block;
  • Andra filändelser konverteras till ett file_url-block;
  • Om även question tillhandahålls samtidigt, placera det först som ett text-block.
Därför, om du bara vill migrera från v1 och inte vill ändra request body, behöver du bara byta sökvägen till /aichat2/conversations, och den ursprungliga användningen av references fungerar som vanligt. Om mer detaljerad kontroll behövs (till exempel att placera flera bilder mellan texter, eller om ordningen är viktig) använd direkt message-arrayen.

Verktygsanrop och MCP

Den centrala förbättringen i v2 är att modellen självständigt kan anropa verktyg för att slutföra uppgifter i flera steg, detta är aktiverat som standard, och klienten behöver inte göra någon ytterligare konfiguration i begäran. Vanliga scenarier:
  • Användaren frågar ”Hjälp mig att söka efter vilka nya utställningar som nyligen finns i Shanghai” → Modellen anropar inbyggd web search → Sammanställer resultaten till ett svar.
  • Användaren frågar ”Läs den här PDF:en och skriv sedan en sammanfattning” → Modellen anropar file_read → Skriver en sammanfattning.
  • Användaren har redan auktoriserat Google Drive / GitHub / Notion osv. i Connections → Modellen kan anropa motsvarande MCP-verktyg för att läsa och skriva dess data.
I NDJSON-/SSE-strömmen presenteras verktygsanrop genom de två typerna av händelser tool_use och tool_result, till exempel:
Om du inte vill visa detaljer om verktygsanrop i frontend räcker det att ignorera händelserna tool_use / tool_result / card / citation; modellens slutliga utdata strömmas fortfarande ut via text_delta. max_turns kan begränsa hur många omgångar modellen som mest får anropa verktyg själv i denna begäran, med intervallet 1–500 och standardvärdet 500 om det utelämnas. Om du sätter det lågt (till exempel max_turns: 1) kan du tvinga fram ett enskilt svar och förbjuda alla verktygsanrop.

Asynkron körning och obevakad auktorisering

Om ditt anrop kommer från en larm-Webhook, CI/CD, ett övervakningssystem eller någon annan bakgrundsuppgift kan du sätta async: true så att gränssnittet omedelbart returnerar ett uppgifts-ID och fortsätter körningen i bakgrunden:
Exempel på svar:
Därefter kan du använda action: retrieve + id för att hämta konversationsresultatet; du kan också ange callback_url, och när uppgiften är klar kommer plattformen att POST:a { status, answer, usage, error } till din callback-adress. callback_url måste använda http / https, och du får inte ange localhost eller en privat IP-literal direkt. Det finns vanligtvis ingen som kan klicka för att bekräfta bakgrundsuppgifter. Om du vill att vissa Skills eller MCP Servers ska utföra åtgärder som att skicka, publicera eller skriva i obevakat läge, ska du uttryckligen skicka en lista över förhandsgodkännanden i request body:
Värdena i allowed_skills är sluggar för anslutna Skills; värdena i allowed_mcp_servers är sluggar för anslutna MCP Servers. Skills / MCP Servers som inte finns med i förhandsgodkännandet kan i obevakat läge fortfarande endast förhandsgranska, köra dry-run eller vägra att utföra skrivåtgärder. Om mer detaljerad kontroll behövs kan du också använda det likvärdiga objektet unattended_policy:
Förhandsgodkännandet är just dessa två listor: en tom lista betyder att inga funktioner godkänns, utan behov av ytterligare växlingsfält. Observera: Förhandsgodkännande betyder endast att ”denna begäran tillåter att dessa funktioner hoppar över manuell bekräftelse i obevakat läge”. Den specifika Skill måste fortfarande stödja --unattended-confirm eller motsvarande säkerhetsmekanism; annars fortsätter den med dry-run och utför inte skrivåtgärder direkt.

Återuppta pausade konversationer

Vissa verktyg gör att modellen ”ställer en motfråga till användaren”. Modellen skickar då en ask_user_question-händelse, och konversationen fryses i tillståndet awaiting_user_input:
Rendera denna händelse som ett kort i frontend så att användaren kan välja ett svar, och använd sedan samma id för att starta nästa begäran och fyll tillbaka svaret via tool_results:
tool_use_id i request body måste vara exakt samma som tool_id när pausen inträffade; om de inte stämmer överens returneras 400. När tool_results samtidigt finns i begäran ignoreras question / message / references. Om användaren bestämmer sig för att avstå från denna fråga räcker det att direkt skicka en ny question / message, så markerar plattformen automatiskt det pausade verktygsanropet som ”användaren hoppade över”.

Konversationshantering (CRUD)

v2 erbjuder lättviktig konversationshantering på samma endpoint via fältet action, utan att behöva skapa ett separat API.

action: retrieve —— hämta en konversation

Returnerar det fullständiga konversationsdokumentet (inklusive messages-historik, model, title, tools_used osv.).

action: retrieve_batch —— lista konversationssammanfattningar

Returnerar { items: [...], total }. Sammanfattningar innehåller inte messages, vilket är lämpligt för sidofältslistor; om användaren öppnar en viss konversation, använd sedan action: retrieve för att hämta dess fullständiga meddelanden separat. Valfria filterparametrar: user_id, application_id, model_group, model.

action: update —— ändra titel eller skriv om historik

messages kan också skickas, men servern utför strikt schema-validering (måste vara i den hopfällda formen ToolUseContent); annars returneras 400. Generellt rekommenderas det endast för att ändra title.

action: delete —— ta bort en konversation

Returnerar { id, success: true }. Borttagning kan inte återställas, bekräfta innan du anropar.

Smidig migrering från v1

Om du redan använder /aichat/conversations kräver migrering till v2 nästan inga kodändringar:
  1. Ändra URL:en från https://api.acedata.cloud/aichat/conversations till https://api.acedata.cloud/aichat2/conversations.
  2. Om du tidigare skickade v1-modellnamn (som gpt-3.5, gpt-4-browsing osv.), rekommenderas det att uppgradera till moderna modeller vid byte till v2 (som gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview osv.).
  3. Fälten i NDJSON-strömmen förblir bakåtkompatibla: varje text_delta-händelse innehåller fortfarande delta_answer och id, så klienter som tidigare tolkar delta_answer rad för rad behöver inte ändras.
Efter migreringen kan du vid behov aktivera v2:s nya funktioner (multimodal message, SSE, verktygsanrop, action CRUD) och gå vidare i lämplig takt.

Felhantering

Felsvar är enhetligt formaterade som:
Vanliga fel:
  • 400 bad_request: obligatoriska fält saknas, tool_use_id matchar inte, messages-schemat är ogiltigt osv.
  • 401 invalid_token: authorization-huvudet är felaktigt.
  • 404 not_found: konversationen som motsvarar id finns inte vid action: retrieve / update / delete.
  • 429 too_many_requests: hastighetsbegränsningen har utlösts.
  • 500 chat_error: uppströms-LLM rapporterar ett fel eller completion_tokens=0 för denna omgång (behandlas som ej förbrukat och debiteras inte).
I strömmande svar skickas fel som händelsen {"type":"error","message":"..."}, varefter strömmen omedelbart avslutas.

Slutsats

AI Chat v2 API uppgraderar dialoger från ”enkelrunds- / flerrundsfrågor och svar” till ”agentbaserade observerbara dialoger”, samtidigt som det är bakåtkompatibelt med v1: multimodala indata, verktygsanrop, möjlighet att pausa / återuppta, strömmande strukturerade händelser och inbyggd CRUD. Det rekommenderas att nya integrationer använder v2 direkt; befintliga v1-integrationer kan migreras smidigt i etapper. Om du har några frågor, kontakta gärna vårt tekniska supportteam när som helst.