Skip to main content
L’API AI Chat v2 (/aichat2/conversations) è l’interfaccia di conversazione di nuova generazione, una versione completamente aggiornata della AI Chat API. Sulla base della semplicità di v1 e della gestione delle conversazioni multi-turno, espande:
  • Input utente multimodale: attraverso il campo strutturato message è possibile inviare direttamente blocchi di testo + immagini + file, senza doverli prima allegare indirettamente tramite references.
  • Chiamate di strumenti agentici: include una serie di strumenti per la ricerca online, il recupero di pagine web, la lettura di file e altro, e può collegare server MCP autorizzati dall’utente (Google Drive, Notion, Slack, GitHub ecc.); il modello può chiamare autonomamente gli strumenti più volte in una singola richiesta per completare attività complesse.
  • Eventi di streaming strutturati: tramite accept: text/event-stream o application/x-ndjson è possibile ottenere eventi quali text_delta, tool_use, tool_result, thinking, citation, card, artifact e altri, token per token, semplificando il rendering separato nel frontend in base al tipo corrispondente.
  • Interrompibile / ripristinabile: quando il modello necessita di ulteriori informazioni dall’utente, emette un evento ask_user_question e si mette in pausa; alla chiamata successiva è possibile continuare compilando la risposta tramite tool_results.
  • Nuove azioni CRUD: sullo stesso endpoint, utilizzare il campo action per completare retrieve / retrieve_batch / update / delete, senza necessità di API aggiuntive per la gestione delle conversazioni.
  • Elenco dei modelli costantemente aggiornato: per impostazione predefinita integra modelli contemporanei come GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 e altri.
Allo stesso tempo, a livello di corpo della richiesta è completamente retrocompatibile con v1: basta passare model + question (+ opzionalmente stateful / id / references / preset) per ottenere una risposta JSON {answer, id} equivalente a v1; pertanto, per migrare da /aichat/conversations non è necessario riscrivere il client, basta sostituire il percorso con /aichat2/conversations.
Se stai attualmente utilizzando /aichat/conversations, la vecchia interfaccia continuerà a essere disponibile e potrai migrare secondo i tuoi tempi.

Procedura di richiesta

Per utilizzare l’API AI Chat v2, vai prima alla console di Ace Data Cloud per ottenere il tuo API Token e conservarlo per l’uso. Se non hai ancora effettuato l’accesso o la registrazione, verrai automaticamente reindirizzato alla pagina di accesso per registrarti ed effettuare l’accesso; al termine tornerai automaticamente alla pagina corrente. Un solo API Token può chiamare tutti i servizi della piattaforma, senza doverne richiedere uno separatamente per ogni servizio. La prima richiesta include crediti gratuiti per una prova gratuita; quando i crediti non sono sufficienti, puoi ricaricare il saldo comune nella console.
📘 Documentazione completa: AI Chat v2 API →

Utilizzo di base

L’utilizzo più semplice è esattamente uguale a v1: passa model + question e ottieni {answer, id}. Esempio CURL:
Risultato restituito:
Esempio Python:
I valori model disponibili possono essere visualizzati direttamente nel menu a discesa del pannello Try sulla destra; le categorie comuni includono:
  • 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 ecc.
  • 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 ecc.
  • 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 ecc.
  • xAI: grok-4 ecc.
  • DeepSeek: deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528 ecc.
  • Moonshot: kimi-k3, kimi-k2.6, kimi-k2.5 ecc.
  • Zhipu: glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v ecc.
Per le regole di fatturazione specifiche, consulta la scheda Pricing nella pagina del servizio.

Conversazione multi-turno

Come in v1, passa stateful: true per attivare il salvataggio della conversazione; l’API restituirà un id; nelle richieste successive, basta riportare l’id per continuare la conversazione, senza dover gestire personalmente la cronologia dei messages. Prima richiesta:
Restituisce:
Seconda richiesta, includendo lo stesso id:
stateful è true per impostazione predefinita, ometterlo equivale a passare esplicitamente true. Se non vuoi che il server salvi questo turno di conversazione, puoi impostare esplicitamente stateful: false.

Risposta in streaming

v2 supporta due formati di streaming, selezionati in base all’header accept:

Esempio NDJSON

Ogni riga di NDJSON è un evento strutturato; il più comune è text_delta:

Esempio SSE

L’uso di EventSource nel browser non supporta corpi di richiesta personalizzati; si consiglia di usare fetch + parsing manuale per sezioni tramite \n\n:

