API changes: October 3, 2026

← Changelog · October 2026

BC-1003-1: addresses and bookings no longer lose a filter condition in silence

Old format supported until: not provided

Before

GET /v1/addresses and GET /v1/bookings accepted a filter that could not be applied and answered 200. On addresses, a request like ?filter[city]=Berlin&filter= returned the entire address book of the Bitrix24 account: during query-string parsing one spelling destroys the other, the condition disappeared, and the answer looked filtered. The spelling ?filter={"city":"Berlin"}&filter= lost the condition the same way without a single bracket. On bookings, any envelope key other than dateFrom and dateTo never reached Bitrix24 and the answer covered the whole interval, while a destroyed envelope answered MISSING_REQUIRED_PARAMS — "pass dateFrom and dateTo" to a caller who had passed exactly those. POST /v1/bookings/search lost a condition the same way: a body of {"filter":{"status":"CONFIRMED"}} went to Bitrix24 without that key and the answer covered the whole interval.

After

Both routes inspect the filter envelope before calling Bitrix24. If at least one spelled condition did not arrive — both forms mixed, one name spelled at two different nesting levels (?filter[a]=1&filter[a][b]=2), nesting deeper than two levels — the answer is 400 INVALID_FILTER, and the message names which case it is. On bookings, a key other than dateFrom and dateTo, as well as a filter that arrived as a string, a JSON object or an array, answers 400 UNSUPPORTED_FILTER listing the accepted keys. POST /v1/bookings/search refuses the same way: the body is read only through filter.within with the keys dateFrom and dateTo, and any other key is 400 UNSUPPORTED_FILTER before Bitrix24 is called.

What integrators should do

Pass the whole filter in one form — either bracket notation ?filter[field]=value throughout, or a single JSON object ?filter={…} carrying every condition. On GET /v1/bookings, narrow only by dateFrom and dateTo (flat parameters or the filter[dateFrom] / filter[dateTo] keys); on POST /v1/bookings/search, use the top-level pair or filter.within. Select the rest on your side. An empty ?filter= still means "no filter" and such requests need no change. A request that used to get 200 with extra records now gets 400, and that is the fix: the old answer carried data you had not asked for.

FIX-1003-2: CRM forms no longer hide ordinary form text

Before

GET /v1/crm-forms and GET /v1/crm-forms/:id sometimes replaced ordinary form text with [redacted]. A word ending in "key" was treated as a credential name: the label Monkey: Banana came back as [redacted]. An encoded address such as %2Frest%2F1%2Fhelp was treated as an inbound webhook address and was hidden as well.

After

Ordinary form text is returned as is. Credentials in the text are still hidden: pairs such as apiKey: …, api_key=…, x-api-key: …, token=… and inbound webhook addresses, including encoded ones. The response remains HTTP 200, and the response fields are unchanged.

Impact on integrators

No action is required. Form names, field labels and result texts contain fewer false [redacted] values.

FIX-1003-3: deleting a blocked key confirms revocation of its tokens

Before

DELETE /v1/keys/:id could confirm deletion of a blocked key before access tokens issued by that key stopped being accepted.

After

Successful deletion of a blocked key confirms that all related live access tokens have already been revoked. If revocation cannot be completed temporarily, the key remains available for another deletion attempt.

Impact on integrators

The request does not need to change. Retry deletion after a transient failure.

FIX-1003-4: a deleted authorization app no longer describes the application card

Before

When an application's authorization key was deleted before fix FIX-0922-6, the link to the deleted authorization app stayed in place until a new key was issued, and the card kept describing the deleted app:

• GET /v1/applications and GET /v1/applications/{id} returned isEmbedded: true when the deleted app had placements, and the key block showed the mask of its key when that key was blocked (status: BLOCKED);
• POST /v1/cowork/applications/{id}/key returned APPLICATION_HAS_AUTH_KEY in warningCodes, and the key block of the returned card showed the same mask.

After

A link to a deleted authorization app reads as "no authorization key" on all of these endpoints: isEmbedded is false, the key block shows the personal key (slot: "api") or an empty slot, and APPLICATION_HAS_AUTH_KEY no longer appears in warningCodes. Successful responses are preserved: the HTTP 200 response of both GET endpoints and the HTTP 201 response of key issuance are unchanged. A live authorization app is described as before, including its blocked key.

BC-1003-5: static deploy uses the platform web server

Old format supported until: not provided

Before

For runtime: "static", the start field was required and the supplied command controlled the application process.

After

For runtime: "static", the start field is optional and ignored. The platform serves the ready static build from extractTo on the selected port and supports SPA routes through index.html.

What integrators should do

Remove start from static deploys and make sure the archive contains the ready build directly in extractTo. If the application needs a custom start command, select a suitable non-static runtime; for a manually managed existing unit on a dedicated virtual machine, use systemd: false.