Skip to main content
AI Chat v2 API (/aichat2/conversations) — це нове покоління інтерфейсу діалогів, яке є повністю оновленою версією AI Chat API. На основі лаконічності v1 та керованих багатораундових діалогів він розширює:
  • Мультимодальні введення користувача: безпосередньо передавайте текст + зображення + блоки файлів через структуроване поле message, без необхідності попередньо непрямо додавати їх за допомогою references.
  • Агентні виклики інструментів: вбудований набір інструментів для онлайн-пошуку, отримання вебсторінок, читання файлів тощо, а також можливість підключати MCP-сервери, авторизовані користувачем (Google Drive, Notion, Slack, GitHub тощо); модель може в межах одного запиту автономно багаторазово викликати інструменти для виконання складних завдань.
  • Структуровані потокові події: через accept: text/event-stream або application/x-ndjson можна отримувати події text_delta, tool_use, tool_result, thinking, citation, card, artifact тощо для кожного токена, що зручно для окремого рендерингу за відповідними типами на фронтенді.
  • Можливість переривання / відновлення: коли моделі потрібно, щоб користувач доповнив інформацію, вона надсилає подію ask_user_question і призупиняється; під час наступного виклику достатньо повернути відповідь через tool_results, щоб продовжити.
  • Нові CRUD-дії: через поле action на тому самому endpoint можна виконувати retrieve / retrieve_batch / update / delete, без потреби в додатковому API для керування діалогами.
  • Список моделей, що постійно оновлюється: за замовчуванням підключені сучасні моделі GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 тощо.
Водночас на рівні тіла запиту він повністю зворотно сумісний із v1: достатньо передати лише model + question (+ необов’язкові stateful / id / references / preset), щоб отримати JSON-відповідь {answer, id}, еквівалентну v1; тому для міграції з /aichat/conversations не потрібно переписувати клієнт — достатньо замінити шлях на /aichat2/conversations.
Якщо ви зараз використовуєте /aichat/conversations, старий інтерфейс і надалі буде доступний, і ви можете мігрувати у зручному для себе темпі.

Процес подання заявки

Щоб використовувати AI Chat v2 API, спершу перейдіть до консолі Ace Data Cloud, щоб отримати ваш API Token і зберегти його для подальшого використання. Якщо ви ще не увійшли в систему або не зареєструвалися, вас буде автоматично перенаправлено на сторінку входу із запрошенням зареєструватися та увійти; після завершення ви автоматично повернетеся на поточну сторінку. Один API Token дає змогу викликати всі сервіси платформи, не потрібно подавати окрему заявку для кожного сервісу. Під час першого отримання надається безкоштовний ліміт, що дозволяє безкоштовно ознайомитися з можливостями; якщо ліміту недостатньо, ви можете поповнити універсальний баланс у консолі.
📘 Повна документація: AI Chat v2 API →

Базове використання

Найпростіше використання повністю відповідає v1: передайте model + question і отримайте {answer, id}. Приклад CURL:
Результат, що повертається:
Приклад Python:
Доступні значення model можна безпосередньо переглянути у випадаючому списку панелі Try праворуч; поширені категорії включають:
  • 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 тощо
  • 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 тощо
  • 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 тощо
  • xAI: grok-4 тощо
  • DeepSeek: deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528 тощо
  • Moonshot: kimi-k3, kimi-k2.6, kimi-k2.5 тощо
  • Zhipu: glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v тощо
Докладні правила тарифікації дивіться в картці Pricing на сторінці сервісу.

Багатораундовий діалог

Як і у v1, передайте stateful: true, щоб увімкнути збереження діалогу; API поверне id; у наступних запитах достатньо передавати цей id, щоб продовжити діалог, без необхідності самостійно підтримувати історію messages. Перший запит:
Повертається:
Другий запит, додайте той самий id:
stateful за замовчуванням має значення true; пропускання та явна передача true є еквівалентними. Якщо ви не хочете, щоб сервер зберігав цей раунд діалогу, можна явно встановити stateful: false.

Потокова відповідь

v2 підтримує два потокові формати, які вибираються за заголовком accept:

Приклад NDJSON

Кожен рядок NDJSON є структурованою подією; найпоширенішою є text_delta:

Приклад SSE

