# API changes: October 15, 2026

[← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10)

### FIX-1015-1: Exact counts for searches across time windows

**Before**

For searches with `meta.autoWindowed: true`, `meta.total` could contain only the number of rows collected before an early stop at `limit`, rather than the number of all matches.

**After**

The `meta.total` field is omitted when an incomplete traversal of time windows leaves the exact count unknown. A complete successful result retains the exact count after duplicates are removed, including `0` for an empty result. The API does not make additional requests solely to obtain a count. Searches with `autoWindow: false` retain their existing behavior.

**Impact on integrators**

Check whether `meta.total` is present before using it. `data.length` is the number of returned records; `meta.hasMore` indicates whether more results are available.

### NEW-1015-2: Application database restore

`POST /v1/infra/servers/:id/db/restore` accepts a SQLite restore from a completed copy, including copies of deleted applications in the same account. A protective copy precedes replacement; stopped applications remain stopped. The response is `202 QUEUED`, with progress in the copy list's `restore` field. Read-only keys cannot start a restore. [Restore guide](/docs/infra/database/restore).

### BC-1015-3: entity writes reject a nested fields object

> Old format supported until: not provided

**Before**

An entity create or update request with a `fields` object could return success even though the nested values were not stored.

**After**

Send entity fields at the root of the JSON body. On write paths that add their own envelope, a `fields` object is rejected before the Bitrix24 call with `400 NESTED_FIELDS_ENVELOPE`. Batch errors appear in the item or call result. A declared `fields` property, such as the one on documents, keeps its existing behavior.

**What integrators should do**

Remove the outer `fields` envelope from entity create, update, import, and batch write bodies. Check that field names are at the root of each write object.

### BC-1015-4: contact names longer than 50 characters are rejected before writing

> Old format supported until: not provided

**Before**

The `name` field accepted more than 50 characters when creating or updating a contact. Bitrix24 stored only the first 50, while the response reported a successful write.

**After**

The `name` limit is 50 Unicode code points. Single `POST /v1/contacts` and `PATCH /v1/contacts/{id}` reject longer values with `400 INVALID_PARAMS` before writing. Entity batch `POST /v1/contacts/batch` returns `400 BATCH_ITEM_VALIDATION`, and import `POST /v1/contacts/import` returns `400 IMPORT_ITEM_VALIDATION`; both validate the entire input before writing. In `POST /v1/batch`, an invalid call receives `INVALID_PARAMS` in `data.errors`, while other valid calls may proceed. The limit is published in OpenAPI, `GET /v1/contacts/fields` and `GET /v1/guide`. Other contact fields are not restricted by this limit.

**What integrators should do**

Check the length of `name` before sending it. If it exceeds 50 characters, ask the user to shorten the name and send it again. Do not truncate the name without the user's consent.

### FIX-1015-5: Updating an all-day event preserves its all-day flag

**Before**

`PATCH /v1/calendar-events/:id` without `skipTime` could clear the all-day flag and reduce the duration to zero.

**After**

Updating other fields preserves `skipTime` and the all-day dates. Explicit `skipTime: false` still clears the flag.

**Impact on integrators**

Repeating `skipTime: true` on every update is no longer required.

### FIX-1015-6: call follow-up methods are available on every account

**Before**

The [POST /v1/calls/followups/list](/docs/calls/followup/list) and [GET /v1/calls/followups/:callId](/docs/calls/followup/get) methods were marked as rolling out with Bitrix24 update `call 26.600.0`: the docs carried a rollout notice, and on an account without the update the platform answered `422 METHOD_NOT_YET_AVAILABLE` with an `error.release` field.

**After**

Update `call 26.600.0` is on every account, and the rollout notice is removed from the docs and the `openapi.json` spec. These methods no longer return `METHOD_NOT_YET_AVAILABLE`; the HTTP 200 response of working calls is unchanged. No integration changes are required.

### BC-1015-7: The extranet group flag is read-only

> Old format supported until: not provided

**Before**

`POST /v1/workgroups` and `PATCH /v1/workgroups/{id}` accepted `isExtranet` and the raw `IS_EXTRANET` with a successful response, although Bitrix24 derives the flag from the group's site bindings and does not store the direct value.

**After**

Submitting the flag, including `false` and `true`, is rejected before a write: single operations return `400 READONLY_FIELD`; `POST /v1/workgroups/batch` with `action:create|update` returns `400 BATCH_ITEM_VALIDATION`. In `POST /v1/batch`, individual operation errors use `READONLY_FIELD`: all rejected means HTTP 400, while a mixed result means HTTP 200 with errors for the rejected operations. The field is published as read-only; group reads still return its actual value. Writing `siteId` and `SITE_ID` remains prohibited.

