Saltar al contenido principal
AI Chat v2 API (/aichat2/conversations) es una interfaz de conversación de nueva generación y una versión completamente actualizada de AI Chat API. Sobre la base de la simplicidad de v1 y la gestión alojada de conversaciones de múltiples turnos, amplía:
  • Entrada de usuario multimodal: mediante el campo message estructurado, se pueden enviar directamente bloques de texto + imágenes + archivos, sin necesidad de adjuntarlos indirectamente primero mediante references.
  • Llamada a herramientas con agentes: incluye un conjunto de herramientas como búsqueda web, extracción de páginas web, lectura de archivos, entre otras, y permite montar servidores MCP autorizados por el usuario (Google Drive, Notion, Slack, GitHub, etc.); el modelo puede llamar autónomamente a herramientas en múltiples turnos dentro de una sola solicitud para completar tareas complejas.
  • Eventos de streaming estructurados: mediante accept: text/event-stream o application/x-ndjson, se pueden obtener eventos como text_delta, tool_use, tool_result, thinking, citation, card, artifact, etc., token por token, lo que facilita renderizarlos por separado en el frontend según sus tipos correspondientes.
  • Interrumpible / reanudable: cuando el modelo necesita que el usuario proporcione información adicional, emitirá un evento ask_user_question y se pausará; en la siguiente llamada, puede continuar rellenando la respuesta mediante tool_results.
  • Nuevas acciones CRUD: en el mismo endpoint, se completan retrieve / retrieve_batch / update / delete mediante el campo action, sin necesidad de una API adicional de gestión de conversaciones.
  • Lista de modelos actualizada continuamente: por defecto incluye modelos contemporáneos como GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3, entre otros.
Al mismo tiempo, a nivel del cuerpo de la solicitud es totalmente compatible hacia atrás con v1: basta con enviar model + question (+ opcionalmente stateful / id / references / preset) para obtener una respuesta JSON {answer, id} equivalente a v1, por lo que no es necesario reescribir el cliente al migrar desde /aichat/conversations; solo hay que cambiar la ruta a /aichat2/conversations.
Si actualmente estás usando /aichat/conversations, la antigua interfaz seguirá disponible, y puedes migrar a tu propio ritmo.

Proceso de solicitud

Para usar AI Chat v2 API, primero obtén tu API Token en la consola de Ace Data Cloud y guárdalo como respaldo. Si aún no has iniciado sesión o no te has registrado, serás redirigido automáticamente a la página de inicio de sesión para invitarte a registrarte e iniciar sesión; al finalizar, volverás automáticamente a la página actual. Un solo API Token permite llamar a todos los servicios de la plataforma; no es necesario solicitar uno por separado para cada servicio. La primera solicitud incluye crédito gratuito, que permite probarlo sin coste; cuando el crédito sea insuficiente, puedes recargar saldo general en la consola.
📘 Documentación completa: AI Chat v2 API →

Uso básico

El uso más sencillo es completamente idéntico al de v1: envía model + question y obtén {answer, id}. Ejemplo de CURL:
Resultado devuelto:
Ejemplo de Python:
Los valores disponibles para model se pueden ver directamente en el menú desplegable del panel Try a la derecha; las categorías comunes incluyen:
  • 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.
Para las reglas de facturación específicas, consulta la tarjeta Pricing de la página del servicio.

Conversaciones de múltiples turnos

Al igual que en v1, envía stateful: true para habilitar el guardado de conversaciones; la API devolverá un id; en las solicitudes posteriores, basta con incluir nuevamente el id para continuar la conversación, sin necesidad de mantener tú mismo el historial de messages. Primera solicitud:
Respuesta:
Segunda solicitud, incluyendo el mismo id:
El valor predeterminado de stateful es true; omitirlo es equivalente a pasar explícitamente true. Si no deseas que el servidor guarde esta ronda de conversación, puedes establecer explícitamente stateful: false.

Respuesta en streaming

v2 admite dos formatos de streaming, seleccionados según el encabezado accept:

Ejemplo de NDJSON

Cada línea de NDJSON es un evento estructurado; el más común es text_delta:

Ejemplo de SSE

El uso de EventSource en el navegador no admite cuerpos de solicitud personalizados; se recomienda usar fetch + análisis manual por segmentos de \n\n:

Tipos de eventos de streaming

