1С-Битрикс *

Пробовали работать с Битриксом через AI-агента? Если ещё нет, то вам будет интересно узнать, как это :-)

За полгода написал ряд интеграций с Битрикс24 в разных архитектурах: приложение для Маркета (PHP, 6 порталов), клиентский расчётный сервис (Node.js + PostgreSQL) и cron-синхронизатор legacy-CRM без UI и без OAuth вообще. Мультитенант везде решён по-разному, и это не случайность, ведь каждая архитектура точно закрывает свою нишу.

Внутри: сравнение трёх способов хранить OAuth-токены под 6+ порталов, разбор пяти неочевидных деталей REST API (oauth.bitrix24.tech-обход, POST vs GET на рефреше, rate limit 2 req/sec, batch на 50, буфер 5 мин), куски кода на PHP и TypeScript.

Отдельная часть — лицензирование через материнский смарт-процесс. У продукта, распределённого по клиентским порталам, нет своего backend’а, поэтому control-plane я вынес на служебный портал агентства: смарт-процесс «Лицензии», бизнес-процесс на изменение счётчика запросов, webhook approve/decline с secret. Такого паттерна в документации Битрикс24 нет — а он работает уже несколько месяцев и не требует ничего сверх штатной функциональности платформы.

Матрица «что выбирать под задачу» в конце.

Понадобилось дать ИИ-ассистентам (Claude Code, Cursor) доступ к данным своего сервиса — мониторы, события, аптайм, — чтобы вопрос «что сейчас в сбое?» можно было задать прямо в чате, а не идти кликать по вкладкам дашборда. Стандартный путь для этого — MCP (Model Context Protocol): сервер декларирует инструменты, и любой MCP-клиент их находит и вызывает.

Официальные примеры и SDK предлагают поднимать отдельный MCP-сервис — с транспортной машинерией, сессиями и SSE-стримингом. Я сделал иначе: один HTTP-хендлер внутри существующего Go-монолита, около 200 строк, без единой новой зависимости. Вечер работы, включая тесты curl-ом.

В статье разбираю: какой минимум JSON-RPC-методов реально требует спека для tools-only сервера (initialize, tools/list, tools/call — и почти всё), почему stateless-режим без Mcp-Session-Id легален по спецификации и что он даёт бесплатно, зачем хранить id запроса как json.RawMessage, как описывать инструменты, чтобы LLM вызывала их правильно, и какие грабли ждут при подключении Claude Code и Cursor. Весь код — из работающего продакшена, сокращён до сути.

Делимся опытом автоматизации реферальной программы: как мы ушли от хаотичного сбора рекомендаций на вакансии и запустили собственный продукт для корпоративного портала — цифровой сервис «Рекомендовать кандидата». В результате увеличили конверсию закрытия вакансий по внутренним рекомендациям до 35%.

Стандартный обмен данными в 1С-Битрикс часто превращается в ночной кошмар: полная выгрузка остатков на больших каталогах может занимать от 1 до 8 часов. Когда бизнес требует обновлять данные каждые 15 минут, штатные методы API и XML-импорт просто перестают справляться.

В этой статье я покажу, как с помощью прямого SQL запроса и временных таблиц в памяти (ENGINE=MEMORY) ускорить импорт в сотни раз. Это реальный кейс с продакшена, который стабильно работает уже 4 года на проекте с миллионом товаров и десятками складов.

Привет, Хабр! Меня зовут Леонид, я ведущий PHP-разработчик в НЛМК ИТ.Наша команда отвечает за сервисы HR-направления на едином корпоративном портале (далее – ЕКП), а также занимается развитием и поддержкой корпоративных сайтов.

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

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

Под катом делюсь обзором своего самописного PHP-фреймворка Gy — попытки сделать легковесного «убийцу» Битрикса весом 350 Кб. Расскажу, как я реализовал вызов компонентов, зачем написал кастомный SQL-движок на текстовых файлах PhpFileSql.

Костыли, велосипеды, 3 года разработки по выходным, 315 коммитов, 14232 строки кода, поддержка практически всех версий PHP и ровно 0 пользователей.

Существует немало бесплатных инструментов, способных выявлять веб-уязвимости, обнаруживать ошибки конфигурации и автоматизировать проверки безопасности. Если посмотреть на мировую IT-индустрию, огромный вклад в ее развитие вносит именно Open Source.

В этой статье рассмотрим ряд бесплатных инструментов, которые можно применять для анализа безопасности сайтов на «1С-Битрикс» и Bitrix24 и других веб-приложений. В конце немного расскажу про BitrixProbe, который начал создавать и пользоваться недавно для себя как дополнение к сканированию коммерческим VM.

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

Когда говорят про DWH, чаще всего обсуждают управленческую отчетность, BI-дашборды, витрины данных и красивые графики для руководителей.

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

В процессе кастомизации коробочной CRM Битрикс24 часто клиенты просят внедрить им права доступа. Захотелось внедрить с интерфейсом, как это выглядит в Задачах или Сделках. Изучил документацию — там всё изложено лишь в общем виде, пришлось анализировать исходники, сжечь несколько миллионов токенов различных нейронок, и даже после этого вникать в нюансы и дебажить код.

В статье подробно разбираются нюансы архитектуры компонента BX.UI.AccessRights.V2, подводные камни при внедрении в свой модуль (готовый репозиторий прилагается).

