API changes: September 25, 2026

← Changelog · September 2026

BC-0925-1: an unreadable field id is refused before a smart-process field is changed or deleted

Old format supported until: not provided

Before

PATCH /v1/items/{entityTypeId}/userfields/{id} and DELETE /v1/items/{entityTypeId}/userfields/{id} accepted any string in :id. A value starting with digits was silently cut at the first foreign character: an :id of 7abc changed or irreversibly deleted the field numbered 7 — a different one than requested — and the response was a success ({"updated": true} and 204). A value with no digits reached the Bitrix24 account empty, and the request ended with a Bitrix24 error about a missing required parameter.

After

:id must be a positive integer in plain notation: digits only, with no leading zero, sign, fractional part, exponent or spaces, and no greater than 9007199254740991. Otherwise the Vibecode platform answers 400 INVALID_PARAMS and names the parameter in the message text. No call to the Bitrix24 account is made on such a refusal, and the field is neither changed nor deleted.

What integrators should do

If the field id is taken from the smart process field list and passed through as is, nothing changes — such calls work as before.

Three classes of values are now refused, and they differ in what used to happen:

• a FOREIGN field used to be changed or deleted under a success code — a string with digits first and a foreign tail (7abc read as 7), an exponent (7e2 read as 7, not 700), and an id greater than 9007199254740991 (which shifted to a neighbouring one when converted). These calls changed something other than what you asked for and said nothing about it;
• the operation used to hit the RIGHT field under a success code — an id written in a non-plain form: a leading zero (007), a sign (+7), a fraction (7.0), surrounding spaces. Such calls worked correctly and now get a 400. This is the only class the change breaks for an integration that worked correctly — drop the extra characters and leave the digits only;
• an account error used to come back — a value with no digits, including a system field name such as UF_CRM_…. The Vibecode platform now answers 400 itself, before calling the account.

In all three cases, pass the numeric field id from the field list exactly in the form it comes in there.

Affected endpoints: PATCH /v1/items/{entityTypeId}/userfields/{id}, DELETE /v1/items/{entityTypeId}/userfields/{id} and their short addresses for smart invoices, /v1/userfields/invoices/{id}.

FIX-0925-3: sign-in from Cowork now opens Galaxy apps too

Before

POST /v1/cowork/app-login issued a sign-in only for an app on a dedicated server. For the address of a Galaxy app it answered 404 APP_NOT_AVAILABLE, even when the access policy admitted the key owner.

After

A Galaxy app goes through the same access check as an app on a dedicated server and, once admitted, gets an HTTP 200 response with the sign-in address. A Galaxy host machine still answers 404 APP_NOT_AVAILABLE, since it is not an app.

FIX-0925-4: a server whose creation failed on the cloud side no longer hangs in `PROVISIONING`

Before

When the cloud refused after creation had already started and the request carried an Idempotency-Key header, the server stayed in PROVISIONING with no cloud machine id. A retry with the same key returned the same record, and it looked like "still being created" forever: GET /v1/infra/servers/:id returned status: "PROVISIONING" even though creation had already failed.

After

Such a server is given status: "ERROR" right away. The creation response itself is unchanged — it is still 502 PROVIDER_ERROR with the same text, and a retry with the same Idempotency-Key still returns the same record instead of creating a second machine. Only the status in the record changed: it now names the outcome honestly, and such a server shows up among the failed ones rather than among those still being created.

FIX-0925-5: the sleeping-app log read no longer names a wake address that is banned on the host

Before

GET /v1/infra/servers/{id}/logs on a sleeping Galaxy app returned recovery.recoveryAction with the wake address whenever no door refused the caller by their key. A wake ban on the galaxy host itself (a subscription or plan wall, a host block) was not part of that signal at all, so a fully privileged owner got the machine-readable address, called it and received 402 or 403 SERVER_WAKE_BLOCKED. The same signal also emitted recovery.deliveryWakesHost — the paid second way up, which does not work on a blocked host either.

After

