Битрикс24 перевел CRM-формы и торговый каталог на REST 3.0: что это дает интеграции сайта и склада в Казахстане

22 октября 2026 года Битрикс24 добавил в REST 3.0 методы для CRM-форм и торгового каталога: товары, цены, складские документы. Об этом сказано в журнале изменений REST API Битрикс24. Для бизнеса в Казахстане это значит, что сайт, интернет-магазин и учетная система теперь могут обмениваться с порталом заявками, товарами и остатками через новый, более предсказуемый интерфейс.

Звучит как новость для программистов, но последствия у нее вполне управленческие. Почти каждая интеграция, которую компания заказывает для своего портала, держится на трех вещах: заявка с сайта попадает в CRM, товары и цены совпадают с учетом, остатки на складе не расходятся с тем, что видит менеджер. Все три направления 22 октября получили новые методы. Одним компаниям есть смысл переписать интеграции уже сейчас, другим спешить некуда, и разница зависит от того, что у вас болит.

Что именно появилось в REST 3.0 22 октября

В REST 3.0 перенесли группы методов для CRM-форм, торгового каталога, форума и инфоблоков. Если коротко, в одном обновлении собраны почти все сущности, через которые портал общается с сайтом и интернет-магазином.

REST 3.0 — это новая версия программного интерфейса Битрикс24, в которой у всех методов единый формат ответа, единая схема фильтров и возможность получить связанные данные одним запросом. Она работает параллельно со старой версией и ее не отменяет.

По журналу изменений, 22 октября добавили:

• CRM-формы (crm.form.*): поиск, создание, частичное обновление, включение и выключение, удаление, получение кода для встраивания на сайт и настройки показа.
• Каталоги и справочники: каталоги, разделы, единицы измерения, ставки НДС.
• Цены: цены, типы цен, правила округления, наценки, коэффициенты единиц.
• Товары: простые товары, товары с вариациями, вариации, услуги, картинки товаров, списки типов товаров и свойств.
• Складской учет: складские документы, их товарные позиции, контрагенты документов, поставщики.
• Форум и инфоблоки: удаление сообщений, пользовательские поля сообщений, получение элементов инфоблоков со свойствами. Методы инфоблоков работают только с теми инфоблоками, для которых в административной панели включен доступ по REST.

Это не единственное октябрьское изменение. За день до этого, 21 октября, в REST 3.0 появились методы Базы знаний 2.0 и метод log.blogcomment.get для чтения комментариев к постам Ленты. 23 октября добавили методы sign.b2e.provider.* для подключения своего провайдера подписи в КЭДО. Все это продолжение сентябрьского обновления, о котором мы писали в статье про batch 3.0 и методы BI-Конструктора.

Чем REST 3.0 отличается от старой версии API

Главное отличие в адресе вызова: в REST 3.0 в нем есть сегмент /rest/api/, и без него портал выполнит старый метод. Остальные отличия описаны в обзоре REST API 3.0 в документации Битрикс24. Мы свели их в таблицу:

Что сравниваем	Старая версия REST	REST 3.0
Адрес вызова	/rest/{user_id}/{код}/{метод}	/rest/api/{user_id}/{код}/{метод}
Формат ответа	Отличается от метода к методу	Единый: данные в result, списки в items, ошибки с code и message
Связанные данные	Отдельный запрос на каждую связь	Поля связанных объектов в select через точку, например responsible.name
Фильтры	У разных методов разные правила	Одна схема для всех: по умолчанию И, группы ИЛИ через "logic": "or"
Повтор запроса	Риск создать дубль	Заголовок Idempotency-Key защищает от дублей при повторе
Параметры	Можно передавать в адресной строке	Только POST с телом в JSON, параметры в адресе игнорируются
Документация	Только на сайте	Есть встроенная документация OpenAPI через rest.documentation.openapi

Для владельца бизнеса из этой таблицы важны две строки. Первая про повтор запроса. Если сайт отправил заявку, а связь оборвалась до ответа, интеграция обычно отправляет ее еще раз, и в CRM появляются два одинаковых лида. Заголовок Idempotency-Key решает эту проблему на уровне API. Вторая про связанные данные: меньше запросов означает меньше упоров в лимиты, о которых мы подробно писали в материале об ограничениях REST API Битрикс24.

