API changes: November 13, 2026

← Changelog · November 2026

BC-1113-1: a foreign enum option id is refused before the field is written

Old format supported until: not provided

Before

POST /v1/items/{entityTypeId}/userfields with a positive option id that belongs to another field answered 201, and the created field came back without options. PATCH /v1/userfields/{entity}/{id} with such an id in list answered 200, and the options stayed as they were. The option was not written, although the response reported success.

After

Both requests are refused before the write: 400 INVALID_ENUM, nothing is written. On field update the current options are read first, and the id is checked against them. If the current options cannot be read, the request is not refused: the field is updated, and Bitrix24 checks the passed options. Options without an id and options with an id of the same field work as before: on creation the field gets new options, on update the passed options remain.

What integrators should do

On field creation, pass options without an id. On update, pass an id from the GET /v1/userfields/{entity}/{id} response, and add a new option without an id.

NEW-1113-3: content proof and explicit retry for a Drive version upload

After a version upload times out, GET /v1/disk/uploads/:operationId may confirm applied from SHA-256 of the current file or an eligible version. Without positive proof, the result stays unknown: unchanged history does not prove absence. After waiting at least five minutes, the agent can create a new attempt through POST /v1/disk/uploads/reserve with lineage.kind: "retry" and the exact same intent, then submit the original bytes. The current file is checked before another dispatch. Matching content gives applied without another write; a detected foreign edit stops dispatch. The original call may complete later, and the file may change between the check and the write.

Send X-Disk-Upload-Response-Version: 2 on POST /v1/disk/uploads/reserve, POST /v1/disk/uploads, GET /v1/disk/uploads/:operationId, and GET /v1/disk/uploads requests to read the outcome of the whole chain. Without the header, the previous strict v1 response describes the individual attempt.

FIX-1113-4: GET /v1/ai/quota shows the current quota window

Before

When an account made no charges after its 30-day AI quota window ended, GET /v1/ai/quota continued to show dates and usage from the previous window. An app could read the quota as exhausted.

After

The response shows the current window: data.pctUsed is 0, data.exhausted is false when the limit is positive, data.period.start is the request time, data.resetAt is 30 days later, and data.byModel includes calls from the current window only. After the first charge, the window starts at the charge time.

Impact on integrators

If your app stops requests when data.exhausted is true, use the refreshed value in the response. The request format does not change. Until the first charge, data.period.start and data.resetAt move with the request time.

FIX-1113-5: static apps send Cache-Control: no-cache

Before

An app with runtime: "static" deployed through POST /v1/infra/servers/:id/deploy served its files without a Cache-Control header. The browser picked the cache lifetime itself from the file date in the archive and could keep showing the previous version after a new deploy.

After

Every file of such an app is served with the Cache-Control: no-cache header: the browser keeps a copy but checks it against the server before showing it. The file date becomes the deploy time, so Last-Modified and ETag change with every deploy that changes the app files.

Impact on integrators

No request changes are needed. The header appears after the next deploy of the app.

FIX-1113-6: Smart process field option order in PATCH

Before

PATCH /v1/items/{entityTypeId}/userfields/{id} and PATCH /v1/userfields/invoices/{id} with an enum array returned HTTP 200, but a changed option sort was not saved. A subsequent GET showed the old value.

After

This fixes a case where PATCH with enum returned HTTP 200 while a subsequent GET showed the existing option's old sort. The response remains HTTP 200 with { "success": true, "data": { "updated": true } } for a valid array. Check the new order with a subsequent GET: on some Bitrix24 accounts, HTTP 200 may still accompany the old sort. A userTypeId passed in the body is still ignored. A malformed option array now returns HTTP 400 INVALID_ENUM without updating the field. HTTP 502 BITRIX_ERROR means the API could not verify that the supplied existing option id values belong to this field before updating; the field is not changed.

Impact on integrators

Valid requests need no changes. Check the option order with a subsequent GET after PATCH: HTTP 200 alone does not confirm that the new sort was saved.

