API changes: October 2, 2026

← Changelog · October 2026

NEW-1002-1: Work and daily reports

Work and daily reports are available through the workday API. Work reports can be read, created, updated, sent and evaluated. Daily reports can be read and saved to the caller's own workday record. Submitting without reportId creates and immediately sends a new report. Absent and null fields in partial updates are preserved.

NEW-1002-2: Pay systems and delivery services

Added /v1/pay-systems and /v1/delivery-services: complete lists, read by ID, create, update, delete and /handlers to select a registered handler. They require pay_system and delivery scopes respectively; sale alone is insufficient. Updates and deletion are available only for REST-handler services, subject to Bitrix24 permissions. PATCH returns the record read back; delivery creation returns parent and profiles. Send a logo as logo: [filename, base64], up to 2 MiB. These sections have no pagination, handler registration or generic batch.

NEW-1002-3: Open Line operator actions

Open Line operator actions now include skipping a dialog, marking a client as spam, transferring to an employee or queue and finishing another operator's dialog. Operator pause can be read, started and stopped for the token owner: the webhook issuer or calling OAuth employee. Added client chat open by connector code and session start. All operations require imopenlines, and writes are forbidden for READONLY keys. Marking spam closes the dialog and marks the client as a spammer.

Affected endpoints: POST /v1/openlines/operator/skip, POST /v1/openlines/operator/spam, POST /v1/openlines/operator/transfer, POST /v1/openlines/operator/finish-another, GET /v1/openlines/operator/pause, POST /v1/openlines/operator/pause, DELETE /v1/openlines/operator/pause, POST /v1/openlines/sessions/open, POST /v1/openlines/sessions/start.

NEW-1002-4: Booking resource CRUD, resource types and work hours

Added GET /v1/booking-resources/:id, POST /v1/booking-resources, PATCH|DELETE /v1/booking-resources/:id, list and CRUD at /v1/booking-resource-types, and GET|PUT|DELETE /v1/booking-resources/:id/slots. Requires booking scope and READWRITE for writes. Create returns 201 and the reread card, PATCH returns 200 and the card, delete returns empty 204. Cards return notification switches as booleans; the existing resource list retains Y/N.

PUT slots replaces the entire work-hour set; DELETE removes all slots. Type lists walk pages by row count and ignore the Bitrix24 total, up to 500 types. Bitrix24 enables client notifications by default: explicitly disable all six is*NotificationOn switches when needed. Future bookings prevent resource deletion; active resources prevent type deletion. Bitrix24 refusals return 422; missing records return 404, malformed id or body shape returns 400. Some cloud versions require a new code for type updates and reject the existing code as a duplicate.

Resource PATCH with saved slots returns 422 BOOKING_RESOURCE_SCHEDULE_CONFLICT because native update deletes them. Invalid IANA time zones and zero slot size return 400 before dispatch.

NEW-1002-5: Bot commands and notification actions

Added GET /v1/chats/:dialogId/commands, POST /v1/chats/messages/:messageId/command and POST /v1/chats/messages/:messageId/unread with required dialogId in the body. Available: POST /v1/notifications/:id/answer, POST /v1/notifications/:id/confirm and GET /v1/notifications/search. All require im; actions require write access. Confirming a button executes its action and deletes the notification. Search uses the lastId cursor.

NEW-1002-6: Booking clients and wait list

Added booking clients, client types and the wait list: read, create, update, delete, replace clients and transfer between bookings and the queue. Client PUT replaces the entire roster. Transfers remove the source record. Scope booking. Empty wait list entries are allowed. List traversal ignores the Bitrix24 total. Notification-enabled resources may send messages to clients.

BC-1002-7: Cowork tries to finish ongoing work before the five-hour limit

Old format supported until: not provided

Before

Cowork chat requests with tools continued ordinary work until the window allowance was exhausted. An explicit named tool_choice required a call to the selected function.

After

For enabled users, POST /v1/chat/completions with a small positive five-hour allowance asks the model to briefly finish the part already in progress. A new turn is asked to wait until the window resets and is sent without tools. This is an attempt to finish, with no extra quota or guarantee of file correctness. Existing hard five-hour, weekly and monthly limits remain in force. JSON and structured responses keep their current behavior; no response fields are added.