Старые методы продолжают работать по старому адресу. Документация прямо говорит, что обе версии действуют одновременно и не заменяют друг друга. Поэтому срочно переписывать работающую интеграцию никто не обязывает.

Как CRM-формы через API помогают интеграции сайта с Битрикс24

Через методы crm.form.* форму CRM теперь можно создать, проверить, включить и встроить на сайт программно, без ручной настройки в конструкторе. Подробное описание есть в справке по методам CRM-форм.

CRM-форма — это встроенный в Битрикс24 конструктор форм, заявки из которого сразу попадают в CRM в виде лида, сделки или контакта. Раньше ее настраивали руками в интерфейсе, а потом копировали код на сайт. Теперь доступны такие операции:

• crm.form.add, crm.form.update, crm.form.get, crm.form.list, crm.form.delete для создания, частичного обновления, чтения и удаления форм;
• crm.form.validate проверяет настройки без сохранения и возвращает сразу все нарушения;
• crm.form.activate и crm.form.deactivate включают и выключают форму;
• crm.form.embedding.get отдает код для встраивания на сайт, публичную ссылку и текущие настройки показа;
• crm.form.embedding.update сохраняет настройки показа по клику и автопоказа;
• crm.form.configuration.get возвращает справочные данные конструктора: схемы CRM, воронки, типы полей, права текущего пользователя и лимит активных форм.

Где это пригодится на практике. Компания с несколькими сайтами или лендингами под рекламные кампании может заводить формы скриптом по шаблону, с правильной воронкой и ответственными, а не собирать каждую вручную. Агентство или подрядчик может перед запуском кампании проверить через crm.form.validate, что форма вообще соберется, и узнать о проблеме до того, как на сайт пошел трафик.

Есть и ограничения, которые важно знать заранее:

• методы недоступны на бесплатном и демо-тарифах;
• число активных форм ограничено тарифом, при превышении лимита активация вернет ошибку CRM_FORM_ACTIVATION_LIMIT_REACHED;
• системные формы с признаком system: true нельзя изменить, выключить или удалить;
• удалить активную форму можно только с подтверждением confirmed: true;
• привязать форму к виджету на сайте или к открытой линии через REST нельзя, эти методы работают только на чтение;
• при обновлении нужно передавать текущую версию формы updatedTime, иначе API вернет CRM_FORM_VERSION_MISMATCH.

У последнего пункта есть и плюс. Если два человека одновременно правят одну форму, например маркетолог в интерфейсе и скрипт подрядчика, изменения одного не затрут молча изменения другого. Раньше такие конфликты выяснялись, когда заявки уже терялись.

Если заявки с сайта у вас уже сейчас доходят до CRM не все, причина обычно не в версии API. Порядок поиска мы описали в статье «Форма с сайта не создает лид в Битрикс24».

Что меняется для каталога, цен и склада

Торговый каталог в REST 3.0 позволяет загружать товары, цены и складские документы в Битрикс24 по единым правилам, и для интернет-магазинов это самая заметная часть обновления. Именно здесь чаще всего ломаются интеграции с сайтом, учетной системой и маркетплейсами.

По справке по товарам каталога, у каждого типа товара своя группа методов: простые товары, услуги, товары с вариациями и сами вариации. Старые методы и методы REST 3.0 описаны рядом, и у новой версии есть особенности, которые обязательно нужно учесть при переносе:

• метод списка требует фильтр по iblockId с оператором =, фильтровать по значениям свойств нельзя, на странице не больше 50 записей;
• add и update не сохраняют картинки анонса и детальные картинки, их загружают отдельно через catalog.product.image.add;
• при включенном складском учете не сохраняются количество и закупочная цена: эти данные меняются только через складские документы;
• значение одиночного свойства нужно оборачивать в объект {"VALUE": ...}, обычная строка не сохранится.

Третий пункт часто становится сюрпризом. Многие самописные обмены с сайтом или учетной системой годами записывали остатки прямо в карточку товара. В REST 3.0 при включенном складском учете так не получится. На наш взгляд, это разумное ограничение: остаток, который поменялся без документа, потом трудно объяснить и бухгалтеру, и руководителю.

