# API changes: November 5, 2026 [← Changelog](/docs/changelog) · [November 2026](/docs/changelog/2026-11) ### FIX-1105-1: Scrum Definition of Done and sprint metric routes call Bitrix24 again **Before** `GET /v1/scrum/groups/{groupId}/dod/settings`, `GET /v1/scrum/groups/{groupId}/tasks/{taskId}/dod/necessary`, `GET /v1/scrum/groups/{groupId}/burn-down`, `GET /v1/scrum/groups/{groupId}/team-speed`, `POST /v1/scrum/groups/{groupId}/dod/types/{typeId}/settings` and `POST /v1/scrum/tasks/{taskId}/dod/{typeId}` answered `422 BITRIX_ERROR` with `b24Code: ERROR_EMPTY_ENTITY_ID`, although Bitrix24 answered the same parameters successfully. **After** The routes return the actual Bitrix24 response: [Definition of Done in Scrum](/docs/scrum/dod), [Sprint metrics](/docs/scrum/metrics). **Impact for integrators** No action is required: the paths, parameters and response shape are unchanged. ### FIX-1105-2: calendar event time zones are available in input field descriptions **Before** The `timezoneFrom` and `timezoneTo` fields were accepted when creating and updating calendar events but were missing from MCP discover input schemas. **After** MCP discover publishes both fields in the create and update input schemas for `/v1/calendar-events`. They are write-only; the time zone offset in responses is still included in `from` and `to`. ### BC-1105-3: a record update is not sent to Bitrix24 again, and a failed re-read is not reported as a refusal > Old format supported until: not provided **Before** A `PATCH` of an entity record — for example [PATCH /v1/deals/{id}](/docs/entities/deals/update), [PATCH /v1/contacts/{id}](/docs/entities/contacts/update), [PATCH /v1/leads/{id}](/docs/entities/leads/update) or [PATCH /v1/companies/{id}](/docs/entities/companies/update) — was repeated on the Vibecode side when the account was temporarily unavailable (a `503` with no error code) or answered with a redirect, and the same write could reach the account more than once: for a phone, email or website it added the row again. When the update was accepted but reading the record back failed, the response was an error — for example `429 RATE_LIMITED` — although the record had already changed. **After** The write is sent to Bitrix24 again only after a refusal the account gives before running the method — the request rate limit `QUERY_LIMIT_EXCEEDED`, as before. Temporary unavailability and a redirect both answer `502 BITRIX_UNAVAILABLE`, with no repeat. When the update is accepted but reading the record back fails, the response is `200`: `data` holds only `id`, and `meta.warnings` carries the `REREAD_FAILED` warning. **What integrators should do** After a `429` on `PATCH`, wait the number of seconds given in `Retry-After` and repeat the request: the write was not applied. After a `502` or `503`, read the record first: the change may have been applied. On `REREAD_FAILED`, read the record too instead of repeating the `PATCH`. ### BC-1105-4: Application deletion waits for a protective database backup > Old format supported until: not provided **Before** [DELETE /v1/infra/servers/{id}](/docs/infra/servers/delete) for a `GALAXY_APP` application could return HTTP 200 and delete the application without a protective database backup when backup preparation failed. **After** If backup preparation fails with `APP_DB_TOOL_UNAVAILABLE`, the request returns HTTP 503. The application remains available for another deletion attempt. The previous deletion without a backup on this failure ends immediately because it could cause data loss. **What integrators should do** Treat HTTP 503 as a deletion refusal. Check the application's database readiness, resolve the failure, and retry DELETE with the same `id`. Do not consider the application deleted until the request succeeds. ### NEW-1105-5: CRM aggregates can group by currency [POST /v1/deals/aggregate](/docs/entities/deals/aggregate), [POST /v1/leads/aggregate](/docs/entities/leads/aggregate), [POST /v1/quotes/aggregate](/docs/entities/quotes/aggregate), [POST /v1/invoices/aggregate](/docs/entities/invoices/aggregate) and [POST /v1/companies/aggregate](/docs/entities/companies/aggregate) accept the currency field in `groupBy`: `currency` for deals and quotes, `currencyId` for leads, invoices and companies. This is the name the list response uses for the currency. The response carries a separate group with its own `count` and sums for each currency. Previously such a `groupBy` was rejected with `400 INVALID_PARAMS`, and with records in several currencies `sum` over the record amount added them into one number without conversion. The legacy `GET /v1/{entity}/aggregate` accepts the currency field in `groupBy` the same way. Also fixed: `sum`, `avg`, `min` and `max` over `amount` in `POST /v1/quotes/aggregate` returned `0` instead of the value computed from quote amounts. ### NEW-1105-6: changing and deleting a single phone, email or website row on leads and companies [PATCH /v1/leads/{id}](/docs/entities/leads/update) and [PATCH /v1/companies/{id}](/docs/entities/companies/update) accept `fm` as an object. A key is a row `id` from `fm` in the `GET` response: a non-empty `value` changes the row, an empty `value` deletes it. Keys `n0`, `n1`, … add rows. A row accepts only `typeId`, `valueType` and `value`; `typeId` is `PHONE` or `EMAIL`, and also `WEB` for companies; `valueType` is required when a row changes. Before writing, Vibecode reads the record: an `id` this record does not have with the same `typeId` gets `409 MULTIFIELD_ROW_NOT_FOUND`, a record that could not be read gets `MULTIFIELD_PRECHECK_FAILED` (`404`, `429` with `Retry-After`, or `502`); in both cases nothing is written. After writing, the record is read again and compared with the request: if the change is not visible, the answer is `422 MULTIFIELD_NOT_APPLIED` with the re-read record in `data`; if it is visible but a row the request did not name is gone or changed, the answer is `200` with the `MULTIFIELD_OTHER_ROWS_CHANGED` warning; if the comparison is not possible, the answer is `200` with the `MULTIFIELD_UNVERIFIED` warning. `fm` as an array, `phone`, `email` and `web` still only add rows; contacts, batch calls, import and create accept `fm` only as an array, as before. ### BC-1105-7: companies no longer have the sourceId and sourceDescription fields > Old format supported until: not provided **Before** The company field schema ([GET /v1/companies/fields](/docs/entities/companies/fields)) declared `sourceId` and `sourceDescription`, although a Bitrix24 company has no such fields. A value in [PATCH /v1/companies/{id}](/docs/entities/companies/update) and [POST /v1/companies](/docs/entities/companies/create) answered with success and was not stored, `sourceId` was listed among the aggregation `groupBy` fields, and `select` and `filter` on them were accepted. **After** The fields are not published in the schema and are not accepted for grouping. A write with them still answers with success and adds the `UNRECOGNIZED_WRITE_FIELD` warning to `meta.warnings`. An explicit `select` on them gets `400 UNKNOWN_SELECT_FIELD`, `filter` gets `400 UNKNOWN_FILTER_FIELD`, grouping gets `400 INVALID_AGGREGATION_FIELD`. **What integrators should do** Remove `sourceId` and `sourceDescription` from requests to companies: they were never written or returned. Leads, contacts and deals do have a source. ### FIX-1105-8: blueprint text follows the Bitrix24 default design **Before** [GET /v1/app/blueprints/:slug](/docs/app-blueprints) always included a paragraph in the blueprint text telling the reader to fetch `/v1/me` and take the design from `data.uiDesign`. **After** The paragraph is present when the Bitrix24 default design is enabled for the Bitrix24 account. While that feature is off, the blueprint text is served without the paragraph. The other sections of the blueprint are unchanged. **Impact on integrators** No changes are required. The agent receives the same blueprint text, only the design paragraph differs. ### FIX-1105-9: files with keys longer than 100 characters are readable and deletable by key **Before** [GET /v1/storage/objects/{key}](/docs/storage/objects/get), [HEAD /v1/storage/objects/{key}](/docs/storage/objects/head) and [DELETE /v1/storage/objects/{key}](/docs/storage/objects/delete) answered `404 ROUTE_NOT_FOUND` for a key longer than 100 characters, although the upload accepted such a key and the [object list](/docs/storage/objects/list) showed it. **After** These methods accept any key the upload accepts. GET redirects to the file, HEAD returns its metadata, DELETE deletes the file. **Impact on integrators** No changes needed. Files with long keys that are already in storage are available at the same address.