API changes: November 6, 2026

← Changelog · November 2026

BC-1106-1: CRM forms preserve the Bitrix24 schema and rules

Old format supported until: not provided

Before

The form list returned only active forms and a reduced field set by default. Form reads rebuilt fields and consents, added the title, result and agreementsSettings properties and added field options. Form contract fields did not list the analytics, integrations and spamProtection descriptors, and reading one contract field by those names answered 400 INVALID_PARAMS. The isCallback filter selected records after fetching a page. A failed additional read after a write appeared as a failed write. Website widgets and Open Channels answered UNKNOWN_FILTER_FIELD for an unknown query parameter, returned a reduced property set per item, applied a page size of 50 with offset 0 and always returned meta with limit and offset. Embedding codes were rebuilt into a separate shape.

After

The list includes active and inactive forms and returns 11 scalar properties by default. select supports sections and nested paths, with filtering by id and sorting. In GET /v1/crm-forms, query parameters other than controls become Bitrix24 filter conditions: an unknown name no longer causes a local refusal, and Bitrix24 decides whether it is valid. GET /v1/crm-forms/{id} accepts an optional select. The form, website widget and Open Channel lists no longer impose defaults of limit=50, offset=0 or a limit range of 1–1000: Bitrix24 validates the values. Without limit and offset, no pagination is sent. Pagination fields meta.limit, meta.offset and meta.total are no longer guaranteed: they come only from Bitrix24 pagination, and the meta object may be absent. Forms retain the Bitrix24 schema, with no rebuilding of fields and consents and no added properties. Form contract fields list every property, including analytics, integrations and spamProtection, reading one contract field by those names returns its descriptor, and both paths accept an optional select. Additional field-option lookup and post-fetch isCallback filtering have been removed. Ordinary content is preserved, while exact credentials of the current connection are replaced with paths listed in meta.redacted.

Create and update accept a flat body or a fields object. PATCH /v1/crm-forms/{id} no longer enforces its own writable and read-only property lists: Bitrix24 validates active and other supplied properties. A successful write followed by a failed read retains its success status and data.id, adding meta.warnings. CRM_FORM_PARTIALLY_CREATED remains an error with error.id, b24Code and field errors. Bitrix24 errors include b24Code, and insufficient token scope has a distinct BITRIX_INSUFFICIENT_SCOPE code. Only an unavailable method becomes 409 CRM_FORM_REST_NOT_ENABLED. Local request-shape refusals in the described crm.form.* methods answer with an INVALID_PARAMS code: the UNKNOWN_FILTER_FIELD, UNKNOWN_FIELD, READONLY_FIELD, INVALID_FILTER_OPERATOR and INVALID_FILTER_SHAPE codes are no longer returned there, and a missing updatedTime on a form or embedding update gives INVALID_PARAMS instead of MISSING_REQUIRED_FIELDS. The MISSING_REQUIRED_FIELDS refusal for a missing entityName and the POST /v1/crm-forms/{id}/results contract remain unchanged. Embedding supports link and code: null, and deletion accepts confirmed as an alias for confirm. On the website widget and Open Channel paths an unknown query parameter gives INVALID_PARAMS instead of UNKNOWN_FILTER_FIELD, items keep the Bitrix24 schema, order and sort are accepted, and without limit and offset no pagination is sent and meta carries only what Bitrix24 returned. Embedding codes keep the Bitrix24 schema as well. In GET /v1/crm-forms/{id}/embedding, the values of variant and delay are no longer validated locally, and delay is passed as a query string value. PATCH /v1/crm-forms/{id}/embedding no longer uses a local allowlist of body settings: Bitrix24 decides which properties are allowed. A local refusal for these inputs is no longer guaranteed; Bitrix24 may accept them or return its own refusal. Request-shape checks remain. In PATCH /v1/crm-forms/{id} and PATCH /v1/crm-forms/{id}/embedding, updatedTime is still required, but its type is no longer validated locally. For these two paths, as well as POST /v1/crm-forms/{id}/activate, POST /v1/crm-forms/{id}/deactivate and DELETE /v1/crm-forms/{id} with optional updatedTime, Bitrix24 accepts or rejects a non-string value instead of a guaranteed local 400 INVALID_PARAMS. In POST /v1/crm-forms, an absent body no longer causes a local refusal: Bitrix24 receives an empty fields object and validates it.

What integrators should do