During finishing, a named tool_choice becomes auto, so the response may contain text without calling the selected function. A deferred new turn does not call a tool. The change applies only after the feature is enabled for the relevant users. While disabled, behavior stays unchanged; there is no separate support period for the former guarantee after enablement.

What integrators should do

Before enablement for your users, verify that the client handles an ordinary text response even with an explicitly selected function. Do not require unconditional tool_calls: show the summary and finish the current turn without automatically restarting the tool. Request and response field formats stay unchanged. Resume deferred work after the window resets.

NEW-1002-8: Open Line CRM chats and quick replies

Open Line CRM chat members: POST|DELETE /v1/openlines/crm/chats/users. Message to the client from an employee or bot: POST /v1/openlines/crm/messages. CRM binding after creating a lead from a dialog: POST /v1/openlines/dialogs/:chatId/lead.

Line quick replies: GET|POST /v1/openline-configs/:lineId/quick-replies, PATCH|DELETE /v1/openline-configs/:lineId/quick-replies/:id. PATCH preserves omitted sectionId. Scope: imopenlines; writes require a write-enabled key.

NEW-1002-9: Operator actions accept chat

POST /v1/openlines/operator/answer and /finish accept the chat<N> form for chatId, alongside a number or numeric string. Obtain the identifier from event.data.chat.id or session search sessions[].chatId.

NEW-1002-10: Open Line bot session actions

Added POST /v1/bots/:botId/openlines/session/operator, /transfer, /finish and /auto-message. Both imbot and imopenlines scopes are required. Handoff changes session state, while leaving an IM chat changes membership only. Automatic messages accept WELCOME or DEFAULT with a message; the response acknowledges the call, not delivery.

FIX-1002-11: Operator actions refuse imprecise identifiers

POST /v1/openlines/operator/answer and /finish return 400 INVALID_CHAT_ID for fractions and values outside the safe integer range, including numeric strings. Such input no longer addresses a neighboring chat after rounding.

FIX-1002-13: a multipart upload reservation now counts against the Bitrix24 account storage cap immediately

Before

The declared size of a multipart upload (POST /v1/storage/objects/multipart/create) was not always counted as used space: when replacing an existing object it was not counted at all, and inside a short caching window the calculation did not see a freshly opened reservation either. An account under the hard storage cap could open several uploads in a row and reserve more than the cap in total — the refusal arrived later, after the parts had been uploaded.

After

The declared size counts from the moment the upload is opened, identically in all cases, including replacement of an existing object. Opening an upload successfully still answers HTTP 200 with the same fields; only the completeness of the accounting changed, so an upload that exceeds the cap now gets 507 STORAGE_QUOTA_EXCEEDED right away, before the provider session is created, instead of after the parts are uploaded. The visible size of the replaced object does not change until the upload completes. An abandoned upload stops holding space once its session expires.

BC-1002-14: unsupported CRM product sort fields now report an error

Old format supported until: not provided

Before

GET /v1/products and POST /v1/products/search accepted sorting by fields that Bitrix24 does not sort, such as price, and returned HTTP 200 in the default order.

After

Sorting by an unsupported product field, including price and the raw name PRICE, returns HTTP 400 UNKNOWN_SORT_FIELD with the supported-field list. Sorting by supported fields and by catalog properties PROPERTY_<n> remains HTTP 200.

What integrators should do

Stop sorting products by price, currency, catalogId, measure, VAT or image fields. If you need price order, sort the response on your side or read prices from /v1/catalog-prices.

BC-1002-15: an unreadable smart-process userfield id is refused before the Bitrix24 account is called

Old format supported until: not provided

Before

GET /v1/items/{entityTypeId}/userfields/{id} accepted any string in :id. A value with no digits reached the Bitrix24 account empty, and the request ended with a Bitrix24 error about a missing required parameter. A value starting with digits was silently cut at the first foreign character: :id set to 7abc answered 200 with the description of the field numbered 7.

After

:id must be a positive integer in plain notation: digits only, no leading zero, no sign, no fraction, no exponent and no 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.

What integrators should do

If the field number comes from the smart-process field list and is passed as is, nothing changes — such calls work as before.

Three classes of value are now refused, and they differ by what used to arrive:

