# API changes: September 19, 2026

[← Changelog](/docs/changelog) · [September 2026](/docs/changelog/2026-09)

### FIX-0919-2: a lost link to the cloud machine is no longer reported as its absence, and no longer advises creating a second one

**Before**

Every operation on a server whose record held no pointer to a cloud machine — wake, start, stop, reboot, resize, and the auto-wake inside deploy, exec, logs and upload — always answered `422 VM_MISSING` with the advice "delete this server and create a new one"; wake additionally carried the hint "no cloud resource will be leaked — there is nothing to free" and moved the record to the `error` status. An empty pointer, however, only means the pointer is missing FROM THE RECORD: if it was never written when the server was created, the machine exists, runs and is billed. In that case the delete-and-recreate advice made the client create a second machine while the first kept running with no record at all, so the hint itself produced a leak.

**After**

Before ruling, the platform checks its own cloud review, and it does so IDENTICALLY on every door. When the review sees a machine under this server's cloud name, the answer is `422` with the NEW code `VM_POINTER_LOST`: the link to the machine is lost, the machine is most likely running and billed, deleting the server and creating a new one is NOT the remedy, and the platform sees the case so support can restore the link. The operation still does not run — without the pointer it cannot — but the record is NOT moved to `error` and keeps its previous status. When the review sees no machine under that name the answer is the previous one — `422 VM_MISSING` with the same text and the same side effects. The cloud review refreshes once an hour, so a record it has not caught up with yet still gets the previous `VM_MISSING` answer.

**Affected endpoints:** [POST /v1/infra/servers/{id}/wake](/docs/infra/lifecycle/wake), [POST /v1/infra/servers/{id}/start](/docs/infra/lifecycle/start), [POST /v1/infra/servers/{id}/stop](/docs/infra/lifecycle/stop), [POST /v1/infra/servers/{id}/reboot](/docs/infra/lifecycle/reboot), plus the auto-wake inside [POST /v1/infra/servers/{id}/deploy](/docs/infra/deploy/deploy), [POST /v1/infra/servers/{id}/exec](/docs/infra/deploy/exec), [GET /v1/infra/servers/{id}/logs](/docs/infra/deploy/logs) and [POST /v1/infra/servers/{id}/upload](/docs/infra/deploy/upload). A galaxy app has no machine of its own BY DESIGN, so its previous answer is unchanged.

### FIX-0919-3: `wasEverCommercial` in `GET /v1/me` is payment history, not access

**Before**

The description of the `tariff.wasEverCommercial` field in [GET /v1/me](/docs/keys-auth/me) and the MCP guidance for agents (the `upgrade-from-trial` prompt, the `vibe://tariff-gate-reference` reference) presented the flag as trust: as if a Bitrix24 account that was ever on a commercial plan kept access after a downgrade, only the balance could stop it, and it got OPEN mode past the plan check.

**After**

The descriptions now match the platform behaviour in force since 02.09.2026: the flag only records that the account was once seen on a commercial plan. It grants neither infrastructure access nor OPEN mode and lifts no refusal — access is decided by the current plan, subscription and demo. API responses are unchanged.

**What integrators should do**

Do not branch on `wasEverCommercial`. Read the availability of an operation from `capabilities` in the same response, and the reason for a refusal from its error code.

### NEW-0919-4: server run mode and the work-schedule library are now available over the API

The run mode that V1 reads already expose (`runMode`, `workSchedule`) can now be set with a key as well. `PATCH /v1/infra/servers/{id}/run-mode` accepts `{"mode":"ALWAYS"}`, `{"mode":"IDLE","idleMinutes":30}` or `{"mode":"SCHEDULE","scheduleId":"..."}` and answers with the same run-mode object the reads return.