Використання EventSource у браузері не підтримує власне тіло запиту, тому рекомендується використовувати fetch + ручний розбір на зрізи за \n\n:

Типи потокових подій

Для клієнтів, яких цікавить лише фінальна відповідь, об’єднання всіх content із text_delta є еквівалентним answer у режимі application/json.

Мультимодальне введення

Якщо введення користувача містить зображення або файл, передавайте message (масив) замість question. Кожен елемент масиву — це блок вмісту:
Підтримувані типи блоків:
  • text — звичайний текст, обов’язкове поле text.
  • image_url — зображення, обов’язкове поле image_url.url.
  • file_url — файл (PDF, CSV, TXT тощо), обов’язкове поле file_url.url.

Зв’язок із references у v1

Для сумісності зі старими клієнтами v2 і надалі розпізнає поле references: ["https://...", ...]:
  • Суфікс URL — jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, автоматично перетворюється на блок image_url;
  • Інші розширення перетворюються на блок file_url;
  • Якщо водночас також надано question, він додається попереду як блок text.
Тому, якщо ви лише хочете перейти з v1 і не хочете змінювати тіло запиту, достатньо змінити шлях на /aichat2/conversations, а початковий спосіб використання references продовжить працювати як звично. Якщо потрібен точніший контроль (наприклад, розмістити кілька зображень між текстом або якщо порядок дуже важливий), безпосередньо використовуйте масив message.

Виклики інструментів і MCP

Основне покращення v2 полягає в тому, що модель може самостійно викликати інструменти для виконання багатокрокових завдань, це увімкнено за замовчуванням, і клієнту не потрібно виконувати жодних додаткових налаштувань у запиті. Типові сценарії:
  • Користувач запитує: «Допоможи мені пошукати, які нові виставки нещодавно проходять у Шанхаї» → модель викликає вбудований web search → упорядковує результати у відповідь.
  • Користувач запитує: «Прочитай цей PDF, а потім напиши резюме» → модель викликає file_read → пише резюме.
  • Користувач уже авторизував Google Drive / GitHub / Notion тощо у Connections → модель може викликати відповідні інструменти MCP для читання та запису їхніх даних.
У потоці NDJSON / SSE виклики інструментів відображаються через два типи подій tool_use і tool_result, наприклад:
Якщо ви не хочете відображати у фронтенді деталі викликів інструментів, достатньо ігнорувати такі типи подій, як tool_use / tool_result / card / citation; фінальний вивід моделі все одно надходить через потік text_delta. max_turns може обмежити максимальну кількість раундів самостійних викликів інструментів моделлю в цьому запиті, а верхня межа за замовчуванням визначається платформою. Якщо встановити мале значення (наприклад, max_turns: 1), можна примусово отримати одноразову відповідь і не дозволити жодних викликів інструментів.

Асинхронне виконання та авторизація без нагляду

Якщо ваш виклик надходить з Webhook сповіщень, CI/CD, системи моніторингу або інших фонових завдань, можна встановити async: true, щоб інтерфейс негайно повернув ID завдання, а виконання продовжилося у фоні:
Приклад відповіді:
Після цього можна використовувати action: retrieve + id для запиту результату розмови; також можна надати callback_url, і після завершення завдання платформа надішле { status, answer, usage, error } методом POST на вашу адресу зворотного виклику. callback_url повинен використовувати http / https, і не можна безпосередньо вказувати localhost або літеральну адресу приватного IP. У фонових завданнях зазвичай немає людини, яка може натиснути підтвердження. Якщо ви хочете, щоб певні Skill або MCP Server виконували дії надсилання, публікації, запису тощо в режимі без нагляду, явно передайте в тілі запиту список попередньої авторизації:
Значення в allowed_skills — це slug підключених Skill; значення в allowed_mcp_servers — це slug підключених MCP Server. Skill / MCP Server, які не внесені до попередньої авторизації, у режимі без нагляду все ще можуть лише виконувати попередній перегляд, dry-run або відмовлятися від виконання операцій запису. Якщо потрібен детальніший контроль, також можна використовувати еквівалентний об’єкт unattended_policy:
Попередня авторизація — це самі ці два списки: порожній список означає, що жодні можливості не авторизовано, без потреби в додатковому полі-перемикачі. Зверніть увагу: попередня авторизація означає лише, що «цей запит дозволяє цим можливостям пропустити ручне підтвердження в режимі без нагляду». Конкретний Skill усе одно повинен підтримувати --unattended-confirm або відповідний механізм безпеки; інакше він продовжить виконувати dry-run і не виконуватиме операції запису безпосередньо.