• the description of a FOREIGN field used to arrive under 200 — a string with digits in front and a foreign tail (7abc was read as 7), an exponent (7e2 was read as 7, not 700) and a number greater than 9007199254740991 (on conversion it slid to a neighbouring one). These calls returned something other than what you asked for, and said nothing about it;
• the CORRECT field used to arrive under 200 — a number written in a non-plain form: a leading zero (007), a sign (+7), a fraction (7.0), spaces around the edges. Such calls worked correctly and now receive a 400. This is the only class the change breaks for an integration that worked properly — strip the extra characters and leave the digits alone;
• an error from the Bitrix24 account used to arrive — a value with no digits, including a system field name such as UF_CRM_…. The Vibecode platform now answers 400 itself, before the Bitrix24 account is called.

In all three cases, pass the numeric field number from the field list exactly as it arrives there.

Affected endpoints: GET /v1/items/{entityTypeId}/userfields/{id} and its short address for smart invoices GET /v1/userfields/invoices/{id}.

FIX-1002-16: entity list and search answer a clear error when entityTypeId did not arrive

Before

A read backed by crm.item.list — the list GET /v1/items/{entityTypeId} (and also /v1/deals, /v1/leads, /v1/contacts, /v1/companies, /v1/invoices, /v1/quotes) and its paired search POST /v1/{entity}/search — was sent to Bitrix24 even when the mandatory entityTypeId argument had not arrived. Bitrix24 refused such a call with its own error code 100 — "Could not find value for parameter {entityTypeId}" — and the client received it as a generic refusal, naming neither the parameter nor the fix.

After

Vibecode checks the argument before calling Bitrix24 on both handles and answers 400 with code MISSING_PARAMS. The message names the method, the parameter and how to supply it: for /v1/items it points at the {entityTypeId} path segment and where to look the value up (GET /v1/smart-processes), while for the other entities the value is fixed by the entity itself, so the message asks for the X-Request-Id of the response. Successful reads are unaffected — the HTTP 200 response is unchanged.

NEW-1002-17: Workgroup member actions and my workgroups

Added POST, DELETE, PATCH /v1/workgroups/:groupId/users, POST /v1/workgroups/:groupId/invitations, PUT /v1/workgroups/:groupId/owner and GET /v1/me/workgroups. Scope sonet_group; READONLY keys cannot write. Partial or empty action results return 422 BITRIX_ERROR with processedUserIds and skippedUserIds inside error. Invitations notify recipients; owner changes can add a new member. Details.

FIX-1002-18: employee sorting no longer blocks list reads

Before

A recognized multi-field sort and a UF_* sort that required multiple pages returned 400 INVALID_SORT_FIELD from GET /v1/users, POST /v1/users/search, and POST /v1/batch.

After

The same requests preserve a successful response. The requested order is replaced in full with ascending id order, and the response contains one SORT_FALLBACK_TO_ID warning for the sort field. A single ordinary field other than id still returns UNKNOWN_SORT_FIELD.

Impact on integrators

Handle the warning by its code field when the requested employee order matters to your application.

BC-1002-19: Bot registration checks account address changes and registration origin

Old format supported until: not provided

Before

