Passer au contenu principal
L’API AI Chat v2 (/aichat2/conversations) est une interface de conversation de nouvelle génération et une version entièrement améliorée de l’API AI Chat. En s’appuyant sur la simplicité de v1 et la gestion hébergée des conversations multi-tours, elle étend :
  • Entrée utilisateur multimodale : envoyez directement des blocs de texte + image + fichier via le champ message structuré, sans avoir besoin de les joindre indirectement via references.
  • Appels d’outils orientés Agent : intègre un ensemble d’outils tels que la recherche en ligne, l’extraction de pages web, la 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 des outils de manière autonome sur plusieurs tours dans une seule requête afin d’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 token par token, ce qui facilite leur rendu séparé selon leur type côté frontend.
  • Interrompable / Reprenable : 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 : utilisez le champ action sur le même endpoint pour effectuer retrieve / retrieve_batch / update / delete, sans avoir besoin d’une 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 la requête, elle est entièrement rétrocompatible avec v1 : il suffit d’envoyer model + question (+ éventuellement stateful / id / references / preset) pour obtenir une réponse JSON {answer, id} équivalente à v1. Ainsi, pour migrer depuis /aichat/conversations, il n’est pas nécessaire de réécrire le client : il suffit de remplacer le chemin par /aichat2/conversations.
Si vous utilisez actuellement /aichat/conversations, l’ancienne interface restera disponible, et vous pourrez migrer à votre propre rythme.

Processus de demande

Pour utiliser l’API AI Chat v2, rendez-vous d’abord sur la console Ace Data Cloud afin d’obtenir votre API Token et le conserver pour plus tard. 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, il n’est pas nécessaire d’en demander un séparément pour chaque service. Lors de votre première demande, un quota gratuit vous sera offert afin de pouvoir l’essayer gratuitement ; lorsque le quota est insuffisant, vous pouvez recharger votre solde universel dans 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 récupérez {answer, id}. Exemple CURL :
Résultat renvoyé :
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.1-pro, 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 de la page du service.

Conversation multi-tours

Comme avec v1, envoyez stateful: true pour activer la sauvegarde de la conversation, et l’API renverra un id ; il suffit de renvoyer cet id lors des requêtes ultérieures pour continuer la conversation, sans avoir à maintenir vous-même l’historique des messages. Première requête :
Retour :
Deuxième requête, avec le même id :
stateful est défini sur true par défaut ; 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 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 brut, 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

Afin d’assurer la compatibilité avec les anciens clients, v2 reconnaît toujours le champ references: ["https://...", ...] :
  • Les suffixes d’URL sont jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, automatiquement convertis en blocs image_url ;
  • Les autres extensions sont converties en blocs file_url ;
  • Si un question est également fourni, il est alors placé en tête en tant que bloc text.
Ainsi, si vous souhaitez uniquement migrer depuis v1 sans modifier le corps de la requête, remplacez simplement le chemin par /aichat2/conversations, et l’utilisation originale de references continue 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 lui-même des outils pour accomplir des tâches en plusieurs étapes, ceci est activé par défaut, et ne nécessite aucune configuration supplémentaire dans la requête côté client. Cas courants :
  • L’utilisateur demande « Aidez-moi à chercher quelles sont 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 un 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 présentés à travers 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, il suffit d’ignorer les événements tool_use / tool_result / card / citation ; la sortie finale du modèle continue d’être diffusée via text_delta. max_turns peut limiter le nombre maximal de cycles durant lesquels le modèle peut s’appeler lui-même via des outils dans cette requête ; la plage est de 1 à 500, et la valeur par défaut est 500 s’il est omis. Le définir à une valeur faible (par exemple, max_turns: 1) peut forcer une réponse unique et ne permettre aucun appel d’outil.

Exécution asynchrone et autorisation sans supervision

Si vos appels proviennent de Webhooks d’alerte, de CI/CD, de systèmes de surveillance ou d’autres tâches backend, vous pouvez définir async: true pour que l’interface renvoie immédiatement l’ID de la tâche, tandis que l’exécution se poursuit en arrière-plan :
Exemple de réponse :
Vous pouvez ensuite utiliser action: retrieve + id pour consulter le résultat de la conversation ; vous pouvez également fournir un callback_url, et une fois la tâche terminée, la plateforme enverra { status, answer, usage, error } par POST à votre adresse de rappel. callback_url doit utiliser http / https, et ne peut pas contenir directement localhost ou une adresse IP privée littérale. Les tâches backend n’ont généralement personne pour cliquer sur une confirmation. Si vous souhaitez que certains Skill ou MCP Server exécutent des actions telles que l’envoi, la publication ou l’écriture en mode sans supervision, veuillez transmettre 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’être prévisualisés, exécutés en dry-run ou se voir refuser les opérations d’écriture en mode sans supervision. Si un contrôle plus précis 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, aucun champ interrupteur supplémentaire n’est nécessaire. Remarque : la préautorisation signifie seulement 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 en dry-run et n’exécutera pas directement les opérations d’écriture.

Reprendre une conversation en pause

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 figée dans l’état awaiting_user_input :
Dans le frontend, affichez cet événement sous forme de carte afin que l’utilisateur sélectionne une réponse, puis lancez la requête suivante avec le même id et réinjectez 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 pause ; 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 en pause 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 (incluant l’historique messages, model, title, tools_used, etc.).

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

Renvoie { items: [...], total }. Les résumés n’incluent pas messages, ils sont adaptés à une liste de 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 facultatifs : 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 effectue une validation stricte du schéma (il doit être sous la forme ToolUseContent repliée), et renverra 400 en cas de non-conformité. En général, il est uniquement recommandé de l’utiliser 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 presque 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 de la migration vers 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, ainsi les clients qui analysent déjà 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 avancer à votre rythme.

Gestion des erreurs

Les réponses d’erreur sont uniformisées comme suit :
Erreurs courantes :
  • 400 bad_request : champs obligatoires manquants, 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 flux, les erreurs sont émises sous forme d’événement {"type":"error","message":"..."}, puis 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 tour / plusieurs tours » vers des « conversations observables orientées Agent » : entrées multimodales, appels d’outils, mise en pause / reprise, événements structurés en flux, CRUD intégré. Il est recommandé aux nouvelles intégrations d’utiliser directement v2 ; les intégrations v1 existantes peuvent migrer progressivement par étapes. Pour toute question, veuillez contacter à tout moment notre équipe de support technique.