RetailCRM pro 🕘 история названий (1)

Добавление новых фильтров в API 1. Метод /api/v5/store/products: • filter[externalIds][] - множественный фильтр по внешним ID • filter[articles][] - множественный фильтр по артикулам 2. Метод /api/v5/store/offers: • filter[articles][] - множественный фильтр по артикулам 3. Метод /api/v5/store/inventories: • filter[productExternalIds][] - множественный фильтр по внешним ID товаров Все новые фильтры принимают в качестве значения массив строк. Подробнее в документации: • GET /api/v5/store/products • GET /api/v5/store/offers • GET /api/v5/store/inventories

Включение JS-режима модуля в кабинете партнёра Ранее, чтобы перевести модуль в режим JS-модуля, нужно было обращаться в партнерский отдель. Теперь данный режим можно включить самостоятельно в карточке модуля в кабинете партнера. Где это находится Партнёрский кабинет → Маркетплейс → Редактирование модуля Что изменилось В форме редактирования модуля появился флаг Разрешать встраивать JS в систему • Признак можно включить самостоятельно • После сохранения отключить его в кабинете партнёра уже нельзя (после включения поле становится недоступным для изменения) #jsapi

Публикация новых версий JS-модулей через API В биллинге появился новый API-метод для загрузки новых версий JS-модулей в маркетплейс. Теперь партнёру не нужно загружать архив вручную через интерфейс. Публикацию новой версии можно встроить в собственный CI-процесс сборки и деплоя. Где управлять токеном В кабинете партнёра появился новый подраздел: Партнёрский кабинет → Модули → Работа с JS-модулями Раздел становится доступен, после заключения договора по проекту «Маркетплейс». В разделе можно: • посмотреть текущий токен загрузки • сгенерировать новый токен • деактивировать токен Токен общий для партнёра, а не для отдельного модуля. При регенерации токена старое значение перестаёт работать. API-метод загрузки сборки POST https://account.retailcrm.ru/api/public/v1/marketplace/module/{moduleCode}/js/upload Параметры: • moduleCode — код модуля в маркетплейсе. Заголовки: • X-MODULE-UPLOAD-TOKEN — токен доступа Тело запроса: • multipart/form-data Поле файла: • new_version — ZIP-архив с новой версией JS-модуля, не более 5 МБ. Пример запроса:

curl -X POST "https://account.retailcrm.ru/api/public/v1/marketplace/module/<moduleCode>/js/upload" \
  -H "X-MODULE-UPLOAD-TOKEN: <token>" \
  -F "new_version=@build/module.zip"

Пример успешного ответа: Код ответа: • 200 OK Тело ответа:

{
  "success": true,
  "moduleCode": "<moduleCode>"
}

Обратите внимание, что обработка новой версии асинхронная, и результат обработки будет виден в личном кабинете. Подробнее в документации https://docs.retailcrm.ru/Developers/modules/PublishingModuleMarketplace/JsModules#h-24 #jsapi

⚠️ Перенос технического домена <uid>.retailcrm.io → <uid>.rcrm-io.ru Со вторника 14 апреля 2026 г мы переносим технический адрес системы c <uid>.retailcrm.io на <uid>.rcrm-io.ru. При регистрации нового модуля в REST API registerUrl callback будет возвращать в register[systemUrl] адрес с новым доменом. Старый адрес останется доступным для обратной совместимости.

Добавлена переменная для расчета суммы покупок до следующего уровня лояльности В объект LoyaltyAccountInfo добавлена новая переменная requiredSumForNextLevel. Она возвращает сумму покупок, которой клиенту не хватает для перехода на следующий уровень программы лояльности. Переменную можно использовать вместо ручного расчета через разницу между порогом уровня и текущей суммой покупок клиента. Это упрощает настройку триггеров, валидаций и Twig-шаблонов и снижает риск ошибок при изменении порогов уровней. Пример в Twig:

{{ customer.getLoyaltyAccountBySiteCode('siteCode').requiredSumForNextLevel }}

Подробнее в документации

Изменения в API-методе расчёта максимальной скидки Добавлена возможность рассчитывать максимальную скидку для ещё не созданного клиента с учётом уровня лояльности или события. Для этого в параметрах API-метода POST /api/v5/loyalty/calculate не нужно указывать поле order[customer]. Если у магазина site, указанного в запросе, есть активная программа лояльности (ПЛ), то будут созданы виртуальный клиент и виртуальное участие. Участию начисляться welcome-бонусы и скидки по событиям в соответствии с настройками ПЛ. Бонусы по событию «День рождения» начисляться не будут. Если у магазина нет активной ПЛ, то запрос вернет соответствующую ошибку. Виртуальные участия не расходуют пакет участий в программах с расширенными возможностями. Изменения метода позволяют: - рассчитывать скидку по заказу для ещё не зарегистрированного в системе клиента с учётом бонусов за регистрацию; - видеть, какие бонусы или скидки ожидают нового клиента после оформления первого заказа. Подробнее в документации.

Номер заказа в API-методе получения статусов заказов В API-методе GET /api/v5/orders/statuses наряду с полями id и externalId теперь отдается поле с номером заказа — number. Это позволит упростить идентификацию заказов в тех случаях, когда требуется получать именно их номера, без необходимости вызывать более тяжеловесный API-метод GET /api/v5/orders. Подробнее в документации.

Улучшения в безопасности и удобстве раздела API-ключи В разделе API-ключи теперь: 1. Значения API-ключей выводятся в маскированном виде. Исходное значение доступно только при создании API-ключа. Это снижает риск утечек API-ключей. 2. Ключи можно искать фильтром по полю Комментарий 3. В списке ключей теперь видно дату-время последнего использования. Дата-время старше 3 месяцев не хранится. Если она пустая, то либо ключ не использовался, либо использовался более 3 месяцев назад.

Фильтры по ID заказа, клиента, mg-клиента в api/v5/tasks В API-методе GET /api/v5/tasks добавлены фильтры filter[orderId], filter[customerId], filter[mgCustomerId], позволяющие фильтровать задачи по ID заказа, клиента и клиента в MessageGateway, связанные с задачей. Подробнее в документации: • GET /api/v5/tasks

API-метод получения списка звонков Добавлен API-метод GET /api/v5/telephony/calls для получения списка звонков. Даный метод позволяет получить метаданные о звонке, такие как: - дата и время звонка, - длительность, - результат, - тип звонка, - теги, - транскрибация и т.д. Пагинация производится по курсору - в ответе возвращается специальная метка (pagination[nextCursor]), значение которой нужно передать в параметр cursor следующего запроса. Запись звонка доступна для получения при помощи отдельного метода - GET /api/v5/telephony/calls/{id}/record. В качестве значения id используется внутренний идентификатор звонка. Подробнее в документации: - GET /api/v5/telephony/calls - GET /api/v5/telephony/calls/{id}/record