Skip to main content
AI Chat v2 API (/aichat2/conversations) è la nuova generazione di interfaccia di dialogo, una versione completamente aggiornata dell’AI Chat API. Si basa sulla semplicità e sulla gestione di conversazioni multi-turno della v1, espandendo:
  • Input utente multimodale: tramite il campo message strutturato è possibile inviare direttamente testo + immagini + file, senza dover prima allegare indirettamente tramite references.
  • Chiamate a strumenti agent: include un insieme di strumenti per ricerca online, scraping web, lettura di file, e può montare server MCP autorizzati dall’utente (Google Drive, Notion, Slack, GitHub, ecc.), il modello può chiamare autonomamente strumenti in più turni all’interno di una singola richiesta per completare compiti complessi.
  • Eventi strutturati in streaming: tramite accept: text/event-stream o application/x-ndjson è possibile ricevere eventi come text_delta, tool_use, tool_result, thinking, citation, card, artifact, ecc., facilitando il rendering front-end per tipo corrispondente.
  • Interrompibile / Recuperabile: il modello emetterà un evento ask_user_question e si fermerà quando ha bisogno di ulteriori informazioni dall’utente; la prossima chiamata può continuare riempiendo la risposta tramite tool_results.
  • Nuove azioni CRUD: completare retrieve / retrieve_batch / update / delete tramite il campo action sullo stesso endpoint, senza necessità di un’API di gestione delle sessioni aggiuntiva.
  • Elenco di modelli in continuo aggiornamento: accesso predefinito a GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 e altri modelli contemporanei.
Inoltre, a livello del corpo della richiesta, è completamente retrocompatibile con v1: basta inviare model + question (+ opzionale stateful / id / references / preset) per ottenere una risposta JSON {answer, id} equivalente a v1, quindi non è necessario riscrivere il client per migrare da /aichat/conversations, basta cambiare il percorso in /aichat2/conversations.
Se attualmente stai utilizzando /aichat/conversations, l’interfaccia precedente rimarrà attiva, puoi migrare al tuo ritmo.

Processo di Richiesta

Per utilizzare l’AI Chat v2 API, prima vai al Pannello di Controllo di Ace Data Cloud per ottenere il tuo API Token, da tenere come riserva. Se non hai ancora effettuato il login o registrato, verrai automaticamente reindirizzato alla pagina di login che ti invita a registrarti e accedere; una volta completato, verrai riportato automaticamente alla pagina corrente. Un API Token è sufficiente per accedere a tutti i servizi della piattaforma, senza necessità di richiederne uno separato per ogni servizio. La prima richiesta ti darà un credito gratuito, per un’esperienza senza costi; quando il credito è insufficiente, puoi ricaricare il saldo generale nel pannello di controllo.
📘 Documentazione completa: AI Chat v2 API →

Utilizzo di Base

L’uso più semplice è identico a v1: invia model + question e ricevi {answer, id}. Esempio CURL:
Risultato di ritorno:
Esempio Python:
I valori disponibili per model possono essere visualizzati direttamente nel menu a discesa del pannello Try a 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, gemini-3.1-pro-preview, gemini-3.1-flash-image-preview, gemini-3-pro-preview, gemini-2.5-flash-lite, ecc.
  • xAI: grok-4, ecc.
  • DeepSeek: deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528, ecc.
  • Moonshot: kimi-k3, kimi-k2.6, kimi-k2.5, ecc.
  • Zhipu: glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v, ecc.
Le specifiche regole di fatturazione possono essere consultate nella scheda Pricing della pagina dei servizi.

Conversazione Multi-turno

Come per v1, invia stateful: true per attivare il salvataggio della sessione, l’API restituirà un id; le richieste successive devono includere l’id per continuare la conversazione, senza necessità di mantenere la cronologia dei messaggi. Prima richiesta:
Risposta:
Seconda richiesta, porta lo stesso id:
stateful è impostato su true per impostazione predefinita; omettere e specificare esplicitamente true è equivalente. Se non desideri che il server salvi questo turno di conversazione, puoi impostare esplicitamente stateful: false.

Risposta in streaming

