API changes: October 15, 2026

← Changelog · October 2026

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.

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 and GET /v1/calls/followups/:callId 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.

NEW-1015-9: Message view count on request

GET /v1/chats/messages/{messageId}/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 and GET /v1/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 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.