Para los clientes que solo se preocupan por la respuesta final, concatenar el content de todos los text_delta es equivalente a answer en el modo application/json.

Entrada multimodal

Si la entrada del usuario incluye imágenes o archivos, pasa message (un array) en lugar de question. Cada elemento del array es un bloque de contenido:
Tipos de bloques compatibles:
  • text — Texto normal, requiere el campo text.
  • image_url — Imagen, requiere image_url.url.
  • file_url — Archivo (PDF, CSV, TXT, etc.), requiere file_url.url.

Relación con references de v1

Para ser compatible con clientes antiguos, v2 sigue reconociendo el campo references: ["https://...", ...]:
  • Si el sufijo de la URL es jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, se convierte automáticamente en un bloque image_url;
  • Otros sufijos se convierten en un bloque file_url;
  • Si también se proporciona question, se coloca delante como un bloque text.
Por lo tanto, si solo quieres migrar desde v1 y no quieres modificar el cuerpo de la solicitud, basta con cambiar la ruta a /aichat2/conversations; el uso original de references seguirá funcionando normalmente. Si necesitas un control más detallado (por ejemplo, colocar varias imágenes entre textos, o si el orden es muy importante), usa directamente el array message.

Llamadas a herramientas y MCP

La mejora principal de v2 es que el modelo puede llamar autónomamente a herramientas para completar tareas de varios pasos; esto está habilitado de forma predeterminada, y el cliente no necesita realizar ninguna configuración adicional en la solicitud. Escenarios comunes:
  • El usuario pregunta «Ayúdame a buscar qué nuevas exposiciones hay recientemente en Shanghái» → el modelo llama a la búsqueda web integrada → organiza los resultados en una respuesta.
  • El usuario pregunta «Lee este PDF y luego escribe un resumen» → el modelo llama a file_read → escribe un resumen.
  • El usuario ya ha autorizado Google Drive / GitHub / Notion, etc., en Connections → el modelo puede llamar a las herramientas MCP correspondientes para leer y escribir sus datos.
En el flujo NDJSON / SSE, las llamadas a herramientas se presentan mediante los dos tipos de eventos tool_use y tool_result, por ejemplo:
Si no quieres mostrar los detalles de las llamadas a herramientas en el frontend, basta con ignorar los tipos de eventos tool_use / tool_result / card / citation; la salida final del modelo seguirá fluyendo mediante text_delta. max_turns puede limitar el número máximo de rondas en que el modelo puede llamarse a sí mismo mediante herramientas en esta solicitud; el rango es de 1–500 y, si se omite, el valor predeterminado es 500. Establecerlo bajo (por ejemplo, max_turns: 1) puede forzar una única respuesta y no permitir ninguna llamada a herramientas.

Ejecución asíncrona y autorización desatendida

Si tus llamadas proceden de Webhooks de alertas, CI/CD, sistemas de monitoreo u otras tareas en segundo plano, puedes establecer async: true para que la interfaz devuelva inmediatamente el ID de la tarea y continúe ejecutándose en segundo plano:
Ejemplo de respuesta:
Después puedes usar action: retrieve + id para consultar el resultado de la conversación; también puedes proporcionar callback_url, y, cuando se complete la tarea, la plataforma hará POST de { status, answer, usage, error } a tu dirección de callback. callback_url debe usar http / https, y no puede indicar directamente localhost ni una dirección IP privada literal. Normalmente no hay nadie que pueda hacer clic para confirmar las tareas en segundo plano. Si deseas que determinados Skill o MCP Server ejecuten acciones de envío, publicación, escritura, etc. en modo desatendido, pasa explícitamente una lista de preautorización en el cuerpo de la solicitud:
Los valores en allowed_skills son los slug de los Skill conectados; los valores en allowed_mcp_servers son los slug de los MCP Server conectados. Los Skill / MCP Server no incluidos en la preautorización, en modo desatendido, solo pueden seguir previsualizando, hacer dry-run o rechazar la ejecución de operaciones de escritura. Si necesitas un control más detallado, también puedes utilizar el objeto equivalente unattended_policy:
La preautorización consiste en estas dos listas: una lista vacía significa que no se autoriza ninguna capacidad, sin necesidad de campos de activación adicionales. Nota: la preautorización solo significa «esta solicitud permite que estas capacidades omitan la confirmación humana en modo desatendido». El Skill específico aún debe admitir --unattended-confirm o el mecanismo de seguridad correspondiente; de lo contrario, seguirá haciendo dry-run y no ejecutará directamente operaciones de escritura.

