Changelog

What changed in the public API.

How we change the API

Additions break nothing and ship without notice. A new field in a response, a new optional parameter, a new method, a new webhook event — any of these can appear at any time. Your code should tolerate fields it does not know.

Breaking changes mean a new version — /v2/. The old version lives for at least six months after the new one ships, and we announce it in advance.

What counts as breaking: removing or renaming a field, a method, an error code, a scope or a webhook event; adding a required request field; changing a field's type.

v1.5.0 — 14 October 2026

Additions only. Everything that worked before works the same.

• Write to a customer first — POST /v1/conversations: a new conversation with an existing contact and the first message on a chosen channel (by default where the customer was last active). Channels that cannot start a conversation refuse exactly as in the app. New scope conversations:start.
• Calls: a call card in /messages now carries a call object — duration, recordings (links live 10 minutes), summary, and the transcript with ?include=transcript. Only for keys holding the new scope calls:read. Call a customer — POST /v1/conversations/{id}/calls, scope calls:make: the given employee's phone (operator_id) rings first, then the customer's. Only the contact's own numbers can be dialled — add a new number to the contact first.
• Conversation quality review — GET and PUT /v1/conversations/{id}/quality, scopes quality:read and quality:write. A key's review is signed «API · <key>».
• Video meeting in a conversation — POST /v1/conversations/{id}/meetings: a meeting hosted by operator_id and its link sent to the customer. Scope meetings:write.
• Contact custom fields: attributes on POST and PATCH /v1/contacts by the same rules as the widget: an unknown field is kept and shown on the card under «Other», a value of the wrong type is dropped, a long one is cut — and the response field attribute_warnings reports each of these. The field schema — GET /v1/contacts/attributes.
• Notes on a contact card — GET (new scope notes:read) and POST /v1/contacts/{id}/notes (notes:write). A key's note is signed «API · <key>».
• Saved replies — GET /v1/macros and GET /v1/macros/{id} (macros:read), POST and PATCH (macros:write). The list is paged, newest first, with q searching the title and shortcut. Shared team replies only; employees' personal macros are not visible to a key.
• Tags — POST /v1/tags and PATCH /v1/tags/{id}, scope tags:write.
• Help centre: a key with kb:write reads drafts and the archive (?status=draft|archived|all); image and video upload for articles — POST /v1/kb/media; AI translation of an article — POST /v1/kb/articles/{id}/translate, a separate scope kb:translate because it spends the company's tokens; a language the AI translated after the original's last edit is skipped (up_to_date).
• `GET /v1/me`: the project's time zone, language and working hours, and acts_as — whose behalf the key acts on.
• A key acting as an employee. In Settings → API a key has «Acts on behalf of»: no author (an integration, as before) or an employee. A key with an author acts with that person's rights and visibility, everything it does is signed «Maria Ivanova · API · <key>», and operator_id defaults to the author. If the author is deactivated, the key answers 403 key_author_inactive.
• If the customer already has an open conversation on that channel that the key's employee cannot see, POST /v1/conversations answers 409 and sends nothing.
• Keys that already held kb:write now also read drafts and upload article images. The macros:write scope is marked sensitive.
• Notes on a client company — GET and POST /v1/organizations/{id}/notes; only a key with an author may write (otherwise 409 author_required).
• Edited and deleted replies: messages in /messages and in message.* webhooks carry edited_at and deleted_at. An employee can fix or delete their reply in the customer's channel; a deleted reply stays in the list with deleted_at — the customer no longer sees it, body keeps what was sent.
• MCP: new tools start_conversation (write to a customer first — only through a person's confirmation, like a reply) and list_macros (saved replies). add_note also writes on a contact card, update_contact handles custom fields, tags and client companies, search_knowledge_base finds drafts.

v1.4.2 — 27 September 2026

Additions only.

• Customer ratings (the «Rate the operator» scenario step): analytics/quality.customer_ratings — sent, responded, response_rate, avg_score, distribution, by_channel; analytics/operators rows gain customer_score and customer_ratings (credited to the operator the customer was asked about); analytics/overview.kpis gain customer_score and customer_ratings. Kept apart from the AI score.
• `analytics/quality`: new fields closed (dialogs closed in the period —

the coverage denominator: evaluated ÷ closed), reasons (low-score reasons, most frequent first), detail_scored (confident scores that carry detail); by_operator gains auto_fails and criteria (mean 1–5 per judge criterion, null without detail); by_week gains days (calendar days in the week: 7, or fewer for a short last week).

• `analytics/revenue`: saving the «Финансы» stage map now re-labels every

stored deal of the company at once; a won deal the CRM later moves to a lost stage (a refund) leaves the revenue within 90 days of the win. A Bitrix24 win date is taken from CLOSEDATE only when it is a past moment (a planned date in the future is not).

• The overview / channels / teams reports aggregate in the database

rather than in server memory: same numbers, faster on long periods.

v1.4.1 — 24 September 2026

Analytics report fixes. Fields and methods are unchanged; the numbers change — now correct.

• `analytics/operators`: handled — dialogs where the operator replied to

the customer at least once in the period (was: dialogs assigned to them now). closed — dialogs they closed themselves. avg_resolution_seconds — the life of the dialogs they closed. resolved_share — the share of handled dialogs closed now. The operator filter picks operator rows.

• `analytics/revenue`: a deal counts once — on its nearest dialog (created

no earlier than 7 days before the dialog opened and no later than 30 days after it closed). New field currency: by_channel, by_operator and per_day are in that currency only — other currencies are no longer added in. An operator's revenue goes to whoever closed the dialog.

• `analytics/overview`: ai_quality is now filled — the mean score, as in

the «Quality» report.

• `analytics/revenue`: new cohort_won_count — won deals on dialogs closed in

the period (one cohort with open_count and lost_count); won_count still follows the recognition date.

• `analytics/bot`: autonomous_share is now computed (resolved by the agent ÷

taken by the agent); with no outcomes yet it is null with the reason no_outcomes_yet (draft_mode_only is no longer returned).

• An explicit period longer than 366 days is cut to 366 (like days).
• Spam counts in no report.
• `analytics/overview`: resolved and resolved_share — of the dialogs

started in the period, how many are closed now; never above 100%. Internal notes no longer count as the first response.

• Period: date-only bounds (2026-09-01) mean midnight in the company's

time zone. Bounds with a time are taken as-is, as before.

• A key limited to «own» dialogs and the operator / team filters now really

narrow «Операторы», «Команды» and «Качество».

v1.4.0 — 13 September 2026

Connecting an assistant got simpler. Existing connections keep working.

• No key is needed to connect. You sign in as yourself and the assistant

acts with your permissions — including a narrowed dialog visibility if you have one. Before this you had to create a key and tick thirteen boxes first.

• The connection's permission is a «Read» / «Read and write» switch, changed in

the console without reconnecting.

• A key remains for one case: giving an assistant less than you have. It is

a folded line on the consent screen.

• One address. /mcp/readonly keeps working for anyone who already pasted it,

but it is gone from the console: the switch does the same thing more clearly.

v1.3.0 — 13 September 2026

Our own MCP server. An addition: nothing in the REST surface changed.

• Two addresses: /mcp — everything the key allows — and /mcp/readonly,

reading only, where no action is available even to a key that allows one.

• 19 tools shaped as whole tasks rather than as API methods. The list an

application sees is assembled for the one key it holds: what the key does not allow is not in the list.

• Sign-in over OAuth 2.1 with PKCE — the application registers itself, a

person in the console picks a key and approves. An ordinary API key in the header works too, without the consent screen.

• A reply to a customer is not sent straight away: the tool returns a link

where a person sees the exact text and presses Send. The check is on our side and cannot be bypassed.

• Text a customer wrote reaches the model marked as someone else's.
• Connected applications are listed in Settings → API & MCP and disconnect with one

button.

Details in the guide «Connect an assistant (MCP)».

v1.2.0 — 13 September 2026

Writing to the help centre, and meetings. Additive: nothing existing changed.

• A kb:write scope — create and edit articles and categories. The body is

accepted as Markdown. There is no delete, and the key holds no permission for one: removing published content stays a person's decision in the app.

• A new article is created as a draft. Publishing is a separate parameter, and

it is also what puts the article into the AI operator's index.

• A conferences:read scope — meetings with their summaries, decisions and

transcripts. Asks for both the meetings and the transcript permission.

• Two webhook events: conference.ended (the call finished — always) and

conference.transcript_ready (transcript and summary ready — only where there was a recording).

See the «Writing to the help centre» and «Meetings» guides.

v1.1.0 — 13 September 2026

Analytics. Additive: nothing existing changed or was removed.

• A new analytics:read scope. It covers the money reports too, so only

someone who holds both analytics and revenue rights — and who sees every conversation — can create such a key.

• Seven reports: overview, channels, teams, operators, revenue, dialog quality

and the AI operator. Plus filters, which returns the values the filters accept.

• Every report takes the same parameters: a from/to period and filters by

channel, team and operator. The period must not exceed 366 days.

• No cursor in reports: a report is a whole answer, not a page of a list.

See the «Analytics» guide for the details.

v1.0.0 — 12 September 2026

The first release.

• Project-level keys with resource:verb scopes.
• Reading: conversations, messages, contacts, client organizations, tags, users, teams, help center.
• Writing: conversation status and assignment, tags, replies and internal notes, creating and editing contacts and organizations.
• Webhooks: eight events, HMAC-SHA256 signatures, retries, a 7-day delivery log.
• Cursor pagination, one error envelope with a request id, Idempotency-Key, rate limits with headers.