# API changes: November 13, 2026 [← Changelog](/docs/changelog) · [November 2026](/docs/changelog/2026-11) ### 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](/docs/userfields/smart-processes/create) 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}](/docs/userfields/crm/update) 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}](/docs/userfields/crm/get) 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](/docs/disk/uploads-get) 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](/docs/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](/docs/disk/uploads-reserve), [POST /v1/disk/uploads](/docs/disk/uploads), [GET /v1/disk/uploads/:operationId](/docs/disk/uploads-get), and [GET /v1/disk/uploads](/docs/disk/uploads-list) 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](/docs/ai/consumption/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](/docs/infra/deploy/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}](/docs/userfields/smart-processes/update) 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](/docs/infra/database/snapshot), [POST /v1/infra/servers/:id/db/execute](/docs/infra/database/execute), [POST /v1/infra/servers/:id/db/tables/:table/rows](/docs/infra/database/rows-create), [PATCH /v1/infra/servers/:id/db/tables/:table/rows/:key](/docs/infra/database/rows-update), [DELETE /v1/infra/servers/:id/db/tables/:table/rows/:key](/docs/infra/database/rows-delete), [POST /v1/infra/servers/:id/db/restore](/docs/infra/database/restore), [DELETE /v1/infra/servers/:id](/docs/infra/servers/delete) ### 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..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..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](/docs/entities/sites/ai/generate), [GET /v1/sites/ai/status](/docs/entities/sites/ai/status), [GET /v1/sites/ai/fields](/docs/entities/sites/ai/fields), [GET /v1/sites/ai/fields/{name}](/docs/entities/sites/ai/field) ### NEW-1113-12: newcomer first steps in Cowork are stored per account [GET /v1/cowork/me](/docs/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](/docs/ai/consumption/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](/docs/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.