Reanudar conversaciones pausadas

Algunas herramientas hacen que el modelo «pregunte de vuelta al usuario». En ese momento, el modelo emitirá un evento ask_user_question, y la conversación se congelará en el estado awaiting_user_input:
En el frontend, renderiza este evento como una tarjeta para que el usuario elija una respuesta y, después, inicia la siguiente solicitud usando el mismo id, devolviendo la respuesta mediante tool_results:
El tool_use_id en el cuerpo de la solicitud debe ser exactamente igual al tool_id en el momento de la pausa; si no coincide, devolverá 400. Cuando tool_results existe simultáneamente en la solicitud, question / message / references se ignorarán. Si el usuario decide abandonar esta pregunta, basta con pasar un nuevo question / message; la plataforma marcará automáticamente la llamada a herramienta pausada como «omitida por el usuario».

Gestión de conversaciones (CRUD)

v2 proporciona una gestión ligera de conversaciones mediante el campo action en el mismo endpoint, sin necesidad de abrir otra API.

action: retrieve —— Recuperar una conversación

Devuelve el documento completo de la conversación (incluido el historial de messages, model, title, tools_used, etc.).

action: retrieve_batch —— Enumerar resúmenes de conversaciones

Devuelve { items: [...], total }. Los resúmenes no incluyen messages, lo cual es adecuado para una lista en la barra lateral; si el usuario abre una conversación, usa después action: retrieve para recuperar por separado sus mensajes completos. Parámetros de filtrado opcionales: user_id, application_id, model_group, model.

action: update —— Cambiar el título o reescribir el historial

También se puede enviar messages, pero el servidor realizará una validación estricta del schema (debe tener la forma plegada de ToolUseContent); si no cumple, devolverá 400. Por lo general, solo se recomienda usarlo para cambiar title.

action: delete —— Eliminar una conversación

Devuelve { id, success: true }. Después de eliminarla no podrá recuperarse; confirma antes de realizar la llamada.

Migración fluida desde v1

Si ya estás usando /aichat/conversations, migrar a v2 casi no requiere cambios de código:
  1. Cambia la URL de https://api.acedata.cloud/aichat/conversations a https://api.acedata.cloud/aichat2/conversations.
  2. Si antes enviabas nombres de modelos v1 (como gpt-3.5, gpt-4-browsing, etc.), al cambiar a v2 se recomienda actualizar a modelos contemporáneos (como gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview, etc.).
  3. Los campos del flujo NDJSON se mantienen compatibles hacia atrás: cada evento text_delta sigue incluyendo delta_answer e id, por lo que los clientes existentes que analizan delta_answer línea por línea no necesitan cambios.
Después de la migración, puedes habilitar según sea necesario las nuevas capacidades de v2 (message multimodal, SSE, llamadas a herramientas, CRUD mediante action) y avanzar a tu propio ritmo.

Manejo de errores

La respuesta de error tiene el formato unificado:
Errores comunes:
  • 400 bad_request: faltan campos obligatorios, tool_use_id no coincide, el schema de messages no es válido, etc.
  • 401 invalid_token: la cabecera authorization es incorrecta.
  • 404 not_found: al usar action: retrieve / update / delete, no existe la conversación correspondiente al id.
  • 429 too_many_requests: se ha activado el límite de velocidad.
  • 500 chat_error: el LLM ascendente informó un error o completion_tokens=0 en esta ronda (se trata como no consumido y no se cobrará).
En las respuestas de streaming, los errores se emiten como eventos {"type":"error","message":"..."}, tras lo cual el flujo finalizará inmediatamente.

Conclusión

La API AI Chat v2, mientras mantiene la compatibilidad hacia atrás con v1, actualiza las conversaciones de «preguntas y respuestas de una o varias rondas» a «conversaciones observables orientadas a agentes»: entradas multimodales, llamadas a herramientas, pausa / reanudación, eventos estructurados en streaming y CRUD integrado. Se recomienda utilizar v2 directamente para nuevas integraciones; las integraciones existentes de v1 pueden migrar gradualmente y sin problemas por fases. Si tienes alguna pregunta, no dudes en contactar con nuestro equipo de soporte técnico.