When waking is banned on the host, the answer names the wake address in no field — neither recovery.recoveryAction nor the hint text — and it does not name recovery.deliveryWakesHost. Instead of an address, hint names the condition: the ban sits on the shared host, the account owner lifts it, and changing the key does not help. The log-read response itself remains HTTP 200 with an empty list of lines, as before. The recovery.wakeSchedule field does not change in that state: creating a recurring window stays available, and the prose warns separately that a window will not bring the host up.

Influence on integrators

Nothing to change if you already branch on the PRESENCE of recovery.recoveryAction, as the documentation requires. A client that used the wake address unconditionally will stop receiving a guaranteed refusal from it.

FIX-0925-6: a cursor with a corrupted date in revenue exports is rejected with INVALID_CURSOR instead of a 500 error

Before

A cursor with a corrupted date — for example, one assembled or edited by hand — broke the request: instead of rejecting the cursor, the export answered HTTP 500. This affected GET /v1/platform/revenue/topups, GET /v1/platform/revenue/charges, GET /v1/platform/revenue/expirations, GET /v1/platform/revenue/refunds, GET /v1/platform/revenue/consumption/by-service, GET /v1/platform/revenue/consumption/reconstructed and GET /v1/platform/revenue/money-in/payments.

After

Such a cursor is rejected with 400 INVALID_CURSOR, just like a cursor issued for a different window. A cursor taken from the nextCursor field of the previous page works as before, and the traversal order and page contents are unchanged.

Impact on integrators

No changes are needed. A client that retried the request after an HTTP 500 response now gets 400 INVALID_CURSOR right away: retrying with the same cursor will not help, so restart the traversal without cursor.

FIX-0925-7: the charges export includes AI usage over the quota

Before

Vibe charges for AI usage over the Bitrix24 account quota did not appear in GET /v1/platform/revenue/charges and GET /v1/platform/revenue/consumption/by-service: such a charge row carried no per-tranche breakdown, and both exports are built from it. Purchased vibes consumed this way were visible only indirectly, as a lower remaining in GET /v1/platform/revenue/topups.

After

A charge for AI usage over the quota records its per-tranche breakdown like every other charge and appears in both exports: in /charges as a per-tranche movement and in /consumption/by-service with the AI_TOKENS service type. Such a charge is one row per Bitrix24 account per Moscow day: it belongs to the UTC day of its first overage and keeps growing until the end of that Moscow day, so re-request the latest closed UTC day after 21:00 UTC on the following day. External AI overage above quota is now recorded the same way, with its own row for each charge. Charges recorded before this fix carry no breakdown and stay out of the exports. The response format is the same, and the response remains HTTP 200.

FIX-0925-8: bot file upload checks the required fields before calling Bitrix24

Before

POST /v1/bots/:botId/files passed the body to Bitrix24 as is. With dialogId missing, or the file sent under unrecognised field names (fileName and fileContent, for example), the request reached Bitrix24 without its required parameters and came back with code 100 — "required parameter missing" — naming no parameter.

After

The required fields are checked before the Bitrix24 call. Without dialogId, the file name or content, the answer is 400 MISSING_PARAMS. The error text lists the unrecognised body fields and shows the correct request shape.

Impact on integrators

A correct request in any of the three supported body formats works as before. A client that used to get 100 now sees a specific refusal from the Vibecode platform and knows which field is missing.

FIX-0925-9: Editing the scopes of a key whose webhook stayed on the previous Bitrix24 account address answers PORTAL_ADDRESS_CHANGED

Before

PATCH /v1/keys/:id with a new scopes list for a key whose webhook was still issued for the previous address after the Bitrix24 account address changed answered one of the scope sync refusals — 410 STALE_DEVELOPER_KEY, 502 RECOVERY_FAILED or 502 DEVKEY_SCOPE_SYNC_FAILED. None of them named the actual cause: retrying did not help, and the advice to reconnect the account did not fix this case. Every call of such a key to the Bitrix24 account already answered 409 PORTAL_ADDRESS_CHANGED.

After

Editing the scopes of such a key answers the same 409 PORTAL_ADDRESS_CHANGED and does not contact the Bitrix24 account. The key's scopes change neither on the platform nor in Bitrix24. The other scope edit responses are unchanged.

Impact on integrators

Handle 409 PORTAL_ADDRESS_CHANGED the same way as on the key's other calls: reconnect the key — its webhook is re-issued for the current address — then repeat the scope edit. The code is described in Authorization, keys and permissions.