v2 supporta due formati di streaming, a seconda dell’intestazione accept:

Esempio NDJSON

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

Esempio SSE

Il lato browser utilizza EventSource e non supporta corpi di richiesta personalizzati, si consiglia di utilizzare fetch + analisi manuale per \n\n:

Tipi di eventi in streaming

Per i client che si interessano solo alla risposta finale, concatenare tutti i content di text_delta è equivalente a answer nel formato application/json.

Input multimodale

Se l’input dell’utente include immagini o file, passare message (array) al posto 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 client più vecchi, v2 riconosce ancora il campo references: ["https://...", ...]:
  • L’estensione dell’URL è jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, si trasforma automaticamente in un blocco image_url;
  • Altre estensioni si trasformano in un blocco file_url;
  • Se viene fornita anche una question, allora la si pone come un blocco text in precedenza.
Quindi, se si desidera migrare solo da v1 senza modificare il corpo della richiesta, basta cambiare il percorso in /aichat2/conversations, l’uso originale di references continuerà a funzionare. Per un controllo più preciso (ad esempio, per inserire più immagini tra i testi, o se l’ordine è molto importante) si utilizza direttamente l’array message.

Chiamata degli strumenti e MCP

Il punto centrale del miglioramento di v2 è che il modello può chiamare autonomamente strumenti per completare compiti a più fasi, questo è attivato per impostazione predefinita, non è necessario che il client faccia alcuna configurazione aggiuntiva nella richiesta. Scenari comuni:
  • L’utente chiede “Aiutami a cercare quali nuove mostre ci sono 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 riassunto” → il modello chiama file_read → scrive il riassunto.
  • 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 suoi dati.
Nella stream NDJSON / SSE, la chiamata degli strumenti viene presentata attraverso eventi di tipo tool_use e tool_result, ad esempio:
Se non si desidera visualizzare i dettagli della chiamata degli strumenti nel frontend, è possibile ignorare gli eventi tool_use / tool_result / card / citation, l’output finale del modello continuerà a fluire attraverso text_delta. max_turns può limitare quante volte il modello può chiamare strumenti autonomamente in questa richiesta, il limite predefinito è deciso dalla piattaforma. Impostarlo basso (ad esempio max_turns: 1) può forzare una risposta singola, non consentendo alcuna chiamata agli strumenti.

Esecuzione asincrona e autorizzazione senza supervisione

Se la tua chiamata proviene da un Webhook di allerta, CI/CD, sistema di monitoraggio o altri compiti in background, puoi impostare async: true per far sì che l’interfaccia restituisca immediatamente l’ID del compito, continuando l’esecuzione in background:
Esempio di risposta:
Dopo, puoi usare action: retrieve + id per interrogare il risultato della conversazione; puoi anche fornire callback_url, dopo il completamento del compito la piattaforma invierà { status, answer, usage, error } tramite POST al tuo indirizzo di callback. callback_url deve utilizzare http / https, e non può essere direttamente localhost o un indirizzo IP privato. I compiti in background di solito non possono essere confermati da nessuno. Se desideri che alcune Skill o MCP Server eseguano azioni di invio, pubblicazione, scrittura, ecc. in modalità senza supervisione, specifica esplicitamente l’elenco di 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 dei MCP Server connessi. Le Skill / MCP Server non incluse nell’autorizzazione preventiva possono comunque solo visualizzare, eseguire dry-run o rifiutare l’esecuzione delle operazioni di scrittura in modalità senza supervisione. Se hai bisogno di un controllo più dettagliato, puoi anche utilizzare l’oggetto equivalente unattended_policy:
L’autorizzazione preventiva è semplicemente questi due elenchi: un elenco vuoto non autorizza alcuna capacità, senza bisogno di ulteriori campi di attivazione. Nota: l’autorizzazione preventiva rappresenta solo “questa richiesta consente a queste capacità di saltare la conferma umana in modalità senza supervisione”. La Skill specifica deve comunque supportare --unattended-confirm o un meccanismo di sicurezza corrispondente; altrimenti continuerà a eseguire dry-run e non eseguirà direttamente le operazioni di scrittura.