Складские документы описаны в справке по складским документам. Поддерживаются пять типов: приход, оприходование, перемещение между складами, возврат и списание. В REST 3.0 провести или отменить проведение можно сразу для массива документов. Важная деталь: такая групповая операция не откатывается целиком. Корректные документы проведутся, а по остальным вернутся ошибки, поэтому интеграция обязана разбирать ответ построчно, а не смотреть только на общий статус. Методы добавления, изменения и удаления документов недоступны, если складской учет не входит в тариф.

Для Казахстана отдельно пригодятся методы ставок НДС catalog.vat.*. С 2026 года базовая ставка НДС в Казахстане составляет 16%, и компании, которые перешли на нее, должны были поправить ставку и в каталоге, и в шаблонах документов. Теперь это можно проверить и привести в порядок скриптом, а не перебирать товары вручную.

Нужно ли переписывать текущие интеграции

Нет, работающую интеграцию переписывать прямо сейчас не обязательно: старые методы продолжают действовать, и документация не называет даты их отключения. Сам по себе выход новой версии поводом для доработок не является, решать стоит по состоянию своих обменов.

Переход на REST 3.0 имеет смысл, если:

• вы как раз заказываете новую интеграцию сайта или интернет-магазина с Битрикс24. Писать новый код на версии, которая уже устаревает, нет смысла;
• в CRM регулярно появляются дубли лидов или сделок после сбоев связи. Idempotency-Key закрывает эту проблему;
• обмен упирается в лимиты запросов, а данные по связанным объектам приходится забирать отдельными вызовами;
• у вас много сайтов и форм, и их настройка вручную занимает время маркетолога или подрядчика.

Подождать можно, если интеграция стабильна, данные не расходятся, а бюджет на доработки в этом квартале нужен под другие задачи. В этом случае достаточно зафиксировать переход в плане работ на следующий год.

Отдельно о коробочной версии. В обзоре REST 3.0 не сказано, чем доступность методов в коробке отличается от облака. Сказано только, что по новому адресу доступны лишь те методы, которые уже перенесли. Владельцам коробки стоит проверить наличие нужных методов на своем портале после установки обновлений, а не полагаться на то, что все из журнала изменений уже доступно у них.

По нашему опыту внедрений в B2BPRO.KZ, интеграции чаще всего ломаются не при смене версии API, а в момент, когда никто не помнит, как они устроены. Подрядчик ушел, документации нет, а скрипт обмена лежит на хостинге сайта. Поэтому переход на REST 3.0 хорошо совмещать с ревизией: описать, какие данные и в какую сторону ходят, кто отвечает за обмен и что делать при сбое.

Как подготовиться к переходу: план на две недели

Подготовка к REST 3.0 начинается с инвентаризации того, что уже подключено к порталу, и для большинства компаний занимает одну-две недели. Ниже порядок, которым мы пользуемся сами:

1. Соберите список интеграций. В разделе приложений портала посмотрите входящие вебхуки и установленные локальные приложения. Для каждого запишите, кто его создал, что оно делает и от имени какого пользователя работает.
2. Проверьте, на чем написан код. Официальные SDK b24phpsdk, BX24.js и PHP CRest пока не поддерживают адрес /rest/api/. Если интеграция построена на них, для REST 3.0 понадобятся прямые HTTP-запросы или переход на SDK с поддержкой новой версии: b24jssdk, b24pysdk или b24gosdk.
3. Отметьте болевые точки. Где бывают дубли, где расходятся остатки, где заявки теряются. Это и есть приоритет для переноса.
4. Проверьте тариф. Методы CRM-форм не работают на бесплатном и демо-тарифах, а методы изменения складских документов требуют тарифа со складским учетом.
5. Начните с одного направления. Обычно это заявки с сайта: обмен короткий, результат виден сразу, а риск для учета минимальный.
6. Тестируйте на копии данных. Создайте тестовую воронку или тестовый каталог, прогоните обмен, сравните результат со старым.
7. Запишите, как устроена новая интеграция. Хватит одной страницы: что, откуда и куда передается, где лежит код, кто отвечает.

Если сайт и портал делали разные подрядчики, на этом этапе полезно собрать их вместе. Ошибки обмена чаще всего возникают на стыке, где каждая сторона уверена, что проблема у другой. Когда сайт нужно переделывать под новую схему обмена, это задача для разработки сайтов под ключ, а сторону портала закрывает внедрение и настройка Битрикс24.

