Vai al contenuto principale
L’API AI Chat v2 (/aichat2/conversations) è l’interfaccia conversazionale di nuova generazione, una versione completamente aggiornata della AI Chat API. Sulla base della semplicità di v1 e della gestione ospitata delle conversazioni multi-turno, estende:
  • Input utente multimodale: tramite il campo strutturato message è possibile inviare direttamente blocchi di testo + immagini + file, senza doverli prima allegare indirettamente tramite references.
  • Chiamata di strumenti in stile Agent: integra una serie di strumenti per la ricerca web, il recupero di pagine web, la lettura di file e altro ancora, e può collegare server MCP autorizzati dall’utente (Google Drive, Notion, Slack, GitHub ecc.); il modello può chiamare autonomamente gli strumenti per più turni all’interno di una singola richiesta per completare attività complesse.
  • Eventi di streaming strutturati: tramite accept: text/event-stream o application/x-ndjson è possibile ottenere eventi come text_delta, tool_use, tool_result, thinking, citation, card, artifact token per token, facilitando il rendering separato nel frontend in base al tipo corrispondente.
  • Interrompibile / ripristinabile: quando il modello necessita che l’utente integri informazioni, emette un evento ask_user_question e si mette in pausa; alla chiamata successiva è possibile continuare reinserendo la risposta tramite tool_results.
  • Nuove azioni CRUD: sullo stesso endpoint, tramite il campo action, è possibile completare retrieve / retrieve_batch / update / delete, senza necessitare di API aggiuntive per la gestione delle conversazioni.
  • Elenco di modelli continuamente 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 inviare model + question (+ opzionalmente stateful / id / references / preset) per ottenere una risposta JSON {answer, id} equivalente a v1; quindi, per migrare da /aichat/conversations non è necessario riscrivere il client, basta cambiare il percorso in /aichat2/conversations.
Se attualmente utilizzi /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, innanzitutto ottieni il tuo API Token dalla console di Ace Data Cloud e conservalo come riserva. Se non hai ancora effettuato l’accesso o la registrazione, verrai automaticamente reindirizzato alla pagina di accesso per registrarti e accedere; al termine, tornerai automaticamente alla pagina corrente. Un solo API Token consente di chiamare tutti i servizi della piattaforma, senza doverne richiedere uno separatamente per ciascun servizio. Alla prima richiesta viene assegnato un credito gratuito, che consente di provare il servizio gratuitamente; quando il credito non è sufficiente, è possibile ricaricare il saldo universale nella console.
📘 Documentazione completa: AI Chat v2 API →

Utilizzo di base

L’utilizzo più semplice è esattamente uguale a v1: invia model + question e ottieni {answer, id}. Esempio CURL:
Risultato restituito:
Esempio Python:
I valori model disponibili sono visibili 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.1-pro, 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.

Conversazioni multi-turno

Come in v1, invia stateful: true per attivare il salvataggio della conversazione; l’API restituirà un id; nelle richieste successive, basta reinviare l’id per continuare la conversazione, senza dover gestire autonomamente la cronologia dei messaggi. Prima richiesta:
Restituisce:
Seconda richiesta, includendo lo stesso id:
Il valore predefinito di stateful è true; ometterlo equivale a passare esplicitamente true. 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, selezionati in base all’header accept:

Esempio NDJSON

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

Esempio SSE

Sul lato browser, l’uso di EventSource non supporta corpi di richiesta personalizzati; si consiglia di usare fetch + analisi manuale suddivisa per \n\n:

Tipi di eventi in streaming

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

Input multimodale

Se l’input dell’utente include immagini o file, passa 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 precedenti, v2 continua a riconoscere il campo references: ["https://...", ...]:
  • Il suffisso dell’URL è jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, viene automaticamente convertito in un blocco image_url;
  • Le altre estensioni vengono convertite in blocchi file_url;
  • Se viene fornito contemporaneamente anche question, viene anteposto come un blocco text.
Pertanto, se vuoi solo migrare da v1 senza modificare il corpo della richiesta, basta sostituire il percorso con /aichat2/conversations; l’uso originale di references continua a funzionare normalmente. Se serve un controllo più preciso (ad esempio, inserire più immagini tra i testi, oppure se l’ordine è importante), usa direttamente l’array message.

Chiamate di strumenti e MCP

Il miglioramento principale 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 il web search integrato → organizza i risultati in una risposta.
  • L’utente chiede «Leggi questo PDF e poi scrivi un riassunto» → il modello chiama file_read → scrive un 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.