POST /v1/bots could return 201 for an earlier registration after an account address change or when its local Vibecode record was missing (#1059).

After

A registration affected by an account address change is retained and returns 409 BOT_DOMAIN_REREGISTRATION_REQUIRED with data: { botId, code, needsReregistration: true }. Unproven origin returns 409 BOT_REGISTRATION_ORIGIN_UNPROVEN without changing the record. A changed key binding or account address returns 409 BOT_REGISTRATION_CONTEXT_CHANGED. A concurrent write returns 409 BOT_REGISTRATION_CONCURRENT.

What integrators should do

Handle these refusals separately from success. For a new bot, use a unique code and a personal key backed by an incoming webhook. Without a previous local record, OAuth and caller-provided tokens are refused before registration. Refresh expired legacy OAuth tokens separately. Do not automatically delete the retained Bot or key. For Agent and Managed Bot identities, use the owner resource recovery, or contact support if it is unavailable.

FIX-1002-20: empty V1 POST, PUT and PATCH requests receive validation errors

Before

An empty request without a body or a Content-Type header could cause an internal HTTP 500 error for some V1 methods.

After

The request now reaches route validation and returns the documented HTTP 400 error.

NEW-1002-21: SIP, default outgoing line and call recording

Telephony integrations using the Vibecode API can manage SIP connections, choose the outgoing line for the entire Bitrix24 account, read employee settings with an application key, attach a completed call recording and find CRM cards by phone. Passwords are write-only; responses include presence flags instead. Recordings accept base64 mp3/wav up to 2 MiB or a public HTTPS URL; the internal upload URL is never exposed.

NEW-1002-22: Business-process tasks

Added GET /v1/bizproc-tasks, POST /v1/bizproc-tasks/:id/complete and POST /v1/bizproc-tasks/delegate. The list returns a page of tasks and the next position. Completion performs a real approval with approve, reject, ok or cancel. Delegation transfers tasks to another employee. Requires bizproc scope and a key that allows writes for actions. Bitrix24 checks rights and decision validity. Delegation may fail after transferring some tasks: re-read the list before retrying.

NEW-1002-23: App document downloads and public sharing

DOCX, PDF and PNG downloads are available for /v1/documents/:id with documentgenerator scope. READONLY keys can download. A representation still being generated returns 409 DOCUMENT_NOT_READY. File size is limited to 10 MiB.

Public sharing is enabled or disabled through POST /v1/documents/:id/public-url with { enabled: boolean }. An enabled URL can be opened without a key. App document machine links now lead to authenticated Vibe API routes.

BC-1002-24: only the custom-openai-compat provider accepts a per-credential endpoint

Old format supported until: not provided

Before

Creating and updating an AI provider credential (POST and PATCH /v1/ai/credentials) accepted a credentials.baseUrl field for any provider. The address was checked — scheme and reachability — only for the custom-openai-compat provider; for openai, anthropic, openrouter and bitrix the string was stored as given and did not affect routing anyway: those providers call the platform address.

After

For every provider other than custom-openai-compat the credentials.baseUrl field is refused: HTTP 400, code base_url_not_supported. A credential without that field is created and updated exactly as before. Your own endpoint is still set on a custom-openai-compat credential, where the value is validated at save time and stored normalized.

What integrators should do

Drop credentials.baseUrl from create and update requests for every provider other than custom-openai-compat. The value never affected where the call went, so existing credentials behave the same — only the request itself needs the edit.

NEW-1002-25: Call journal and feed comments

Added the personal call journal, entry deletion and chat lookup through /v1/calls/log. Chat lookup may create a private chat and requires a writable key. GET /v1/posts/comments reads user-wide comments with separate feed and blog IDs; DELETE /v1/feed-comments/:id deletes a feed event comment. Credential-bearing links are redacted. Missing journal entries return 404 instead of silent Bitrix24 success.

NEW-1002-26: Prepared-service connectors and public OAuth client documents

POST /v1/connectors/mcp supports tools from prepared code services. Calls retain the common access checks and write approval. A configured connection to the external service is still required.

For OAuth servers supporting CIMD, the client identifier can be the HTTPS URL of an immutable public document. The document is available without an API key and contains no client secret. Existing manual settings and dynamic client registration through DCR are retained. See connector foundations.

FIX-1002-27: a personal coupon of a deleted recipient can no longer be redeemed by anyone

Before

A coupon issued to the e-mail of a person whose account was deleted on request stayed personal: a redemption attempt answered COUPON_NOT_ASSIGNED_TO_YOU. The refusal invited the caller to sign in with an address that can no longer be used, so the code looked valid and waiting for its recipient.

After

The recipient is detached from the coupon together with the deletion of the account, and nobody can redeem the code any more — neither the recipient nor anyone else: no live address matches the coupon's recipient. A coupon that was free at the moment of deletion is also closed, and a redemption attempt gets the collapsed COUPON_INVALID refusal — the same one a coupon redeemed or expired before the deletion answers with.

One state escapes the closing, and escapes it for good: a coupon whose redemption was in flight at the moment of deletion is not closed and stays in a live state. An attempt to redeem such a coupon can still get the former COUPON_NOT_ASSIGNED_TO_YOU — a refusal that still invites signing in with the recipient's address, which no longer exists. The code still cannot be redeemed.

Coupons with no recipient and coupons issued to active accounts answer as before.

NEW-1002-28: Knowledge-base moves and module field types

POST /v1/note/collections/:id/move changes the account-wide collection order. POST /v1/note/documents/:id/move moves a document with its subtree to a collection or another parent. The response contains the object read back after the move. Destination fields are optional and position may be negative.

GET /v1/userfields/types?moduleId=crm returns module field types as an array of userTypeId and description, without internal keys. The requested module scope is required. Employee field types remain unavailable.