Пример: интернет-магазин с витриной на сайте и складом в Битрикс24

Возьмем условный пример, чтобы показать, где новые методы дают эффект. Магазин в Алматы продает товары через свой сайт и маркетплейс. Заявки с сайта уходят в Битрикс24, а каталог и остатки ведутся в портале со складским учетом.

Типичные проблемы такого магазина выглядят так. Покупатель дважды нажимает «Отправить», связь подвисает, и менеджеры звонят ему вдвоем. Остатки на сайте обновляются раз в сутки, и вечером продаются товары, которых уже нет. Цены в акции правят вручную в двух местах.

Что можно сделать с новыми методами:

• заявки с сайта отправлять с Idempotency-Key, чтобы повторная отправка не создавала второй лид;
• при поступлении товара проводить приходный документ через catalog.document.*, а сайт забирает остатки из портала, не записывая их сам;
• цены и типы цен держать в каталоге Битрикс24 через catalog.price.* и catalog.pricetype.*, а сайт и выгрузка на маркетплейс берут их оттуда;
• формы для рекламных лендингов собирать по шаблону через crm.form.add и проверять через crm.form.validate до запуска кампании.

Пример условный, и переносить его один в один не стоит. Конкретная схема зависит от того, где у компании главный учет. Если главная учетная система внешняя, портал не должен становиться вторым источником правды по остаткам, иначе расхождения никуда не денутся.

Типичные ошибки при работе с REST 3.0

Чаще всего ошибки при переходе возникают из-за ожидания, что новая версия работает так же, как старая, только по другому адресу. Вот что мы советуем проверить:

• Забыли сегмент /api/. Запрос уйдет в старый метод, если он существует, и разработчик будет думать, что работает с новой версией.
• Передают параметры в адресной строке. REST 3.0 их игнорирует, нужен POST с телом в JSON.
• Пишут картинки и остатки в карточку товара. Картинки грузятся отдельным методом, остатки при складском учете меняются только документами.
• Не разбирают ответ групповых операций. Проведение массива документов не откатывается целиком, часть может пройти, часть нет.
• Игнорируют версию формы. Без актуального updatedTime обновление формы не пройдет.
• Дают интеграции права администратора. Методы складских документов в REST 3.0 проверяют права пользователя на конкретный тип документа. Удобнее завести отдельного пользователя с нужными правами, чем пускать скрипт под администратором.

Частые вопросы

Перестанут ли работать старые интеграции с Битрикс24 после выхода REST 3.0?

Нет, старые методы продолжают работать по прежнему адресу. По документации Битрикс24, обе версии API действуют одновременно и не заменяют друг друга, а дата отключения старой версии не названа. Переписывать стабильную интеграцию срочно не нужно, но новые интеграции лучше сразу делать на REST 3.0.

Можно ли создавать CRM-формы через API на бесплатном тарифе?

Нет, методы CRM-форм в REST 3.0 недоступны на бесплатном и демо-тарифах. Кроме того, тариф ограничивает число активных форм: при превышении лимита активация вернет ошибку. Перед тем как планировать автоматическое создание форм для сайтов и лендингов, проверьте условия своего тарифа.

Как понять, на какой версии API работает наша интеграция?

Посмотрите адрес, на который скрипт отправляет запросы. Если в нем есть сегмент /rest/api/, это REST 3.0. Если адрес вида /rest/номер/код/метод без /api/, используется старая версия. Еще один признак: интеграции на PHP CRest и BX24.js пока работают только со старой версией.

Можно ли через REST 3.0 менять остатки товаров напрямую?

При включенном складском учете нельзя: количество и закупочная цена в карточке товара через методы REST 3.0 не сохраняются. Остатки меняются складскими документами: приходом, оприходованием, перемещением, возвратом или списанием. Это делает движение товара прозрачным, но требует переделки обменов, которые раньше писали остаток напрямую.

Сколько времени занимает переход интеграции сайта на REST 3.0?

Зависит от числа обменов и качества старого кода. Перенос одной формы заявок обычно укладывается в несколько дней вместе с тестами. Обмен каталогом и остатками сложнее: нужно учесть отдельную загрузку картинок, складские документы и постраничную выборку по 50 записей. Начинать удобнее с заявок, а каталог переносить вторым этапом.