FIX-0925-10: the workflow list answers with a clear code on an account without the module

Before

When the business processes module is not included in the account plan or is switched off in its settings, Bitrix24 answers the bizproc.workflow.instances method with a "method not found" message. The GET /v1/workflows request surfaced that as 404 ENTITY_NOT_FOUND — a message about a missing entity, while both the entity and the request itself were fine. The ENTITY_NOT_FOUND code was absent from the page error table, and the cause of the refusal could not be read off the response.

After

The same account state answers 409 BIZPROC_MODULE_NOT_ENABLED. The message names both possible causes and the action: ask an account administrator to enable business processes. The response remains a 4xx client refusal, and the error-loop protection does not count it — it stays informative for any number of retries instead of turning into 429 ERROR_LOOP_DETECTED.

Integrator impact

No action required: the refusal was and remains a 4xx response. An integration that told the disabled module apart by the Bitrix24 message text can switch to the 409 BIZPROC_MODULE_NOT_ENABLED code. The former 404 ENTITY_NOT_FOUND was never promised by the documentation for this state. The other operations of the Workflows section answer as before — the change affects the list of running workflows only.

FIX-0925-11: BitrixGPT 5.5 accepts json_schema when the model supports structured outputs

Before

POST /v1/chat/completions with response_format.type = json_schema and model bitrix/bitrixgpt-5.5 returned 400 model_does_not_support_structured_outputs, while GET /v1/me did not list structured outputs.

After

BitrixGPT 5.5 and Thinking models that support structured outputs appear in GET /v1/me, and json_schema requests pass the capability check. Clients do not need to change their request format.

Impact on integrators

No integration changes are required: continue using response_format.type = json_schema.

FIX-0925-12: storage: reads and deletes by key pick a non-deleted copy of the file

Before

When several copies of a file lay under one key and the earliest of them was deleted, GET /v1/storage/objects/{key}, HEAD /v1/storage/objects/{key} and DELETE /v1/storage/objects/{key} returned 410 STORAGE_OBJECT_DELETED, although the file stayed in the object list. After the first delete under such a key, every further DELETE returned the same, and the remaining copy was not deleted.

After

A request by key picks the earliest non-deleted copy of this file. While such a copy exists, the file is read and deleted by key, and each DELETE deletes one copy. When no non-deleted copies remain, the response is unchanged: 410 STORAGE_OBJECT_DELETED.

Impact on integrators

No changes are needed. For a file with several copies, a repeated DELETE by key deletes the next copy and returns 410 STORAGE_OBJECT_DELETED only when no copies remain.

BC-0925-13: mailbox listing without the Mail module answers with a clear 409

Old format supported until: not provided

Before

When the Mail module is absent from the Bitrix24 account, the method is not included in the plan, or the account has not yet received the update carrying mail.mailbox.list, Bitrix24 answered "method not found", and GET /v1/mail/mailboxes surfaced it as 404 ENTITY_NOT_FOUND. The account state was indistinguishable from a missing record.

After

Only GET /v1/mail/mailboxes answers 409 MAIL_MODULE_NOT_ENABLED. The message names the possible causes — the module is not installed, the method is not included in the plan, or the account has not yet received the update carrying mail.mailbox.list — because there is no way to tell them apart from the outside. Other Bitrix24 refusals on this route are unchanged: a permission refusal stays 403, and a rate limit stays 429 with its own Retry-After.

Impact on integrators

Successful responses are unchanged. If your code branched on 404 for mailbox listing, add a 409 MAIL_MODULE_NOT_ENABLED branch. Do not blindly retry an unchanged 409; retry after the module is enabled, the plan changes, or the account is updated. Neighbouring mailbox routes are not affected.

BC-0925-14: the task chat feed for a read-only key — a page holds at most 50 messages

Old format supported until: not provided

Before

GET /v1/tasks/:taskId/chat/messages could serve any key, a read-only key included, a page of up to 200 messages — as many as passed in limit.

After