FIX-1113-7: More time to create an application database snapshot

Before

The local SQLite database snapshot was allocated 5 seconds. Once that limit was reached, the snapshot was interrupted with APP_DB_BACKUP_TIMEOUT. This limit applied to manual, daily and protective backups.

After

Snapshot creation is allocated 45 seconds. If the snapshot does not finish within that time, the backup still receives APP_DB_BACKUP_TIMEOUT. Successful backup creation is not guaranteed for every database size.

Impact on integrators

The backup creation request still returns HTTP 202, and the backup is created in the background. No request changes are needed. Backups that previously ended with status FAILED require a new creation attempt.

Database writes may wait longer for a protective backup to become ready. While the backup is being prepared, a write call returns 409 APP_DB_BACKUP_NOT_READY with the Retry-After header. Repeat the call after the specified pause. A single HTTP request is not held for the entire preparation time. Creating the backup can take up to several minutes: 45 seconds is the limit for the local snapshot alone, not the entire backup preparation.

Protective backups before an application database restore or application deletion use the same snapshot limit, so preparing these operations may take longer.

Affected endpoints: POST /v1/infra/servers/:id/db/backups, POST /v1/infra/servers/:id/db/execute, POST /v1/infra/servers/:id/db/tables/:table/rows, PATCH /v1/infra/servers/:id/db/tables/:table/rows/:key, DELETE /v1/infra/servers/:id/db/tables/:table/rows/:key, POST /v1/infra/servers/:id/db/restore, DELETE /v1/infra/servers/:id

NEW-1113-9: Cowork: `opened` flag on personal limit windows

On a Bitrix24 account with personal AI limits enabled, every limit window now carries an opened flag: windows.<window>.opened in GET /v1/cowork/state and in the POST /v1/cowork/subscription/resume response, an opened: { fiveHour, week, month } map next to quotaPct in GET /v1/cowork/me, and windows.<window>.opened in the partner /api/b24/*. false means the window will start with the first request. resetAt stays for compatibility. Accounts without personal limits do not get the field.

NEW-1113-10: the pull_channel scope is available on every account

The pull_channel scope is no longer limited to accounts with Pull channel support enabled (NEW-1001-33): it can be selected when creating a key or application on any account. Keys that already carry the scope keep working as before.

NEW-1113-11: Generate a site from a description

Added site generation, status checks, field definitions and reading one field. The start accepts a client Idempotency-Key; repeating a completed request with the same key returns its saved response for 24 hours. A generation takes the user's available AI site draft. Checking its status requires write access and is not retried automatically after a 5xx response. An empty or whitespace-only Idempotency-Key is treated as absent.

Affected endpoints: POST /v1/sites/ai/generate, GET /v1/sites/ai/status, GET /v1/sites/ai/fields, GET /v1/sites/ai/fields/{name}

NEW-1113-12: newcomer first steps in Cowork are stored per account

GET /v1/cowork/me returns an onboarding block with the moments of the first sent request (firstPromptAt) and the first complete answer (firstAnswerAt). The marks are shared by all the user's devices on the account, so the newcomer hints are not shown again on another computer. If the seat already has Cowork usage, both moments arrive filled even without a mark, and the inferred flag is true.

BC-1113-13: the company quota is no longer returned to a Cowork subscription key

Old format supported until: not provided

Before

GET /v1/ai/quota answered a Cowork subscription key with the vibe:cowork scope the same way as any other key of the account: with the company AI quota percentages and the exhausted flag. Calls made with such a key do not consume that quota, so the response did not describe the key's limits, and exhausted: true looked like an exhausted subscription.

After

A key with the vibe:cowork scope receives 403 company_ai_quota_not_applicable. Other keys receive the same response as before.

What integrators should do

Read Cowork subscription limits from GET /v1/cowork/me: the quotaPct and resetAt fields for the five-hour, week and month windows. Request the company quota with a key that does not have the vibe:cowork scope.