# API changes: June 23, 2026

[← Changelog](/docs/changelog) · [June 2026](/docs/changelog/2026-06)

### 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](/docs/infra/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](/docs/entities/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](/docs/scrum) 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](/docs/keys-auth)).

**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](/docs/infra/servers/get) 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](/docs/infra/servers/list) and [delete](/docs/infra/servers/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](/docs/infra/servers/list)) as the deletion signal.

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

A new [Lists](/docs/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](/docs/entities/smart-processes/create) and [PATCH /v1/smart-processes/:entityTypeId](/docs/entities/smart-processes/update) 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](/docs/entities/deals/list), [POST /v1/deals/search](/docs/entities/deals/search)