Skip to main content
L’API AI Chat v2 (/aichat2/conversations) est une interface de conversation de nouvelle génération, représentant une mise à niveau complète de l’API AI Chat. Sur la base de la simplicité de v1 et de la gestion hébergée des conversations multi-tours, elle étend :
  • Entrées utilisateur multimodales : envoyez directement des blocs de texte + images + fichiers via le champ message structuré, sans avoir à les joindre indirectement d’abord avec references.
  • Appel d’outils orienté Agent : intègre un ensemble d’outils de recherche en ligne, de récupération de pages web, de lecture de fichiers, etc., et permet de monter des serveurs MCP autorisés par l’utilisateur (Google Drive, Notion, Slack, GitHub, etc.) ; le modèle peut appeler les outils de manière autonome sur plusieurs tours dans une seule requête pour accomplir des tâches complexes.
  • Événements de streaming structurés : via accept: text/event-stream ou application/x-ndjson, vous pouvez obtenir des événements tels que text_delta, tool_use, tool_result, thinking, citation, card, artifact, etc., token par token, facilitant leur rendu séparé selon le type côté frontend.
  • Interruptible / récupérable : lorsque le modèle a besoin que l’utilisateur complète des informations, il émet un événement ask_user_question et se met en pause ; lors de l’appel suivant, il suffit de renseigner la réponse via tool_results pour continuer.
  • Nouvelles actions CRUD : complétez retrieve / retrieve_batch / update / delete via le champ action sur le même endpoint, sans API supplémentaire de gestion des conversations.
  • Liste de modèles continuellement mise à jour : intègre par défaut des modèles contemporains tels que GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3, etc.
En même temps, au niveau du corps de requête, elle est entièrement rétrocompatible avec v1 : il suffit d’envoyer model + question (+ stateful / id / references / preset optionnels) pour obtenir une réponse JSON {answer, id} équivalente à v1. Ainsi, aucune réécriture du client n’est nécessaire pour migrer depuis /aichat/conversations : il suffit de remplacer le chemin par /aichat2/conversations.
Si vous utilisez actuellement /aichat/conversations, l’ancienne interface restera disponible, et vous pouvez migrer à votre propre rythme.

Processus de demande

Pour utiliser l’API AI Chat v2, obtenez d’abord votre API Token dans la console Ace Data Cloud, et conservez-le en réserve. Si vous n’êtes pas encore connecté ou inscrit, vous serez automatiquement redirigé vers la page de connexion afin de vous inviter à vous inscrire et à vous connecter ; une fois terminé, vous reviendrez automatiquement sur la page actuelle. Un seul API Token permet d’appeler tous les services de la plateforme, sans avoir à en demander un séparément pour chaque service. Une demande initiale offre un crédit gratuit permettant une utilisation d’essai gratuite ; lorsque le crédit est insuffisant, vous pouvez recharger le solde commun depuis la console.
📘 Documentation complète : API AI Chat v2 →

Utilisation de base

L’utilisation la plus simple est exactement la même que v1 : envoyez model + question, et obtenez {answer, id}. Exemple CURL :
Résultat retourné :
Exemple Python :
Les valeurs model disponibles peuvent être visualisées directement dans la liste déroulante du panneau Try à droite ; les catégories courantes incluent :
  • 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, etc.
  • 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, etc.
  • 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, etc.
  • xAI : grok-4, etc.
  • DeepSeek : deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528, etc.
  • Moonshot : kimi-k3, kimi-k2.6, kimi-k2.5, etc.
  • Zhipu : glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v, etc.
Pour les règles de tarification spécifiques, consultez la carte Pricing sur la page du service.

Conversation multi-tours

Comme avec v1, envoyez stateful: true pour activer la sauvegarde de la conversation ; l’API renverra un id ; il suffit de renvoyer cet id dans les requêtes ultérieures pour continuer la conversation, sans devoir maintenir vous-même l’historique des messages. Première requête :
Retour :
Deuxième requête, avec le même id :
stateful vaut par défaut true ; l’omettre est équivalent à transmettre explicitement true. Si vous ne souhaitez pas que le serveur enregistre ce tour de conversation, vous pouvez définir explicitement stateful: false.

Réponse en streaming

v2 prend en charge deux formats de streaming, sélectionnés selon l’en-tête accept :

Exemple NDJSON

Chaque ligne de NDJSON est un événement structuré, le plus courant étant text_delta :

Exemple SSE

L’utilisation de EventSource côté navigateur ne prend pas en charge les corps de requête personnalisés ; il est recommandé d’utiliser fetch + une analyse manuelle par segments \n\n :