Pass active=true to retain the previous active-only selection. Use native form sections instead of the added title, result, agreementsSettings and synthetic field properties. Request target entities and responsible users through select=crm.entityScheme,responsible.userIds, and use the entity-field dictionary for CRM field options. After a readback warning, perform a GET before another change. Replace branching on UNKNOWN_FILTER_FIELD, UNKNOWN_FIELD, READONLY_FIELD, INVALID_FILTER_OPERATOR, INVALID_FILTER_SHAPE on the described crm.form.* paths with an INVALID_PARAMS branch; handle a missing updatedTime on form and embedding updates the same way. Keep supplying updatedTime when updating a form or embedding, and for a non-string value handle the Bitrix24 response instead of relying on the previous local 400 INVALID_PARAMS. For activation, deactivation, deletion and creation without a body, also handle the Bitrix24 response instead of relying on the previous local refusal. Read the details from error.message, error.b24Code and error.validation. An unknown query parameter in the form list no longer causes a local UNKNOWN_FILTER_FIELD: it becomes a filter condition that Bitrix24 accepts or rejects. Do not rely on a guaranteed local refusal. For the form list, also send limit and offset explicitly to retain the previous 50-item page, and check for meta and its fields before reading them. For embedding, handle the Bitrix24 response and error.b24Code instead of relying on the previous local refusal for variant, delay values or the set of settings. For CRM_FORM_PARTIALLY_CREATED, read the form at error.id, correct or delete it, and do not repeat creation. Do not save a redacted configuration back without restoring the changed values. On the website widget and Open Channel paths, replace the UNKNOWN_FILTER_FIELD branch with an INVALID_PARAMS branch as well, send limit and offset explicitly to keep the previous page size, and read item and embedding-code properties from the Bitrix24 response.

NEW-1106-2: Thread settings and chat features

PATCH /v1/chats/{chatId}?format=v2 accepts threadsEnabled as a boolean and manageThreadCreate, manageThreadPost as MEMBER, MANAGER, or OWNER. GET /v1/chats/configuration returns known chat settings features; an omitted feature means its value is unknown.

FIX-1106-4: creating an app: a Bitrix24 refusal with an unread plan now returns a clear code

Before

POST /v1/apps answered 502 CONNECTOR_REST_UNAVAILABLE when Bitrix24 refused to issue the key and the account plan could not be read.

After

The same case returns 403 PORTAL_TARIFF_UNREADABLE, and error.details.remedy says how to repeat the check. When the plan and access are confirmed, the response stays 502 CONNECTOR_REST_UNAVAILABLE.

NEW-1106-5: a durable command refused because of the server clock now carries its own code

POST /v1/infra/servers/{id}/exec in durable mode (async=true) now answers HTTP 502 with the code EXEC_JOB_START_WINDOW when the server refuses the launch because of its own clock: the clock runs more than a minute ahead of the platform clock or more than thirty seconds behind it. The refusal arrives before the command starts, so once the time on the server is checked the same command may be sent again. Previously this case arrived with the generic EXEC_JOB_INVALID code, which did not separate a clock disagreement from the other refusals. The new code is also visible in the operation outcome at GET /v1/infra/operations/{operationId}. Every other refusal keeps its previous code.

FIX-1106-6: a deploy no longer fails because the server clock disagrees

Before

Within an hour of a server being created or woken, the runtime step of POST /v1/infra/servers/{id}/deploy was sent to the server as a deferred task with a bounded launch window. If the server clock ran more than a minute ahead of the platform clock or more than thirty seconds behind it, the task was refused, and the deploy ended with an error at that step even though the request and the application code were correct.

After

That refusal is now told apart from the other server refusals, and the runtime step runs directly, without the deferred task. The deploy goes through whether the server clock runs ahead or behind. The request fields and the response format are unchanged.

Impact on integrators

No action is required. A runtime step refusal for any other reason still arrives with its previous code.

FIX-1106-7: `categoryId` is now required by the CRM required-fields contract for every type except leads and quotes

Before

The PUT schema in GET /v1/openapi.json declared categoryId optional for every type, and the response example substituted 0 even for leads and quotes. An integrator who built a request from the schema could omit categoryId for a deal and get a refusal from Bitrix24.

After

PUT /v1/deals/fields/required, together with PUT /v1/{contacts,companies,invoices}/fields/required and PUT /v1/items/{entityTypeId}/fields/required, lists categoryId among the required fields. Leads and quotes carry no such field in the schema at all: these types do not accept it. The response example shows categoryId: null when the setting is global. The method behaviour is unchanged: Bitrix24 still checks the rules.

Impact on integrators

No action is required: requests that worked keep working. Check your own validation if it treated categoryId as optional for deals, contacts, companies, invoices and smart processes.

NEW-1106-8: aggregation warns about mixed currencies

POST /v1/deals/aggregate now adds an AGGREGATE_MIXED_CURRENCIES entry to data.meta.warnings when sum, avg, min or max reads a field stored in the record's own currency (deals.amount, deals.taxValue, leads.opportunity, leads.amount, quotes.amount, invoices.opportunity, companies.revenue), the records read span more than one currency, and groupBy names no currency field. The values are not converted, so such a number adds different currencies. The warning appears independently of truncation and may come together with AGGREGATE_TRUNCATED. The deprecated GET /v1/{entity}/aggregate warns the same way. The Bitrix24 accounting-currency fields (deals.receivedAmount, deals.lostAmount) never raise it.