Tipi di eventi streaming

Per i client che si interessano solo della risposta finale, concatenare il content di tutti i text_delta equivale a answer nella modalità application/json.

Input multimodale

Se l’input dell’utente include immagini o file, passa message (array) invece di question. Ogni elemento dell’array è un blocco di contenuto:
Tipi di blocchi supportati:
  • text — Testo normale, campo text obbligatorio.
  • image_url — Immagine, campo image_url.url obbligatorio.
  • file_url — File (PDF, CSV, TXT ecc.), campo file_url.url obbligatorio.

Relazione con references di v1

Per compatibilità con i vecchi client, v2 riconosce ancora il campo references: ["https://...", ...]:
  • I suffissi URL sono jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, convertiti automaticamente in blocchi image_url;
  • le altre estensioni vengono convertite in blocchi file_url;
  • se viene fornito contemporaneamente anche question, allora viene anteposto come blocco text.
Pertanto, se vuoi solo migrare da v1 senza modificare il corpo della richiesta, basta sostituire il percorso con /aichat2/conversations, e l’uso originale di references continua a funzionare normalmente. Se è necessario un controllo più preciso (ad esempio inserire più immagini tra i testi, oppure se l’ordine è molto importante), usa direttamente l’array message.

Chiamate degli strumenti e MCP

Il principale miglioramento di v2 è che il modello può chiamare autonomamente strumenti per completare attività in più passaggi, ed è abilitato per impostazione predefinita, senza che il client debba effettuare alcuna configurazione aggiuntiva nella richiesta. Scenari comuni:
  • L’utente chiede «Cercami quali nuove mostre ci sono recentemente a Shanghai» → il modello chiama la ricerca web integrata → organizza i risultati in una risposta.
  • L’utente chiede «Leggi questo PDF e poi scrivi un riepilogo» → il modello chiama file_read → scrive il riepilogo.
  • L’utente ha già autorizzato Google Drive / GitHub / Notion ecc. in Connections → il modello può chiamare gli strumenti MCP corrispondenti per leggere e scrivere i relativi dati.
Nel flusso NDJSON / SSE, le chiamate degli strumenti vengono presentate tramite due tipi di eventi, tool_use e tool_result, ad esempio:
Se non vuoi mostrare nel frontend i dettagli delle chiamate degli strumenti, basta ignorare gli eventi tool_use / tool_result / card / citation; l’output finale del modello continua comunque a fluire tramite text_delta. max_turns può limitare il numero massimo di cicli in cui il modello può richiamare autonomamente strumenti in questa richiesta; il limite predefinito è deciso dalla piattaforma. Impostarlo a un valore basso (ad esempio max_turns: 1) può forzare una singola risposta e non consentire alcuna chiamata di strumenti.

Esecuzione asincrona e autorizzazione non supervisionata

Se la tua chiamata proviene da un Webhook di avviso, CI/CD, sistema di monitoraggio o altre attività di backend, puoi impostare async: true affinché l’interfaccia restituisca immediatamente l’ID dell’attività e continui l’esecuzione in background:
Esempio di risposta:
Successivamente puoi usare action: retrieve + id per interrogare il risultato della conversazione; puoi anche fornire callback_url, e al completamento dell’attività la piattaforma invierà { status, answer, usage, error } tramite POST al tuo indirizzo di callback. callback_url deve usare http / https e non può indicare direttamente localhost o un indirizzo IP privato letterale. Di solito nelle attività di background non c’è nessuno che possa fare clic per confermare. Se desideri che determinate Skill o MCP Server eseguano azioni come invio, pubblicazione, scrittura ecc. in modalità non supervisionata, passa esplicitamente un elenco di pre-autorizzazione nel corpo della richiesta:
I valori in allowed_skills sono gli slug delle Skill connesse; i valori in allowed_mcp_servers sono gli slug degli MCP Server connessi. Le Skill / gli MCP Server non inclusi nella pre-autorizzazione, in modalità non supervisionata, possono comunque solo visualizzare in anteprima, effettuare dry-run o rifiutarsi di eseguire operazioni di scrittura. Se è necessario un controllo più dettagliato, puoi anche usare l’equivalente oggetto unattended_policy:
La pre-autorizzazione consiste proprio in questi due elenchi: un elenco vuoto significa non autorizzare alcuna capacità, senza necessità di campi di attivazione aggiuntivi. Nota: la pre-autorizzazione rappresenta solo il fatto che «questa richiesta consente a queste capacità di saltare la conferma manuale in modalità non supervisionata». La Skill specifica deve comunque supportare --unattended-confirm o il corrispondente meccanismo di sicurezza; altrimenti continuerà a effettuare dry-run e non eseguirà direttamente operazioni di scrittura.