Відновлення призупиненої розмови

Деякі інструменти змушують модель «ставити користувачу зустрічне запитання», і в цей момент модель надсилає подію ask_user_question, а розмова заморожується у стані awaiting_user_input:
У фронтенді відрендерте цю подію як картку, щоб користувач вибрав відповідь, а потім надішліть наступний запит із тим самим id, повернувши відповідь через tool_results:
tool_use_id у тілі запиту обов’язково має повністю збігатися з tool_id під час призупинення; у разі невідповідності буде повернуто 400. Коли в запиті одночасно присутні tool_results, question / message / references усі ігноруються. Якщо користувач вирішить відмовитися від цього питання, достатньо безпосередньо передати новий question / message, і платформа автоматично позначить призупинений виклик інструменту як «пропущений користувачем».

Керування розмовами (CRUD)

v2 на тому самому endpoint надає легковагове керування розмовами через поле action, без потреби окремо відкривати API.

action: retrieve —— отримати розмову

Повертає повний документ розмови (включно з історією messages, model, title, tools_used тощо).

action: retrieve_batch —— перелічити стислий опис розмов

Повертає { items: [...], total }. Стислий опис не містить messages, він підходить для списку на бічній панелі; якщо користувач відкриває певну розмову, потім окремо отримайте її повні повідомлення за допомогою action: retrieve. Необов’язкові параметри фільтрації: user_id, application_id, model_group, model.

action: update —— змінити заголовок або переписати історію

Також можна передати messages, але сервер виконуватиме сувору перевірку schema (має бути форма згорнутого ToolUseContent), у разі невідповідності буде повернено 400. Зазвичай рекомендується використовувати це лише для зміни title.

action: delete —— видалити одну розмову

Повертає { id, success: true }. Після видалення відновлення неможливе, будь ласка, підтвердьте перед викликом.

Плавна міграція з v1

Якщо ви вже використовуєте /aichat/conversations, міграція на v2 майже не потребує змін у коді:
  1. Змініть URL з https://api.acedata.cloud/aichat/conversations на https://api.acedata.cloud/aichat2/conversations.
  2. Якщо раніше ви передавали назви моделей v1 (наприклад, gpt-3.5, gpt-4-browsing тощо), під час переходу на v2 рекомендується оновитися до сучасних моделей (наприклад, gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview тощо).
  3. Поля потоку NDJSON залишаються зворотно сумісними: кожна подія text_delta як і раніше містить delta_answer та id, тому клієнту, який раніше розбирав delta_answer построково, не потрібно нічого змінювати.
Після міграції можна за потреби ввімкнути нові можливості v2 (мультимодальне message, SSE, виклики інструментів, action CRUD) і впроваджувати їх у зручному темпі.

Обробка помилок

Відповіді з помилками уніфіковані:
Поширені помилки:
  • 400 bad_request: відсутні обов’язкові поля, tool_use_id не збігається, schema messages є недійсною тощо.
  • 401 invalid_token: заголовок authorization неправильний.
  • 404 not_found: під час action: retrieve / update / delete розмова, що відповідає id, не існує.
  • 429 too_many_requests: спрацювало обмеження швидкості.
  • 500 chat_error: помилка висхідної LLM або в цьому раунді completion_tokens=0 (обробляється як невикористане, плата не стягується).
У потоковій відповіді помилка надсилається як подія {"type":"error","message":"..."}, після чого потік одразу завершується.

Висновок

AI Chat v2 API, зберігаючи зворотну сумісність із v1, оновлює діалоги з «одиночних / багатораундових запитань і відповідей» до «спостережуваних Agent-діалогів»: мультимодальний ввід, виклики інструментів, можливість призупинення / відновлення, потокові структуровані події, вбудований CRUD. Для нових інтеграцій рекомендується одразу використовувати v2; наявні інтеграції v1 можна плавно мігрувати поетапно. Якщо у вас виникнуть будь-які запитання, будь ласка, звертайтеся до нашої команди технічної підтримки в будь-який час.