# API changes: November 9, 2026

[← Changelog](/docs/changelog) · [November 2026](/docs/changelog/2026-11)

### BC-1109-1: a record deletion is not sent to Bitrix24 again

> Old format supported until: not provided

**Before**

A `DELETE` of an entity record — for example [DELETE /v1/deals/{id}](/docs/entities/deals/delete), [DELETE /v1/contacts/{id}](/docs/entities/contacts/delete), [DELETE /v1/leads/{id}](/docs/entities/leads/delete) or [DELETE /v1/companies/{id}](/docs/entities/companies/delete) — was repeated on the Vibecode side when the account was temporarily unavailable (a `503` with no error code) or answered with a redirect, and one deletion reached the account more than once. A repeat after a deletion that had already happened was refused by the account because the `id` no longer existed, so the client got a refusal for a deletion that had gone through.

**After**

The deletion is sent to Bitrix24 again only after a refusal the account gives before running the method — the request rate limit `QUERY_LIMIT_EXCEEDED`. Temporary unavailability and a redirect both answer `502 BITRIX_UNAVAILABLE`, with no repeat. A successful deletion still answers HTTP 204.

**What integrators should do**

After a `429` on `DELETE`, wait the number of seconds given in `Retry-After` and repeat the request: the deletion was not applied. After a `502` or `503`, read the record first: the deletion may have been applied, and a repeated `DELETE` for it answers with a "not found" refusal.

### BC-1109-2: Application grants for connector reads

> Old format supported until: not provided

**Before**

Connector calls from applications were allowed by the key scope and the owner's audience. Writes required approval.

**After**

Applications read data through `/v1/connectors/mcp` only with a current administrator grant for the company connection. The key owner audience does not replace a grant. Application writes are no longer supported and do not create approval tickets. [GET /v1/connectors](/docs/connectors-host/list) returns `appState` for every connector; [GET /v1/me](/docs/keys-auth/me) reports `readOnly` and refusal codes.

Refusals have HTTP representation 403: `CONNECTOR_APP_NOT_GRANTED`, `CONNECTOR_APP_GRANT_PENDING`, `CONNECTOR_APP_EXPOSURE_WIDENED`, `CONNECTOR_APP_WRITE_NOT_ALLOWED`, `CONNECTOR_APP_NOT_CONNECTED`. MCP returns the code in `_meta["vibe/error"].code`. Widening link access or enabling the external application API suspends the grant until new approval. Cowork access is preserved.

**What integrators should do**

Submit a connector request for the application: an administrator grants read access to the company connection. Remove write tool calls from the application.

### NEW-1109-3: Application connectors and access requests

An application manager can list company connectors using `GET /v1/applications/:id/connectors`: access status, read-only tools and the application's current exposure. `POST /v1/applications/:id/connectors/:slug/access-request` submits a request to a Bitrix24 account administrator. Repeating a request while a decision is pending or access is active preserves its status.

### NEW-1109-4: Chat file list

`GET /v1/chats/{chatId}/files` returns one page of chat files — the Media, Files and Voice tabs of the chat side panel. The required `group` takes one or more of `MEDIA`, `FILE`, `AUDIO`, separated by commas. Optional: `limit` (1–200), the cursor `lastId` and, together with it, `lastDate`, `order=date` only with `group=AUDIO`, `search` — the start of a file name. `data` holds `list`, `files`, `users` and `tariffRestrictions`. Requires the `im` scope; a read-only key may call the route too. A file link that carries credentials is replaced with `null` in the answer.