For a read-only key a page of the task chat feed holds at most 50 messages for any limit: reading a page of up to 200 messages may make the user a member of the task chat, that is, it changes the data of the Bitrix24 account, and a read-only key does not change that data. For such a key hasNextPage is derived from how full the page is: a full page means the history may go on. The response remains HTTP 200 of the same shape. A key with write access reads the feed as before, up to 200 messages per page.

What integrators should do

If a read-only key requests a limit above 50, page through the history with the lastId cursor until hasNextPage: false and do not expect a page to hold the whole limit. To get up to 200 messages per page, switch the key to write access, as described on the access rights page.

NEW-0925-15: Chats: the format=v2 mode, chat loading, counters and messages around a message

The chats section gained the format=v2 mode on two endpoints and three new endpoints. GET /v1/chats/recent with the format=v2 parameter returns the list of recent dialogs in pages by the lastMessageDate cursor and the hasNextPage flag, and GET /v1/chats/:dialogId/messages with the same parameter reads the feed by the lastId cursor in both directions via order. Without format=v2 both endpoints respond as before. The new endpoints GET /v1/chats/:dialogId/load open a chat in one request — the card, the first page of messages and the pinned ones, GET /v1/chats/counters returns unread counters per chat, and GET /v1/chats/messages/:messageId/context returns a message together with its neighbours. Limits outside the range are clamped with an echo in meta, an unknown or repeated parameter, except format, is refused with 400 INVALID_PARAMS; a repeated format uses its last value. The format[]=v2 form is also accepted when every element is v2. The Bitrix24 refusal code arrives in error.b24Code for 422 and 404 responses. A date that does not exist on the calendar (2026-02-30, 24:00) in the lastMessageDate cursor and in updatedAfter is refused with 400 INVALID_PARAMS instead of being shifted to a neighbouring day. Opening a chat, messages around a message and the v2 feed may make the user a chat member when the chat allows auto-join, so they count as writes: a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them, as described on the access rights page.

FIX-0925-16: a dropped connection to Bitrix24 answers 502 BITRIX_UNAVAILABLE

Before

When the connection to Bitrix24 dropped before an answer arrived (a reset or refused connection, a TLS failure, a break in the middle of the answer), a request for Bitrix24 data got 500 INTERNAL_ERROR, as if the platform itself had failed. POST /v1/batch answered the same way.

After

Such a drop answers 502 BITRIX_UNAVAILABLE, as the error reference describes. error.message names the machine code of the cause when it is known, for example ECONNRESET, and error.hint gives the retry rule: a read is safe to repeat with backoff, and before retrying a write, re-read the record. The platform does not repeat the request itself.

Impact on integrators

No action required. If you retry with backoff on BITRIX_UNAVAILABLE, short network failures now land in that branch instead of INTERNAL_ERROR.

NEW-0925-17: Vibe credits spend per Bitrix24 account: GET /v1/platform/revenue/spend

The Revenue Export API showed consumption of purchased Vibe credits only, for closed UTC days only, and broken down no deeper than the service type: GET /v1/platform/revenue/consumption/by-service returned neither gifted credits, nor the current day, nor the server plan, the Cowork tier or the AI model.

The new GET /v1/platform/revenue/spend method (key scope revenue:spend) returns the actual Vibe credits spend: day × Bitrix24 account × service × price item × credits source, for a window of up to 92 days from 2026-06-30 up to and including the current day, as JSON or CSV. The source (funding) tells apart purchased credits, the starter grant, Bitrix24 bonuses, manual credits, compensations, credits returned by a refund, charges made on credit and charges whose source was not recorded. A page is one UTC day, walked with nextCursor; days from finalBefore on are marked provisional and may still change. Other methods are unchanged.

FIX-0925-18: a wake window on a server in the scheduled run mode can be created and edited through the API

Before

Entry FIX-0916-10 promised that a server in the SCHEDULE run mode is not treated as always-on and that an extra wake window on it is created the usual way. Through the API the promise did not hold: POST /v1/infra/servers/{id}/wake-schedules and PATCH /v1/infra/servers/{id}/wake-schedules/{scheduleId} answered 400 ALWAYS_ON_CONFLICT for such a server on a non-preemptible plan with no sleep timeout — both to the owner's key and to the key of a server team admin.

After