**What integrators should do**

Remove `isExtranet` and its raw variants from create and update bodies, including batch items. Send only writable fields. If you need to select the group kind, use the capabilities of Bitrix24: assigning this flag directly through the Vibecode API does not perform that selection.

### NEW-1015-8: Application database writes via API and MCP

`POST /v1/infra/servers/:id/db/execute` runs up to 64 SQL statements in one transaction. `POST/PATCH/DELETE /v1/infra/servers/:id/db/tables/:table/rows[/:key]` edit single rows; reads return `rowKeys` and per-table editability in the schema. A protective copy is prepared before every write: until it is ready the response is `409 APP_DB_BACKUP_NOT_READY` with the copy id and `Retry-After`. Read-only keys cannot write. A write with an unknown outcome is never retried automatically. MCP `manage_app_db` gains `action: execute`, retrying only while the copy is being prepared. [Execute guide](/docs/infra/database/execute).

### NEW-1015-9: Message view count on request

[GET /v1/chats/messages/{messageId}/viewers](/docs/chats/messages/viewers) accepts the optional `includeViewedCount` parameter with a value of `Y` or `N`. The value is forwarded to Bitrix24 unchanged. With `Y`, the response may contain `viewedCount` — the total message view count, independently of the reader page size. Requests without the parameter keep their previous behaviour.

### BC-1015-10: Cowork/Code Demo requires employee consent

> Old format supported until: not provided

**Before**

Signing in or creating a key automatically activated Demo when promotion conditions were met.

**After**

Signing in and creating a key no longer activate Demo automatically. Previously granted Demo access remains valid.

[GET /v1/cowork/me](/docs/cowork/me) and [GET /v1/cowork/state](/docs/cowork/state) return `demoOffer` with the tier, duration, rules link and `shouldPrompt`. After declining, the invitation is suppressed and the promotion place remains available.

**What integrators should do**

Clients must offer a choice and call `POST /v1/cowork/demo` with `action: accept`, the offered `tier` and `durationDays`, or with `action: decline`. A desktop key with `vibe:cowork` is required. A 409 `COWORK_DEMO_UNAVAILABLE` means the state and offer must be refreshed. For `reason: terms_changed`, the response includes a fresh `error.details.demoOffer` (`tier`, `durationDays`, `rulesUrl`, `shouldPrompt`); display it and request consent again. Other reasons omit `details`. Repeated acceptance does not extend Demo.

### FIX-1015-11: coupon redemption no longer refuses accounts backed by platform staff

**Before**

`POST /v1/cowork/coupon/redeem` refused with `COUPON_SELF_PORTAL` (`HTTP 409`) when the account was backed by a platform employee holding the coupon-issuing right — the redeemer themselves, or a member, API key owner or server owner on that account. The coupon stayed intact.

**After**

That refusal is removed: a coupon is redeemed on any account under the common rules, and `COUPON_SELF_PORTAL` is no longer returned. A successful redemption still answers HTTP 200 with the same body; the code is removed from the method's response table in the docs. No integration changes are required.

### FIX-1015-12: deploying a Docker Compose app no longer fails on its own container

**Before**

[POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) on a dedicated server whose `start` command brings the app up with `docker compose up` failed with `DEPLOY_FAILED` at the `healthcheck` step whenever Compose did not recreate the container. The previous `docker-proxy` process kept holding the port, and the port check treated it as an unrelated holder — both with `"hardening": "off"` and after the automatic hardening rollback.

**After**

The `stop_existing` step stops, with `docker stop`, a running Docker Compose container of the app itself when it publishes the app port and the project directory in its `com.docker.compose.project.working_dir` label equals `extractTo` or sits inside it. The `start` command brings the container back up, and the deploy passes the port check. The `stop_existing` step names the stopped container in `stdout`. Other unrelated processes and containers of other projects are still not terminated.

**Impact on integrators**

No action required. The `start` command is expected to bring the app container up: if it does not, the deploy fails at the `healthcheck` step because the port stays free.

### FIX-1015-13: Build reports a faulty host

When calling `POST /v1/infra/servers/:id/deploy` for a galaxy app, an absent Docker installation on the host now returns `502 GALAXY_HOST_UNHEALTHY` with `retryable: false` before the build starts instead of `GALAXY_APP_BUILD_FAILED`. Contact support to repair the host before retrying the deployment. Do not delete the app: recreating it does not repair the host.