API changes: June 23, 2026

← Changelog · June 2026

NEW-0623-10: push-delivery setup hint in event-subscription errors

The 400 NOT_OAUTH_APP and 400 NO_USER_TOKEN errors of POST /v1/infra/servers/:id/event-subscriptions now include an error.hint field — a text instruction on how to get a server backed by an authorization key (vibe_app_) for push delivery: create an authorization key via POST /v1/apps, authorize the app in the Bitrix24 account, then create a new server under that key. There is no separate "migration" of an existing server from a regular key. The field is additive — existing clients are unaffected.

FIX-0623-1: bizproc activity list

Before

GET /v1/bizproc-activities returned each activity code as an object with per-character numeric keys — for example {"0":"D","1":"i", …} instead of the string "DiskRead". The Array.includes(code) check did not work.

After

The endpoint returns activity codes as an array of strings, as documented.

FIX-0623-2: duplicate-search response keys in camelCase

Before

POST /v1/duplicates/find returned the data object keys in upper case (LEAD, CONTACT, COMPANY), unlike the rest of the API which uses camelCase.

After

Keys come back in camelCase (lead, contact, company); the values (arrays of ids) are unchanged.

FIX-0623-3: Scrum epic files field as an array of ids

Before

GET /v1/scrum/epics/:id returned the files field as a raw Bitrix24 UF object (with VALUE_RAW, USER_TYPE_ID and other internal metadata).

After

files is an array of attachment ids ([417]) or an empty array, consistent with the rest of the API.

BC-0623-4: API key creation is admin-only

Old format supported until: not applicable, the restriction takes effect immediately

Before

Any user of the account could create an API key (POST /v1/keys).

After

Key creation is available only to Bitrix24 account administrators, others are rejected.

What integrators should do

Create keys under an account with Bitrix24 administrator rights.

FIX-0623-5: Retry-After header on rate limiting

Before

On a 429 (rate limit exceeded) response the Retry-After header was not returned, so the integrator did not know when to retry.

After

The 429 response carries Retry-After with the interval in seconds. Use it as the pause before retrying.

FIX-0623-6: a deleted server returns 404 again

Before

GET /v1/infra/servers/:id returned 200 with a full body and status: "deleted" for a soft-deleted server, although the documentation promises 404. A client polling the endpoint and expecting 404 as deletion confirmation never received it.

After

The endpoint returns 404 NOT_FOUND for a deleted server — the same as the list and delete, and as described in the documentation.

Impact on integrators

If your code relied on 200 with status: "deleted", switch to checking for 404 (or for the server's absence from the list) as the deletion signal.

NEW-0623-7: Universal Lists — full REST API

A new Lists section (scope lists): programmatic access to Bitrix24 Universal Lists — the lists themselves, their fields, sections, and elements. 24 endpoints under /v1/lists over the lists.* methods.

A list is addressed by infoblock type (iblockTypeId — lists, lists_socnet, or bitrix_processes, default lists) and an identifier: a numeric path segment is treated as IBLOCK_ID, a non-numeric one as the symbolic IBLOCK_CODE. Fields, sections, and elements are available under nested paths.

If the Universal Lists module is not enabled in the account, the call returns 409 LISTS_MODULE_NOT_ENABLED — a sign the module is off, not an integration error.

Affected endpoints: /v1/lists, /v1/lists/:iblockId, /v1/lists/:iblockId/fields, /v1/lists/:iblockId/sections, /v1/lists/:iblockId/elements

FIX-0623-8: smart-process relation isChildrenListEnabled flag

Before

The nested relation flag isChildrenListEnabled was accepted only as true/false. A Y/N value, like the other smart-process flags, was silently saved as disabled.

After

POST /v1/smart-processes and PATCH /v1/smart-processes/:entityTypeId coerce Y/N (and 1/0, yes/no) to true/false for isChildrenListEnabled in relations.

FIX-0623-9: deal custom field filter and select

Before

When filtering and selecting deal custom (UF) fields in the UF_CRM_* form, the field was rejected with UNKNOWN_FILTER_FIELD in the filter and silently dropped from select.

After

Deal custom fields are given in camelCase (ufCrmCheckOut) and work unchanged in filter and select.

Affected endpoints: GET /v1/deals, POST /v1/deals/search