Riprendere una conversazione sospesa

Alcuni strumenti fanno sì che il modello «ponga una domanda all’utente»; in questo momento il modello emette un evento ask_user_question e la conversazione viene congelata nello stato awaiting_user_input:
Nel frontend, rendi questo evento come una scheda affinché l’utente scelga una risposta, quindi avvia la richiesta successiva con lo stesso id, reinserendo la risposta tramite tool_results:
Il tool_use_id nel corpo della richiesta deve corrispondere esattamente al tool_id al momento della sospensione; in caso contrario verrà restituito 400. Quando nella richiesta sono presenti contemporaneamente tool_results, question / message / references vengono tutti ignorati. Se l’utente decide di abbandonare questa domanda, basta passare un nuovo question / message; la piattaforma contrassegnerà automaticamente la chiamata dello strumento sospesa come «saltata dall’utente».

Gestione delle conversazioni (CRUD)

v2 fornisce una gestione leggera delle conversazioni sullo stesso endpoint tramite il campo action, senza necessità di aprire un’altra API.

action: retrieve —— Recuperare una conversazione

Restituisce il documento completo della conversazione (inclusi la cronologia di messages, model, title, tools_used e così via).

action: retrieve_batch —— Elenca i riepiloghi delle conversazioni

Restituisce { items: [...], total }. I riepiloghi non includono messages, quindi sono adatti per un elenco nella barra laterale; se l’utente apre una conversazione, usa poi action: retrieve per recuperare separatamente i suoi messaggi completi. Parametri di filtro opzionali: user_id, application_id, model_group, model.

action: update —— Modifica il titolo o riscrive la cronologia

È possibile passare anche messages, ma il server eseguirà una rigorosa convalida dello schema (deve avere la forma ToolUseContent compressa); in caso contrario restituirà 400. In generale, si consiglia di usarlo solo per modificare title.

action: delete —— Elimina una conversazione

Restituisce { id, success: true }. Dopo l’eliminazione non sarà possibile ripristinarla, conferma prima di chiamarla.

Migrazione fluida da v1

Se stai già utilizzando /aichat/conversations, la migrazione a v2 non richiede quasi alcuna modifica al codice:
  1. Modifica l’URL da https://api.acedata.cloud/aichat/conversations a https://api.acedata.cloud/aichat2/conversations.
  2. Se in precedenza passavi nomi di modelli v1 (come gpt-3.5, gpt-4-browsing e così via), quando passi a v2 è consigliabile aggiornare ai modelli contemporanei (come gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview e così via).
  3. I campi del flusso NDJSON rimangono retrocompatibili: ogni evento text_delta include ancora delta_answer e id, pertanto i client originali che analizzano riga per riga delta_answer non richiedono modifiche.
Dopo la migrazione, puoi abilitare secondo necessità le nuove funzionalità di v2 (message multimodale, SSE, chiamate di strumenti, CRUD action), procedendo secondo i tuoi ritmi.

Gestione degli errori

Le risposte di errore sono uniformemente nel formato:
Errori comuni:
  • 400 bad_request: campi obbligatori mancanti, mancata corrispondenza di tool_use_id, schema di messages non valido e così via.
  • 401 invalid_token: l’header authorization non è corretto.
  • 404 not_found: la conversazione corrispondente a id non esiste durante action: retrieve / update / delete.
  • 429 too_many_requests: è stato attivato il limite di velocità.
  • 500 chat_error: errore dell’LLM upstream o completion_tokens=0 in questo turno (trattato come non consumato, non verrà addebitato).
Nella risposta in streaming, gli errori vengono emessi come evento {"type":"error","message":"..."}, subito dopo il flusso terminerà.

Conclusione

L’API AI Chat v2, pur mantenendo la retrocompatibilità con v1, aggiorna le conversazioni da «domande e risposte a turno singolo / multiplo» a «conversazioni osservabili agentiche»: input multimodale, chiamate di strumenti, sospendibili / ripristinabili, eventi strutturati in streaming, CRUD integrato. Si consiglia alle nuove integrazioni di utilizzare direttamente v2; le integrazioni v1 esistenti possono migrare gradualmente per fasi. Per qualsiasi domanda, contatta in qualsiasi momento il nostro team di supporto tecnico.