Types d’événements de streaming

Pour les clients qui ne s’intéressent qu’à la réponse finale, concaténer le content de tous les text_delta est équivalent à answer en mode application/json.

Entrée multimodale

Si l’entrée utilisateur contient des images ou des fichiers, transmettez message (un tableau) à la place de question. Chaque élément du tableau est un bloc de contenu :
Types de blocs pris en charge :
  • text — Texte normal, champ text obligatoire.
  • image_url — Image, champ image_url.url obligatoire.
  • file_url — Fichier (PDF, CSV, TXT, etc.), champ file_url.url obligatoire.

Relation avec les references de v1

Pour assurer la compatibilité avec les anciens clients, v2 reconnaît toujours le champ references: ["https://...", ...] :
  • Si le suffixe de l’URL est jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, le convertir automatiquement en bloc image_url ;
  • Convertir les autres extensions en bloc file_url ;
  • Si un question est également fourni, le placer en tête sous forme de bloc text.
Ainsi, si vous voulez seulement migrer depuis v1 sans modifier le corps de la requête, il suffit de remplacer le chemin par /aichat2/conversations, et l’utilisation originale de references continuera de fonctionner normalement. Si vous avez besoin d’un contrôle plus précis (par exemple, placer plusieurs images entre des textes, ou si l’ordre est important), utilisez directement le tableau message.

Appels d’outils et MCP

L’amélioration principale de v2 est que le modèle peut appeler des outils de manière autonome pour accomplir des tâches en plusieurs étapes, c’est activé par défaut, sans qu’aucune configuration supplémentaire ne soit nécessaire côté client dans la requête. Cas d’usage courants :
  • L’utilisateur demande « Aidez-moi à rechercher les nouvelles expositions récentes à Shanghai » → le modèle appelle la recherche web intégrée → organise les résultats dans une réponse.
  • L’utilisateur demande « Lisez ce PDF puis rédigez un résumé » → le modèle appelle file_read → rédige le résumé.
  • L’utilisateur a autorisé Google Drive / GitHub / Notion, etc. dans Connections → le modèle peut appeler les outils MCP correspondants pour lire et écrire leurs données.
Dans les flux NDJSON / SSE, les appels d’outils sont représentés par deux types d’événements, tool_use et tool_result, par exemple :
Si vous ne souhaitez pas afficher les détails des appels d’outils dans le frontend, ignorez simplement les types d’événements tool_use / tool_result / card / citation, la sortie finale du modèle continuera d’être diffusée via text_delta. max_turns peut limiter le nombre maximal de tours pendant lesquels le modèle peut s’appeler lui-même via des outils dans cette requête, la limite par défaut étant déterminée par la plateforme. Le définir à une faible valeur (par exemple max_turns: 1) permet de forcer une réponse unique et d’interdire tout appel d’outil.

Exécution asynchrone et autorisation sans supervision

Si votre appel provient d’un Webhook d’alerte, d’un CI/CD, d’un système de surveillance ou d’une autre tâche en arrière-plan, vous pouvez définir async: true afin que l’interface retourne immédiatement un ID de tâche et poursuive l’exécution en arrière-plan :
Exemple de retour :
Vous pouvez ensuite utiliser action: retrieve + id pour consulter le résultat de la conversation ; vous pouvez aussi fournir un callback_url, et lorsque la tâche est terminée, la plateforme enverra { status, answer, usage, error } en POST à votre adresse de rappel. callback_url doit utiliser http / https, et ne peut pas indiquer directement localhost ou une adresse IP privée littérale. Les tâches en arrière-plan n’ont généralement personne pour cliquer afin de confirmer. Si vous souhaitez que certains Skill ou MCP Server effectuent des actions telles que l’envoi, la publication ou l’écriture en mode sans supervision, transmettez explicitement une liste de préautorisations dans le corps de la requête :
Les valeurs dans allowed_skills sont les slugs des Skill connectés ; les valeurs dans allowed_mcp_servers sont les slugs des MCP Server connectés. Les Skill / MCP Server non inclus dans la préautorisation ne peuvent toujours qu’afficher un aperçu, effectuer un dry-run ou refuser d’exécuter des opérations d’écriture en mode sans supervision. Si un contrôle plus fin est nécessaire, vous pouvez également utiliser l’objet unattended_policy équivalent :
La préautorisation correspond à ces deux listes elles-mêmes : une liste vide signifie qu’aucune capacité n’est autorisée, sans nécessiter de champ d’activation supplémentaire. Attention : la préautorisation signifie uniquement que « cette requête autorise ces capacités à ignorer la confirmation humaine en mode sans supervision ». Le Skill concerné doit toujours prendre en charge --unattended-confirm ou le mécanisme de sécurité correspondant ; sinon, il continuera à effectuer un dry-run et n’exécutera pas directement les opérations d’écriture.