Nel flusso NDJSON / SSE, le chiamate di 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 delle categorie 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 turni in cui il modello può richiamare autonomamente strumenti all’interno di questa richiesta; l’intervallo è 1–500 e, se omesso, il valore predefinito è 500. 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 presidiata

Se la tua chiamata proviene da Webhook di avvisi, CI/CD, sistemi di monitoraggio o altre attività in background, 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 dopo il 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 non c’è nessuno che possa fare clic per confermare le attività in background. Se desideri che determinate Skill o MCP Server eseguano azioni come invio, pubblicazione, scrittura ecc. in modalità non presidiata, passa esplicitamente un elenco di preautorizzazioni 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 / i MCP Server non inclusi nella preautorizzazione possono ancora solo visualizzare in anteprima, eseguire dry-run o rifiutare operazioni di scrittura in modalità non presidiata. Se è necessario un controllo più granulare, puoi anche usare l’oggetto equivalente unattended_policy:
La preautorizzazione consiste proprio in questi due elenchi: un elenco vuoto non autorizza alcuna capacità, senza necessità di ulteriori campi di attivazione. Nota: la preautorizzazione rappresenta soltanto che «questa richiesta consente a queste capacità di saltare la conferma manuale in modalità non presidiata». La Skill specifica deve comunque supportare --unattended-confirm o il meccanismo di sicurezza corrispondente; altrimenti continuerà in dry-run e non eseguirà direttamente operazioni di scrittura.

Riprendere una conversazione in pausa

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 bloccata nello stato awaiting_user_input:
Nel frontend, renderizza questo evento come una scheda affinché l’utente scelga la risposta, quindi avvia la richiesta successiva con lo stesso id, reinserendo la risposta tramite tool_results:
tool_use_id nel corpo della richiesta deve essere esattamente identico al tool_id al momento della pausa; in caso contrario verrà restituito 400. Quando nella richiesta è presente contemporaneamente tool_results, question / message / references vengono tutti ignorati. Se l’utente decide di abbandonare questa domanda, passa direttamente un nuovo question / message; la piattaforma contrassegnerà automaticamente la chiamata dello strumento in pausa come «saltata dall’utente».

Gestione delle conversazioni (CRUD)

v2 fornisce una gestione leggera delle conversazioni tramite il campo action sullo stesso endpoint, 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 —— Elencare 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 quindi action: retrieve per recuperare separatamente i suoi messaggi completi. Parametri di filtro opzionali: user_id, application_id, model_group, model.

action: update —— Modificare il titolo o riscrivere la cronologia

È possibile passare anche messages, ma il server eseguirà una rigorosa convalida dello schema (deve essere nel formato ToolUseContent compresso); se non è conforme, verrà restituito 400. In genere è consigliato usarlo solo per modificare title.

action: delete —— Eliminare una conversazione

Restituisce { id, success: true }. Dopo l’eliminazione non può essere recuperata, conferma prima di chiamare.

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, ecc.), quando passi a v2 è consigliabile aggiornare ai modelli contemporanei (come gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview, ecc.).
  3. I campi del flusso NDJSON rimangono retrocompatibili: ogni evento text_delta continua a includere delta_answer e id, pertanto i client esistenti che analizzano delta_answer riga per riga non richiedono modifiche.
Dopo la migrazione, puoi abilitare secondo necessità le nuove funzionalità di v2 (message multimodale, SSE, chiamate agli strumenti, CRUD action), procedendo secondo i tuoi ritmi.

Gestione degli errori

Le risposte di errore hanno il formato uniforme:
Errori comuni:
  • 400 bad_request: campi obbligatori mancanti, mancata corrispondenza di tool_use_id, schema di messages non valido, ecc.
  • 401 invalid_token: intestazione authorization non corretta.
  • 404 not_found: la conversazione corrispondente a id non esiste durante action: retrieve / update / delete.
  • 429 too_many_requests: è stato attivato il limite di frequenza.
  • 500 chat_error: errore dell’LLM upstream oppure completion_tokens=0 in questo turno (trattato come non consumato, senza addebito).
Nella risposta in streaming, l’errore viene emesso come evento {"type":"error","message":"..."}, dopodiché il flusso termina immediatamente.

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 orientate agli Agent»: input multimodale, chiamate agli 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 e senza problemi. Per qualsiasi domanda, contatta in qualsiasi momento il nostro team di supporto tecnico.