The schedule library is open as well: `GET/POST /v1/work-schedules` and `GET/PATCH/DELETE /v1/work-schedules/{id}`, with windows as `[{"isoDay":1,"start":"09:00","end":"18:00"}]` in the schedule's own time zone. The library is shared per Bitrix24 account, so an edit carries `version` and answers `409 WORK_SCHEDULE_STALE` when someone has changed the schedule meanwhile. A preset schedule cannot be edited (`403 WORK_SCHEDULE_PRESET_READONLY`). A schedule with assigned machines is deleted only with `?reassign=true` — apps move to idle sleep, agents and bots to around the clock, and without that consent the answer is `409 WORK_SCHEDULE_IN_USE`. A galaxy host has no run mode of its own (`400 GALAXY_NOT_SUPPORTED`), and until run modes are rolled out to the Bitrix24 account the write answers `400 RUN_MODE_UNAVAILABLE`. Existing requests, including `PATCH /v1/infra/servers/{id}/sleep`, keep working as before.

### FIX-0919-5: the OpenAPI specification and the API reference describe task history, kanban stages and CRM reference aggregation

**Before**

The machine specification `GET /v1/openapi.json` and the API reference lacked the working operations [GET /v1/tasks/:taskId/history](/docs/task-history) and [GET /v1/tasks/stages/:entityId](/docs/task-stages), as well as `POST /aggregate` of entities with no fields to group by: [POST /v1/currencies/aggregate](/docs/entities/currencies/aggregate), [POST /v1/statuses/aggregate](/docs/entities/statuses/aggregate), [POST /v1/deal-categories/aggregate](/docs/entities/deal-categories/aggregate), `POST /v1/calendar-events/aggregate`, `POST /v1/telephony-lines/aggregate` and `POST /v1/humanresources/nodes/aggregate`. A client generated from the specification and an AI agent could not find them, although the first five operations are described on documentation pages. In addition, over two hundred reference cards showed no scope although the specification declared one, among them every operation of the Duplicate search, Stage history, CRM card layout, Requisite links and Warehouses sections. For [POST /v1/products/aggregate](/docs/entities/products/aggregate) the specification promised a filter with operators, while the operation accepts exact matches only, just like product search.

**After**

All eight operations are described in the specification and the reference. For entities with no fields to group by, the aggregation description names what the operation accepts: `count` over `"*"` and the numeric functions over the entity's numeric fields, with no `groupBy`. Where an entity's filter is restricted — exact matches only, or only certain keys — the aggregation filter is described with the same list of accepted keys as search. The filter keys that are passed as call parameters and without which the operation answers `MISSING_REQUIRED_PARAMS` are marked as required in the specification, and the reference card example sends them. A reference card shows the scope the specification declares. The behaviour of the operations has not changed.

**Impact on integrators**

None: requests and responses are unchanged. A client generated from the specification gets methods for these eight operations once regenerated.

### BC-0919-6: a project deploy key is issued only to an admitted Bitrix24 account

> Old format supported until: not provided

**Before**

`POST /v1/cowork/deploy-key` checked the key scope, the platform switches and the presence of a Cowork/Code seat, and stopped there. An account whose plan does not grant platform access still received a working project key, even though the cabinet refused to issue the same key to it. An employee whose account forbids server creation received the key as well, and hit the refusal only on the first `POST /v1/infra/servers` call.

**After**

Before issuing the key the route asks the same two doors the cabinet and server creation ask: whether the platform admits the account, and whether the account's server-creation policy covers the key owner. An account the platform does not admit receives `402 INT_TARIFF_REQUIRED`, or `402 INT_VIBE_PLUS_REQUIRED` where access is narrowed to a paid Vibe+ plan. If the platform could not read the account plan, the answer is `403 PORTAL_TARIFF_UNREADABLE`, and buying a plan does not clear it. An account with infrastructure switched off receives `403 INFRA_NOT_PERMITTED`, and an employee outside the policy receives `403 SERVER_CREATION_DISABLED` or `403 SERVER_CREATION_ADMINS_ONLY`. A refused call issues no key and leaves the previous project key valid, so running deployments are not interrupted.