API changes: September 26, 2026

← Changelog · September 2026

BC-0926-1: the Cowork subscription key of an owner without a Bitrix24 account cannot be rotated, re-enabled or extended

Old format supported until: not provided

Before

The owner of a Cowork subscription key who signed in from their Bitrix24 without a Bitrix24 account could rotate that key (POST /v1/keys/:id/rotate), and could also return a revoked key to ACTIVE and extend or drop its expiresAt (PATCH /v1/keys/:id).

After

Rotation answers 403 COWORK_BOX_SERVICE_ACCOUNT_DENIED. PATCH /v1/keys/:id answers the same code only when the body moves the key to ACTIVE from another status, or extends or drops expiresAt. Every other update works as before: renaming, revoking and shortening the expiry still succeed. The previous key keeps working. Nothing changed for owners with a Bitrix24 account. Code table — Key management.

What integrators should do

If you rotate a Cowork subscription key or bring it back into service, sign in to the account with a Bitrix24 account and issue the key from it. If you only rename, revoke or shorten the expiry of keys, nothing changes for you.

NEW-0926-2: Direct task actions through the API

14 task actions now have named routes POST /v1/tasks/:taskId/{add-accomplices,add-auditors,approve,bind-crm-item,complete,defer,delegate,disapprove,pause,pause-timer,renew,start,start-timer,take}. Each route calls the Bitrix24 method of the same name — 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 — with the same parameters. Pass taskId in the path and the other named method arguments in the JSON body. The Bitrix24 result is returned in data. The key must allow writes and have the task scope.

Routes and documentation

• POST /v1/tasks/:taskId/add-accomplices
• POST /v1/tasks/:taskId/add-auditors
• POST /v1/tasks/:taskId/approve
• POST /v1/tasks/:taskId/bind-crm-item
• POST /v1/tasks/:taskId/complete
• POST /v1/tasks/:taskId/defer
• POST /v1/tasks/:taskId/delegate
• POST /v1/tasks/:taskId/disapprove
• POST /v1/tasks/:taskId/pause
• POST /v1/tasks/:taskId/pause-timer
• POST /v1/tasks/:taskId/renew
• POST /v1/tasks/:taskId/start
• POST /v1/tasks/:taskId/start-timer
• POST /v1/tasks/:taskId/take

FIX-0926-3: looping model reasoning is cut off with the reasoning_repetition code

Before

If a reasoning model started repeating the same sentences in reasoning_content, the POST /v1/chat/completions stream was held until the service deadline or the max_tokens limit, and no answer ever came. On a request with response_format the refusal arrived as 422 structured_output_truncated advising to raise max_tokens, with a suggestedMaxTokens field — on a looping model a larger budget only made the repetition longer, and the attempt was billed once more.

After

Repetition of the same sentences in the reasoning before the answer starts is stopped without waiting for the service deadline or the max_tokens limit — both on the main stream and on the fallback model stream when the quota is exhausted. In a stream the event {"error":{"code":"reasoning_repetition","type":"invalid_request_error"}} arrives before data: [DONE], and the stream status stays 200 by protocol; a synchronous request with response_format gets 422 with the code reasoning_repetition, the finishReason and hint fields and no param or suggestedMaxTokens. The way out is to send the request again with reasoning_effort: "none".

Only repetition of the same sentences is cut off, not a run of different wordings, and only in what reaches the client as reasoning_content: a repetitive answer in content, such as an array of identical objects, is delivered in full. If the model sends the same text into both channels at once, what counts is how it reaches the client: for a reasoning model this text arrives in content and is delivered as the answer; if it arrives only as reasoning_content, its repetition is cut off the same way as reasoning.

With response_format: {"type": "json_object"}, when the model sends the answer itself in reasoning_content as a JSON document (starting with { or [), the complete document arrives in content with status 200; if the document never comes together, reasoning_repetition arrives, and if it is too long to be recovered, the repetition is cut off at once. Without response_format an answer that arrives only in reasoning_content is cut off with reasoning_repetition when it loops. A regular cut-off at max_tokens without repetition still answers structured_output_truncated.

FIX-0926-4: the streamed chat response always ends with a finish reason

Before

A streamed POST /v1/chat/completions response could end with data: [DONE] without a single event carrying finish_reason. Two different cases looked like this: the model finished its answer but sent no terminal event, and the connection to the model dropped mid-answer. A client could not tell a complete answer from a cut one, and some clients did not end the turn without finish_reason.

After

If the model finished its answer without a terminal event, the platform adds one before data: [DONE] itself: an empty delta with finish_reason: "tool_calls" when the answer contained tool calls, or finish_reason: "stop" otherwise. If the connection dropped before a finish reason arrived, an error event with the code stream_incomplete, type: "server_error", retryable: true and retryAfter arrives before data: [DONE]. The response status remains 200, as for the other errors inside the stream.

Impact on integrators

No change is required. A client that reads the stream to the end and checks the error field receives stream_incomplete the same way as stream_idle_timeout and can retry the request, honoring retryAfter.

FIX-0926-5: a large ERP user mapping replacement no longer answers 503

Before

A full mapping replacement PUT /v1/cowork/onec/access/legacy/mappings that touched several thousand mappings could be refused with HTTP 503, the DB_TRANSIENT code and a Retry-After header. The request was valid, yet nothing was saved.

After

A replacement of several thousand mappings goes through in a single request. A valid replacement within the limits is committed, and the response remains HTTP 200.

Impact on integrators

No change is needed. Retrying after a 503 is still safe: the replacement sets the complete mapping set.