Для AI-агентов: markdown этой страницы — /docs-content/changelog/2026-09-26.md индекс документации — /llms.txt

Изменения API: 26 сентября 2026

← Журнал изменений · Сентябрь 2026

BC-0926-1: ключ подписки Коворка у владельца без учётной записи Битрикс24 не ротируется, не включается заново и не продлевается

Поддержка старого формата до: не предусмотрена

Было

Владелец ключа подписки Коворка, вошедший из портала без учётной записи Битрикс24, мог ротировать такой ключ (POST /v1/keys/:id/rotate), а также вернуть отозванный ключ в статус ACTIVE и удлинить или снять его expiresAt (PATCH /v1/keys/:id).

Стало

Ротация отвечает 403 COWORK_BOX_SERVICE_ACCOUNT_DENIED. PATCH /v1/keys/:id отвечает тем же кодом только тогда, когда тело переводит ключ в ACTIVE из другого статуса либо удлиняет или снимает expiresAt. Остальные правки идут как раньше: переименование, отзыв ключа и сокращение срока по-прежнему успешны. Прежний ключ продолжает работать. Для владельцев с учётной записью Битрикс24 ничего не изменилось. Таблица кодов — Управление ключами.

Что делать интеграторам

Если вы ротируете ключ подписки Коворка или возвращаете его в работу — войти в кабинет учётной записью Битрикс24 и выпустить ключ от неё. Если вы ключи только переименовываете, отзываете или сокращаете им срок — менять ничего не нужно.

NEW-0926-2: Прямые действия над задачей через API

Для 14 действий над задачей появились именованные маршруты POST /v1/tasks/:taskId/{add-accomplices,add-auditors,approve,bind-crm-item,complete,defer,delegate,disapprove,pause,pause-timer,renew,start,start-timer,take}. Каждый маршрут вызывает одноимённый метод Битрикс24 — tasks.task.addAccomplices, tasks.task.addAuditors, tasks.task.approve, tasks.task.bindCrmItem, tasks.task.complete, tasks.task.defer, tasks.task.delegate, tasks.task.disapprove, tasks.task.pause, tasks.task.pauseTimer, tasks.task.renew, tasks.task.start, tasks.task.startTimer, tasks.task.take — с теми же параметрами. taskId передаётся в пути, остальные именованные аргументы метода — в JSON-теле. Результат Битрикс24 возвращается в data. Ключ должен разрешать запись и иметь скоуп task.

Маршруты и документация

FIX-0926-3: зацикленное рассуждение модели обрывается кодом reasoning_repetition

Было

Если модель с рассуждением начинала повторять в reasoning_content одни и те же фразы, поток POST /v1/chat/completions держался до срока обслуживания или до лимита max_tokens, а ответа так и не было. На запросе с response_format отказ приходил как 422 structured_output_truncated с советом поднять max_tokens и полем suggestedMaxTokens — на зацикленной модели больший бюджет только удлинял повтор, и попытка оплачивалась ещё раз.

Стало

Повтор одних и тех же фраз в рассуждении до начала ответа останавливается, не дожидаясь срока обслуживания и лимита max_tokens, — и на основном потоке, и на потоке резервной модели при исчерпанной квоте. В потоке перед data: [DONE] приходит событие {"error":{"code":"reasoning_repetition","type":"invalid_request_error"}}, статус потока остаётся 200 по протоколу; синхронный запрос с response_format получает 422 с кодом reasoning_repetition, полями finishReason и hint и без param и suggestedMaxTokens. Выход — повторить запрос с reasoning_effort: "none".

Обрывается только повтор одних и тех же фраз, а не перебор разных формулировок, и только в том, что приходит клиенту как reasoning_content: повторяющийся ответ в content, например массив одинаковых объектов, доходит целиком. Если модель присылает один и тот же текст сразу в оба канала, решает то, как он приходит клиенту: у модели с рассуждением этот текст приходит в content и доходит как ответ; если он приходит только как reasoning_content, его повтор обрывается так же, как рассуждение.

При response_format: {"type": "json_object"}, когда модель присылает сам ответ в reasoning_content как JSON-документ (начинается с { или [), готовый документ приходит в content ответом со статусом 200; если документ так и не сложился, приходит reasoning_repetition, а если он слишком длинный, чтобы его восстановить, повтор обрывается сразу. Без response_format ответ, пришедший только в reasoning_content, при зацикливании обрывается reasoning_repetition. Обычный обрыв по max_tokens без повтора по-прежнему отвечает structured_output_truncated.

FIX-0926-4: потоковый ответ чата всегда заканчивается причиной завершения

Было

Потоковый ответ POST /v1/chat/completions мог закончиться data: [DONE] без единого события с finish_reason. Так выглядели два разных случая: модель закончила ответ, но не прислала завершающего события, и соединение с моделью оборвалось посреди ответа. Клиент не мог отличить полный ответ от обрезанного, а часть клиентов не завершала ход без finish_reason.

Стало

Если модель закончила ответ без завершающего события, платформа сама добавляет перед data: [DONE] событие с пустым delta и finish_reason: "tool_calls", когда в ответе были вызовы инструментов, или finish_reason: "stop" в остальных случаях. Если соединение оборвалось раньше, чем пришла причина завершения, перед data: [DONE] приходит событие ошибки с кодом stream_incomplete, type: "server_error", retryable: true и retryAfter. Статус ответа по-прежнему 200, как у остальных ошибок внутри потока.

Влияние на интеграторов

Менять ничего не нужно. Клиент, который читает поток до конца и проверяет поле error, получит stream_incomplete тем же путём, что и stream_idle_timeout, и может повторить запрос с учётом retryAfter.