Финальная часть серии — про самое нервное в любом ecommerce-проекте: как включать новую архитектуру по частям, не устраивать «большой релиз» и не останавливать продажи. 

К этому моменту у нас уже есть SSO, события, наблюдаемость, быстрый каталог, корзина, цены, checkout, интеграции, Gateway и SDK. Теперь начинается самая чувствительная часть — включать все это в продакшен без большого релиза или остановки продаж.

Сложность — в процессе. Один модуль уже готов, второй еще нет, часть трафика ходит по старому пути, часть — по новому… Поэтому я сделала практическую схему постепенного включения: фича-флаги, канареечный трафик, двойное чтение, shadow-режим и критерии готовности.

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

Привет, Хабр!

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. 

Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки.

Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов.

Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками.

Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.

Привет, Хабр! Это снова Алиса из KISLOROD. В прошлых частях мы вынесли из Битрикса каталог, корзину, цены и чекаут. Но в любом ecommerce-проекте есть еще одна зона турбулентности — интеграции.

Платежки, ERP, CRM, доставки, SMS, веб-хуки — все это любит тормозить, дублировать запросы и внезапно падать в самый неподходящий момент. Если держать такие вызовы внутри чекаута или админки, проект быстро начинает жить по SLA внешних сервисов.

В этой части разбираем Integration Hub: очереди, веб-хуки, DLQ, идемпотентность и отдельный контур для интеграций, который не блокирует пользователей и не тянет за собой весь чекаут.

Привет, Хабр! Это снова Алиса из сериала про Laravel рядом с Битриксом.  В первой части мы аккуратно подселили Laravel к Битриксу. Во второй — растащили события, авторизацию и тяжелую логику по нормальным сервисам, а в третьей — перестали мучить каталог SQL-запросами и отдали поиск OpenSearch.

Теперь добрались до места, где любой e-commerce начинает показывать характер: корзина и расчет заказа. Это каталог может тормозить незаметно. А вот если корзина начинает чудить — это уже чувствует бюджет.

В прошлой статье про AI-native организации я писал, что AI-native — это не компания, в которой всем выдали доступ к LLM и поставили несколько ботов в мессенджер. Ключевой переход начинается когда компания умеет описывать свою работу так, чтобы ее можно было исполнять, проверять, передавать по маршруту и постепенно делегировать отдельные шаги AI-агентам.

Эта статья — про один из таких практических шагов. Я хочу рассказать, как мы у себя в компании автоматизировали процессное управление на базе BPMN 2.0 моделей, Camunda и Битрикс24 и получили операционный контур, в котором процесс — это не регламент и не картинка BPMN, а исполняемый маршрут с задачами, контекстом, переменными процесса и передачей контекста между шагами.

Если вы разрабатываете на Битрикс24 и поддерживаете несколько окружений — тест, стейдж, прод — вы знаете эту боль. Настроил воронку, добавил пользовательские поля, написал робота с десятком условий, всё это поправил в карточке, назначил права. А потом нужно повторить то же самое на проде. Руками. Забыв половину.

Конфигурация CRM — это не код. Она живёт в базе данных, не попадает в git, и нет адекватного механизма переноса между окружениями. При этом объём этой конфигурации на реальных проектах значительный: десятки смарт-процессов, сотни пользовательских полей, сложные роботы с условиями, матрицы прав доступа, кастомные виды карточек. Всё это нужно как-то синхронизировать.

В Битрикс24 есть разрозненные инструменты для переноса отдельных частей настроек — штатный экспорт некоторых сущностей через интерфейс, партнёрские модули, закрывающие часть задач. Но каждый работает по-своему, покрывает свой кусок, и ни один не даёт того, что нужно на реальном проекте: полного покрытия CRM-конфигурации в одном инструменте, версионируемого вместе с кодом.

Мы прошли этот путь и в итоге написали набор Version Builder'ов для модуля sprint.migration, покрывающих основные сущности CRM Битрикс24. В этой статье — о самой задаче, подходе и подводных камнях.

Пишите в личку по вопросам.

Bitrix24 и amoCRM — две доминирующие CRM в России — отправляют email принципиально разным образом, но имеют общую проблему: ни одна из них не показывает, дошло ли письмо до инбокса получателя. Зелёный статус «Письмо отправлено» в карточке сделки означает только то, что SMTP‑сервер получателя принял письмо. Куда оно легло у клиента — спам, входящие, промоакции — CRM не знает.

В статье:

На первый взгляд миграция из Kaiten в Bitrix24 выглядит как обычная интеграционная задача: прочитать данные из одного REST API и записать в другой REST API.

Но это впечатление быстро проходит, когда начинаешь переносить не демо-доску, а живую проектную систему.

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

В нашем случае нужно было перенести данные из облачного Kaiten в коробочный Bitrix24 так, чтобы команда смогла продолжить работу уже в новом контуре: с группами, задачами, файлами, комментариями, правами доступа и понятной структурой.

В этой статье расскажу, как мы построили мигратор на Python, где помог асинхронный подход, почему маппинг ID оказался центральной частью архитектуры, какие ограничения обнаружились в коробочном Bitrix24 и почему часть задач пришлось решать не только через REST API, но и через отдельные серверные скрипты.

Репозиторий с кодом: https://github.com/vlikhobabin/kaiten-to-bitrix