Reprendre une conversation suspendue

Certains outils amènent le modèle à « poser une question à l’utilisateur ». Le modèle émet alors un événement ask_user_question, et la conversation est gelée dans l’état awaiting_user_input :
Dans le frontend, rendez cet événement sous forme de carte afin que l’utilisateur puisse choisir une réponse, puis lancez la requête suivante avec le même id, en renseignant la réponse via tool_results :
Le tool_use_id dans le corps de la requête doit être exactement identique au tool_id au moment de la suspension ; sinon, une erreur 400 sera renvoyée. Lorsque tool_results est présent dans la requête, question / message / references sont tous ignorés. Si l’utilisateur décide d’abandonner cette question, transmettez directement un nouveau question / message, et la plateforme marquera automatiquement l’appel d’outil suspendu comme « ignoré par l’utilisateur ».

Gestion des conversations (CRUD)

v2 fournit une gestion légère des conversations via le champ action sur le même endpoint, sans nécessiter d’API supplémentaire.

action: retrieve —— Récupérer une conversation

Renvoie le document complet de la conversation (y compris l’historique messages, model, title, tools_used, etc.).

action: retrieve_batch —— Lister les résumés de conversations

Renvoie { items: [...], total }. Les résumés ne contiennent pas messages, ce qui convient à une liste dans la barre latérale ; si l’utilisateur ouvre une conversation, utilisez ensuite action: retrieve pour récupérer séparément ses messages complets. Paramètres de filtrage optionnels : user_id, application_id, model_group, model.

action: update —— Modifier le titre ou réécrire l’historique

messages peut également être transmis, mais le serveur effectuera une validation stricte du schéma (il doit être sous la forme ToolUseContent repliée) ; en cas de non-conformité, une erreur 400 sera renvoyée. En général, il est recommandé de l’utiliser uniquement pour modifier title.

action: delete —— Supprimer une conversation

Renvoie { id, success: true }. La suppression est irréversible, veuillez confirmer avant d’appeler cette action.

Migrer en douceur depuis v1

Si vous utilisez déjà /aichat/conversations, la migration vers v2 ne nécessite pratiquement aucune modification de code :
  1. Remplacez l’URL https://api.acedata.cloud/aichat/conversations par https://api.acedata.cloud/aichat2/conversations.
  2. Si vous transmettiez auparavant des noms de modèles v1 (tels que gpt-3.5, gpt-4-browsing, etc.), il est recommandé de passer à des modèles contemporains lors du passage à v2 (tels que gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview, etc.).
  3. Les champs du flux NDJSON restent rétrocompatibles : chaque événement text_delta contient toujours delta_answer et id, de sorte que les clients existants qui analysent delta_answer ligne par ligne n’ont pas besoin d’être modifiés.
Après la migration, vous pouvez activer selon vos besoins les nouvelles capacités de v2 (message multimodal, SSE, appels d’outils, CRUD action) et progresser à votre rythme.

Gestion des erreurs

Les réponses d’erreur suivent toutes ce format :
Erreurs courantes :
  • 400 bad_request : champ obligatoire manquant, tool_use_id non correspondant, schéma messages invalide, etc.
  • 401 invalid_token : l’en-tête authorization est incorrect.
  • 404 not_found : la conversation correspondant à id n’existe pas lors de action: retrieve / update / delete.
  • 429 too_many_requests : la limite de débit a été déclenchée.
  • 500 chat_error : erreur du LLM en amont ou completion_tokens=0 pour ce tour (traité comme non consommé, aucun frais ne sera facturé).
Dans les réponses en streaming, les erreurs sont émises sous forme d’événements {"type":"error","message":"..."}, après quoi le flux se termine immédiatement.

Conclusion

Tout en restant rétrocompatible avec v1, l’API AI Chat v2 fait évoluer les conversations de « questions-réponses à un ou plusieurs tours » vers des « conversations observables orientées Agent » : entrées multimodales, appels d’outils, interruption / reprise, événements structurés en streaming, CRUD intégré. Il est recommandé d’utiliser directement v2 pour les nouvelles intégrations ; les intégrations v1 existantes peuvent migrer progressivement par étapes. Pour toute question, n’hésitez pas à contacter notre équipe de support technique.