Перейти до основного вмісту
AI Chat v2 API (/aichat2/conversations) — це інтерфейс діалогів нового покоління, що є повністю оновленою версією AI Chat API. На основі лаконічності v1 та керованих багатораундових діалогів він розширює:
  • Мультимодальні введення користувача: надсилайте текст + зображення + блоки файлів безпосередньо через структуроване поле message, без потреби спочатку непрямо додавати їх через references.
  • Виклики інструментів у стилі Agent: вбудований набір інструментів для пошуку в інтернеті, отримання вебсторінок, читання файлів тощо, а також можливість підключення авторизованих користувачем 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-дії: на тому самому endpoint через поле action виконуйте 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, спочатку отримайте ваш API Token у консолі Ace Data Cloud та збережіть його для подальшого використання. Якщо ви ще не ввійшли або не зареєструвалися, вас буде автоматично перенаправлено на сторінку входу для реєстрації та входу, а після завершення ви автоматично повернетеся на поточну сторінку. Один 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.1-pro, 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 може обмежити максимальну кількість раундів самостійних викликів інструментів моделлю в цьому запиті, діапазон становить 1–500, а за замовчуванням, якщо не вказано, — 500. Якщо встановити мале значення (наприклад, 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 надає легковагове керування розмовами через поле action у тому самому endpoint, без потреби відкривати окремий 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: розмова, що відповідає id, не існує під час action: retrieve / update / delete.
  • 429 too_many_requests: спрацювало обмеження швидкості.
  • 500 chat_error: помилка висхідної LLM або completion_tokens=0 у цьому раунді (обробляється як невикористане, плата не стягується).
У потоковій відповіді помилка надсилається як подія {"type":"error","message":"..."}, після чого потік одразу завершується.

Висновок

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