A server in the SCHEDULE run mode gets a wake window through the API the usual way: creating returns 201, editing returns 200, as for any server a window is allowed on. A server in the ALWAYS run mode on a non-preemptible plan still gets the 400 ALWAYS_ON_CONFLICT refusal, except an app in a galaxy: it inherits the galaxy's plan and is not treated as always-on.

Impact on integrators

No action needed.

FIX-0925-19: employee directory uses available keys

GET /v1/infra/servers/:id/b24-users finds employees even when the server key has no access to the directory.

Before

If the server key lacked the user scope, Bitrix24 refused the call and the response was empty: { "success": true, "data": [] } — with no reason given.

After

If the server key is denied by scope, Vibecode tries other keys of the same Bitrix24 account: the server's fallback key, then keys of active Bitrix24 account administrators. If no key has access to the directory, the response remains HTTP 200 with an empty data and includes a hint explaining which scopes to grant. On a network error the response is unchanged: HTTP 200 and { "success": true, "data": [] }.

BC-0925-20: Bitrix24 events and automation rule callbacks arrive without Bitrix24 tokens under a Read-only key

Old format supported until: not provided

Before

A server on the Vibecode platform received Bitrix24 events and business process automation rule callbacks with auth[access_token] and auth[refresh_token] whatever the key modes were.

After

If the server key or the authorization key of the subscribed app is in the Read-only mode, the event and the callback arrive without auth[access_token] and auth[refresh_token], and the gateway does not add the event user headers to them. The same applies to a server whose key is deleted or revoked, and to an app without an active authorization key. An event sent to an app address outside the platform — neither a Black Hole subdomain nor a server's custom domain — arrives without these tokens whatever the key modes. auth[application_token], auth[user_id] and the event data stay. Exchanging the event token for a session through POST /v1/oauth/placement-session is not available to such a handler, and an automation rule waiting for an answer is never completed: answering it is a Bitrix24 write. When the app address points to a platform server, an event raised by a user whom that server's access policy does not admit is not delivered; an event sent to an external address is not filtered by the access policy.

What to do: for reads, call the Vibecode API with your own key — the calls run on behalf of the key owner. To get the tokens and the automation rule answers back, switch both keys — the server key and the app key — to Read and write. If the app address is external, move the handler to a platform server: it receives the tokens when both keys are in Read and write.

BC-0925-21: deploying with a Read-only key does not post the new version announcement

Old format supported until: not provided

Before

POST /v1/infra/servers/:id/deploy with the changelog field posted the new version text to subscribers in the app's Bitrix24 messenger channel feed whatever the key mode was.

After

Deploying with a Read-only key does not post the announcement: posting to the feed is a Bitrix24 write. The version note is still saved to the source depot, the catalog card and the icon are published, and the response warnings carries a notice. The HTTP 200 response is unchanged.

What to do: to post announcements, deploy with a key in the Read and write mode.

NEW-0925-22: `note` field in the `eventDelivery` block of the `GET /v1/me` response

The eventDelivery block of the GET /v1/me response has a new note field. It explains under which key modes events and callbacks arrive without auth[access_token] and auth[refresh_token], what follows from that, and how to get the tokens back. The field is present whenever the response has the eventDelivery block, whatever the mode of the key calling GET /v1/me.

NEW-0925-23: Vibe credits by Bitrix24 account: GET /v1/platform/revenue/credits

The Revenue Export API returned only purchased tranches (GET /v1/platform/revenue/topups) and their expirations (/expirations): gifted credits — the starter grant, Bitrix24 bonuses, manual credits, compensations — as well as credits returned by a refund, purchased ones included, never appeared in the exports, so the path of credits in a Bitrix24 account from being credited to a zero balance did not add up.

The new GET /v1/platform/revenue/credits method (key scope revenue:spend) returns every Vibe credits tranche per Bitrix24 account, purchased and gifted, one row per tranche: the kind of credit (kind takes the same values as funding in /spend), the tranche source, for a refund the item of the refunded subscription, the amounts "credited / spent / remaining / expired / revoked" as of the request, and the credit, expiry and revocation dates. The from/to window is optional and filters the credit date, the current day included; a page holds up to limit rows, walked with nextCursor; the format is JSON or CSV. Other methods are unchanged.