Ripristino di una conversazione sospesa

Alcuni strumenti possono far sì che il modello “riformuli la domanda all’utente”, in questo caso il modello emetterà un evento ask_user_question, la conversazione sarà congelata nello stato awaiting_user_input:
Nel frontend, questo evento viene visualizzato come una scheda per consentire all’utente di scegliere una risposta, quindi si invia una nuova richiesta con lo stesso id, riempiendo la risposta tramite tool_results:
Nel corpo della richiesta, tool_use_id deve essere completamente identico a tool_id al momento della sospensione; altrimenti restituirà 400. Quando ci sono tool_results nella richiesta, question / message / references verranno ignorati. Se l’utente decide di rinunciare a questa domanda, basta inviare una nuova question / message e la piattaforma segnerà automaticamente la chiamata dello strumento sospesa come “saltata dall’utente”.

Gestione delle conversazioni (CRUD)

v2 offre una gestione leggera delle conversazioni attraverso il campo action sullo stesso endpoint, senza necessità di aprire un’API separata.

action: retrieve —— Recupera una conversazione

Restituisce il documento completo della conversazione (inclusa la cronologia messages, model, title, tools_used, ecc.).

action: retrieve_batch —— Elenca i riassunti delle conversazioni

Restituisce { items: [...], total }. Il riassunto non include messages, adatto per un elenco laterale; se l’utente apre una conversazione, utilizzare action: retrieve per recuperare i suoi messaggi completi. Parametri di filtro opzionali: user_id, application_id, model_group, model.

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

messages può essere inviato, ma il server eseguirà un rigoroso controllo dello schema (deve essere nella forma ToolUseContent compressa), altrimenti restituirà 400. In generale, si consiglia di utilizzarlo solo per modificare il title.

action: delete —— Elimina una conversazione

Restituisce { id, success: true }. Dopo l’eliminazione non può essere ripristinato, si prega di confermare prima di chiamare.

Migrazione fluida da v1

Se stai già utilizzando /aichat/conversations, la migrazione a v2 richiede quasi nessuna modifica al codice:
  1. Cambia l’URL da https://api.acedata.cloud/aichat/conversations a https://api.acedata.cloud/aichat2/conversations.
  2. Se in precedenza utilizzavi nomi di modelli v1 (come gpt-3.5, gpt-4-browsing, ecc.), si consiglia di passare a modelli contemporanei (come gpt-5.4, claude-opus-4-8, gemini-3.1-pro, ecc.) durante il passaggio a v2.
  3. I campi del flusso NDJSON rimangono retrocompatibili: ogni evento text_delta porta ancora delta_answer e id, quindi i client che analizzano delta_answer riga per riga non necessitano di modifiche.
Dopo la migrazione, puoi abilitare le nuove funzionalità di v2 (input multimodale message, SSE, chiamate agli strumenti, CRUD action) secondo necessità.

Gestione degli errori

Le risposte di errore sono uniformi:
Errori comuni:
  • 400 bad_request: mancano campi obbligatori, tool_use_id non corrisponde, schema messages non valido, ecc.
  • 401 invalid_token: intestazione authorization non corretta.
  • 404 not_found: durante action: retrieve / update / delete, la conversazione corrispondente all’id non esiste.
  • 429 too_many_requests: attivato il limite di velocità.
  • 500 chat_error: errore del LLM upstream o completion_tokens=0 in questo round (trattato come non consumato, non verrà addebitato).
Nella risposta in streaming, gli errori vengono inviati come {"type":"error","message":"..."} e subito dopo il flusso terminerà.

Conclusione

L’API AI Chat v2, mantenendo la retrocompatibilità con v1, ha aggiornato le conversazioni da “domande e risposte singole / multiple” a “conversazioni osservabili in stile agente”: input multimodale, chiamate agli strumenti, pause / ripristini, eventi strutturati in streaming, CRUD integrato. Si consiglia di utilizzare direttamente v2 per le nuove integrazioni; le integrazioni esistenti di v1 possono essere migrate in fasi. Se hai domande, non esitare a contattare il nostro team di supporto tecnico.