Привет! Меня зовут Максим Месилов, я один из мейнтейнеров BITRIX24 PHP SDK.
У Битрикс24 большой REST API: через него разработчики подключают внешние сервисы, работают с CRM и создают приложения для Marketplace.
С API можно работать напрямую, но тогда появляется повторяющаяся техническая работа: авторизация, вызовы методов и обработка ответов. Каждый раз писать это заново неудобно, поэтому вокруг API постепенно появился PHP SDK — библиотека, которая берёт на себя базовую работу с платформой и даёт разработчику привычный интерфейс на PHP.
Сегодня рассказываю, как PHP SDK для Битрикс24 вырос из pet-проекта в официальный инструмент, зачем он нужен в эпоху AI-кодинга и почему SDK становится нижним слоем для разработки приложений и интеграций вокруг Битрикс24.
Официальный репозиторий PHP SDK здесь: github.com/bitrix24/b24phpsdk
Как и зачем начали создавать SDK
PHP SDK для Битрикс24 начинался как pet-проект. У разработчиков уже был базовый набор инструментов для работы с API: REST API Битрикс24 и CRest. Этого хватало, чтобы отправлять запросы и получать ответы, но для разработки больших интеграций хотелось более удобного уровня абстракции.
В каждом проекте разработчику приходилось заново решать одни и те же технические задачи транспортного слоя: авторизоваться, вызывать методы API, обрабатывать ответы и ошибки, приводить данные к нужным типам, работать с batch-запросами. Эти повторяющиеся операции и стали тем слоем, который хотелось вынести в общую библиотеку. Чтобы упростить себе работу, разработчику нужно вынести повторяющийся транспортный слой в общую библиотеку.
Выглядит это так: подключение к порталу занимает одну строку.
<?php declare(strict_types=1); use Bitrix24\SDK\Services\ServiceBuilderFactory; require_once 'vendor/autoload.php'; $b24 = ServiceBuilderFactory::createServiceBuilderFromWebhook('INSERT_HERE_YOUR_WEBHOOK_URL'); $deal = $b24->getCRMScope()->deal()->get(134)->deal(); echo $deal->TITLE; // string echo $deal->DATE_CREATE->format('d.m.Y'); // CarbonImmutable, а не строка из JSON
В статье примеры упрощены, но мы рекомендуем вам придерживаться базовых принципов:
ставьте PHP через docker;
секретные ключи передавайте через переменные окружения, не надо коммитить их в репозиторий с кодовой базой приложения
Цикл обучающих видео с пошаговыми инструкциями можно посмотреть в учебном курсе «REST API Битрикс24».
Хотя работать с библиотекой удобнее, чем с API напрямую, но такой транспортный слой редко даёт по-настоящему серьёзные преимущества. Получается, что разработчик просто работает с большим набором отдельных HTTP-ручек. Вместо этого важнее прикладная логика: автоматизация продаж, связь CRM с внешним сервисом, отчёты. А транспортный слой, в котором хранятся HTTP-запросы к API — это фундамент, на котором строится полезная бизнес-функциональность.
API-методы немного отличались от подсистемы к подсистеме по сигнатурам и полям, поэтому разработчик вынужден был каждый раз сверяться с документацией.
Так появилась идея SDK: закрыть этот технический транспортный слой готовой библиотекой. Разработчику не нужно каждый раз вручную собирать HTTP-запросы, разбирать JSON-ответы и повторно писать обработку ошибок. Вместо этого он работает с понятными PHP-классами и методами, которые отражают структуру API Битрикс24.
В чём была сложность: у Битрикс24 больше тысячи REST-методов, и их нужно аккуратно разложить по библиотеке.
Почему SDK пришлось писать вручную
В разработке SDK есть два основных подхода.
Первый подход: построить библиотеку на основе машиночитаемой спецификации API. Обычно для этого используют OpenAPI. Если вендор описывает методы, параметры и ответы в специальном формате, часть рутинной работы можно поручить кодогенерации: один и тот же API превращается в библиотеки для PHP, JavaScript, Python или других языков.
Но это возможно, если у API уже есть такая спецификация. В случае Битрикс24 на тот момент не существовало готовой OpenAPI-спецификации, поэтому автоматическая генерация SDK была невозможна.
Второй подход: создавать PHP SDK вручную. Это был более трудоёмкий подход, но он позволял двигаться вперёд без OpenAPI-спецификации. Я и ряд разработчиков это понимали, поэтому мы скооперировались вокруг того, чтобы сделать библиотеку, которая давала бы нам тот тулинг, который нам хотелось для языка PHP версии 7.4.
Как библиотека выросла из pet-проекта
Поначалу SDK развивался как обычный pet-проект: я периодически делал паузы в разработке, другие разработчики помогали с поддержкой, библиотека постепенно набирала пользователей.
Со временем проект стал заметен: репозиторий собрал 400 звёзд на GitHub, а на Packagist в пиковые периоды набиралось 120 установок в день. Некоторые старые проекты продолжают использовать эту зависимость.
В какой-то момент библиотека переросла уровень pet-проекта. Битрикс24 начал больше внимания уделять Developer Experience и DevRel, и SDK перенесли в namespace вендора и стали развивать уже как официальный инструмент для разработчиков.
Новая API 3.0, OpenAPI и системный релизный цикл
Позже PHP SDK вошёл в число участников Яндекс Open Source Code Jam — программы поддержки open-source-проектов. Для библиотеки это стало ещё одним шагом от личного pet-проекта к инструменту, которым пользуется сообщество.
Сейчас SDK развивается уже как часть более системной экосистемы. У Битрикс24 появилась новая версия REST API 3.0 с поддержкой OpenAPI-спецификации, а вместе с ней — третья версия PHP SDK. Мы стараемся развиваться регулярно и делать релизы раз в месяц.
Что вообще за версии?
REST-API развивался с момента публичного запуска Битрикс24 и накопился большой пласт легаси, в том числе по структурам данных которое отдает API. Вендор принял решение существенно обновить дизайн REST-API и поэтому сделали новую версию которая не совместима с текущей.
Ключевые улучшения:
единый формат ответа для всех методов,
получение связанных данных одним запросом,
повторный вызов без дублей по заголовку Idempotency-Key,
встроенная OpenAPI-документация.
Вот, как выглядят адреса эндпоинтов:— {portal}/rest/{user_id}/{token}/{method} для v1
— {portal}/rest/api/{user_id}/{token}/{method} для v3
Детальную информацию о методах v3 можно посмотреть в разделе «Обзор REST 3.0»
Ветка SDK v3 содержит новые методы и все старые, а ветка v1 только старые, поэтому, «по умолчанию» разработку имеет смысл вести на версии SDK 3.*
Покрытие API постепенно расширяется и сейчас дошло до 70%:
100%: imopenlines, booking, note, mail, documentgenerator, lists, biconnector, entity, imconnector
im -- 99%
sale 89%,
landing 85%,
catalog 72%,
humanresources 71%
crm 61% (102 непокрытых метода)
tasks 26%,
disk 42%,
timeman 44%,
rpa и vote -- 0%
Дополнительно в разработку SDK включились разработчики из сообщества, а мой фокус сместился с добавления методов на тулинг.
Главное, что сейчас у нас есть комьюнити PHP-разработчиков и понимание, что библиотека — это просто нижний слой. Поверх него появляются инструменты для жизненного цикла приложения, а ещё выше — стартеры, которые можно использовать как готовые шаблоны проектов. Задача всей этой конструкции — стандартизировать базовые уровни разработки, чтобы разработчик быстрее переходил к прикладной бизнес-логике.
Зачем SDK, когда есть AI-кодинг
С появлением AI-кодинга может показаться, что отдельный SDK уже не важен, потому что можно закинуть промпт в любую LLM, она сама напишет код для работы с REST-API и всё заработает с первого раза.
Для небольших нишевых сценариев это может сработать. Допустим, у вас есть 100 методов в REST API, а вы работаете только с тремя. С ИИ вам не нужно тащить зависимость в виде отдельной библиотеки на 100 методов. Вы просите агента сгенерировать код, который будет работать с 3 методами.
В более сложных проектах появляются проблемы. При работе нужно опираться на качественный уровень абстракции. То есть нельзя перепрыгнуть несколько уровней абстракции, если они недостаточно качественные и надежные. Ошибки всё равно будут, даже с развитыми ИИ-агентами. И если вы не используете качественные абстракции, все ваши наработки будут работать нестабильно.
Можно отлаживать код и исправлять ошибки. Но если у вас уже есть что-то отлаженное, то даже если это делали не вы, стоит это использовать. Просто потому, что это позволяет фокусироваться только на той части, которая вам нужна.
При этом все подходы имеют право на жизнь, одного правильного подхода нет. Хорошо, когда есть выбор, и каждый разработчик сам может принять решение: «я это использую» или «я это не использую».
Как именно будет в итоге и куда мы придём, пока неизвестно. Но надеемся, что это будет более хороший мир.
LLM и OpenSource
Кажется, что сейчас наступила золотая эра опенсорса: LLM ускорили доставку фич, массовые изменения, черновики PR, коммиты и рутинные проверки. Кодогенерация позволяет сделать 100500 фич или PR. Все счастливы? К сожалению, не совсем.
Агентная разработка позволяет прямо внутри процесса выполнения задачи сказать: «пойди оформи ишью и предложи PR», если у вас настроен MCP для Github, то агент все это сделает и мейнтейнер проекта получит волну slop-багрепортов\фиксов и будет вынужден начать их разбирать. Естественно, со своей стороны, он тоже может попросить LLM ему помочь. Ah Shit, Here We Go Again moment.
Мы приходим к тому, что приходится пересматривать весь пайплайн разработки и давать агентам возможность получить максимум обратной связи: линтеры, гайды, юнит и интеграционные тесты. Ответственность разработчика никуда не девается и вы как и прежде должны подумать перед мерджем предложенных изменений или добавлении функционала.
Работа maintainer не исчезает, но меняется фокус поддержки: документация, skills, инструкции, контекст для агентов, политики PR и прочие вещи которые раньше частенько выпадали из скоупа активностей разработчиков.
Главная польза SDK: типизация и предсказуемость
Один из главных плюсов SDK — типизация.
REST API возвращает данные в JSON: даты, цены и другие поля приходят как строки или числа, а разработчику дальше нужно самому приводить их к нужным типам.
В большом приложении такая ручная обработка быстро превращается в рутину. Если библиотека предоставляет удобный типизированный интерфейс, разработчику проще работать с такими вещами. Он может уже опираться на библиотеку и решать прикладные задачи не отвлекаясь на рутину.
Вариант 1 — ничего не делаем, возвращаем массив «как есть»
?Нет автокомплита полей на уровне IDE
✅Поддерживается любая вложенная структура данных
✅Нет затрат на создание и гидратацию подчиненных объектов
Разница видна на одной и той же задаче — получить сделку и посчитать, сколько дней она в работе.
Вариант 2 — делаем честные DTO
✅ Типизация
✅ Автокомплит полей на уровне IDE
✅ ? Для всех типов данных (deal, lead и т. д.) нужно делать объекты и потом поддерживать их
? Затраты на создание и гидратацию объекта или их коллекции в рантайме
Вариант 3 — Иммутабельный результат в виде «ленивого» DTO
✅ Типизация
✅ Автокомплит полей на уровне IDE на аннотациях phpdoc
✅ Поддерживается любая вложенная структура данных
✅ Ленивое создание и гидратация «по запросу»
Мы в SDK взяли лучшее от двух миров и получили lazy DTO.
Т.е. в рантайме у нас массив, а если идет обращение к полю, то мы его приводим к нужному типу данных.
Вот тот же ответ API до и после обращения к полю.
// то, что реально приходит от crm.deal.get — всё строками $raw = [ 'ID' => '134', 'TITLE' => 'Поставка станков', 'OPPORTUNITY' => '1250000.00', 'CURRENCY_ID' => 'RUB', 'CLOSED' => 'N', 'DATE_CREATE' => '2026-08-01T12:30:00+03:00', ];
Приведение типа происходит в момент обращения к полю: если из ста полей сделки нужно три, гидратация отработает по трём. Типы объявлены аннотациями @property-read, их читает typhoon/reflection — та же аннотация даёт и автокомплит в IDE.
<?php require_once DIR . '/crest.php'; $response = CRest::call('crm.deal.get', ['id' => 134]); // ошибку надо проверять руками на каждом вызове if (isset($response['error'])) { throw new RuntimeException($response['error_description'] ?? $response['error']); } $deal = $response['result']; // всё пришло строками, приводим типы сами $dealId = (int)$deal['ID']; $amount = (float)$deal['OPPORTUNITY']; // "1250000.00" $currency = $deal['CURRENCY_ID']; // "RUB" $isClosed = $deal['CLOSED'] === 'Y'; // надо помнить про Y/N $createdAt = new DateTimeImmutable($deal['DATE_CREATE']); $closeDate = new DateTimeImmutable($deal['CLOSEDATE']); $daysInWork = $createdAt->diff($closeDate)->days; // имена полей — просто строки: опечатку поймает только рантайм
Стало — на SDK:
<?php declare(strict_types=1); use Bitrix24\SDK\Core\Exceptions\BaseException; use Bitrix24\SDK\Services\ServiceBuilderFactory; require_once 'vendor/autoload.php'; $b24 = ServiceBuilderFactory::createServiceBuilderFromWebhook('INSERT_HERE_YOUR_WEBHOOK_URL'); try { $deal = $b24->getCRMScope()->deal()->get(134)->deal(); } catch (BaseException $baseException) { // ошибки API — типизированные исключения, а не разбор массива throw new RuntimeException('cannot read deal', previous: $baseException); } $dealId = $deal->ID; // int $currency = $deal->CURRENCY_ID; // Money\Currency $isClosed = $deal->CLOSED; // bool $createdAt = $deal->DATE_CREATE; // CarbonImmutable $daysInWork = (int)$deal->DATE_CREATE->diffInDays($deal->CLOSEDATE); // поля видит IDE: автокомплит и подсветка опечаток — до запуска
Результат иммутабельный — попытка записи роняет исключение:
$deal->TITLE = 'подмена'; // Bitrix24\SDK\Core\Exceptions\ImmutableResultViolationException
Деньги приходят объектом Money, поэтому арифметика не ломается на копейках:
$rows = $b24->getCRMScope()->dealProductRows()->get(134)->getProductRows(); foreach ($rows as $row) { $lineTotal = $row->PRICE->multiply($row->QUANTITY); // Money\Money echo $row->PRODUCT_NAME . ': ' . $lineTotal->getAmount() . ' ' . $lineTotal->getCurrency()->getCode(); }
Под капотом за приведение типов отвечает библиотека typhoon/reflection от Валентина Удальцова, сами типы выводятся из PHPDoc аннотаций.
Эффект масштаба и open-source-патчи
У SDK есть ещё один хороший эффект: исправления начинают работать на всех. Смотрите: если после обновления API что-то ломается, патч в библиотеку иногда приходит в этот же день. Потому что поломка коснулась всех, и чинят тоже все.
Если точнее, это работает так: когда разработчик использует собственную обёртку над API, он чинит проблему только у себя. Когда он использует общий SDK, исправление может попасть обратно в библиотеку, а затем помочь другим командам и партнёрам.
Тут есть спорное место с точки зрения бизнеса. По большей части разработчики библиотеки — сотрудники партнёров. Работа с API сама по себе редко становится уникальным преимуществом компании. Поэтому ее выгоднее стандартизировать на уровне общей библиотеки, а конкурировать уже выше — в качестве приложений и бизнес-логики.
Тем более, мы уже вроде как живем в том времени, когда «Coding is largely solved» by Boris Cherny ©
Ближайшие цели
Цель — довести покрытие API в SDK до 100% и синхронизировать развитие SDK с релизами самого API, чтобы библиотека быстрее догнала изменения на стороне платформы. Ещё мы хотим дать разработчикам более высокий уровень инструментов: слой хранения данных, обновленные стартеры, обвязку для работы с LLM.
Главная задача этих слоёв — создать разработчику надёжную основу. Если нижний уровень уже покрыт тестами, проходит статический анализ и регулярно поддерживается, на него можно опираться при разработке приложений.
Это удобно и для ИИ-разработки. Модель может быстрее писать прикладной код, если использует стабильную библиотеку, а не генерирует каждый раз заново работу с API. Находить и исправлять ошибки тоже проще, потому что проблемный участок находится внутри проверенного слоя.
Что ожидают разработчики от API и SDK
От SDK разработчики ждут привычного для современного PHP качества: соблюдения PSR-стандартов, понятной структуры, типизации, тестов и стабильной работы на реальных проектах.
Главное, что разработчики ожидают — хороший Developer Experience, и в этом главная задача библиотеки. Это означает, что разработчик должен:
Быстро находить нужные методы через автокомплит в IDE.
Видеть типы параметров и результатов.
Использовать готовые обёртки для типовых операций.
Понимать, как работать с библиотекой по документации.
Для больших проектов важна и производительность. SDK должен помогать работать с крупными объемами данных: например, выгружать сотни тысяч сделок и не создавать лишнюю нагрузку на портал. Поэтому библиотеке нужны тесты, проверки качества и опыт использования на разных проектах.
Что ожидают менеджеры
Для оплачивающего услуги разработчиков бизнеса в SDK важно другое: открытый исходный код и понятная лицензия. MIT-лицензия позволяет использовать библиотеку в коммерческих проектах без лишних лицензионных рисков.
Официальный SDK снижает совокупную стоимость владения. То есть вендор гарантирует, что SDK развивается параллельно с релизным циклом. А это значит, что партнёру не нужно тратить свои ресурсы на собственную обвязку вокруг интеграций.
Часть затрат остаётся: SDK нужно развивать, тестировать и поддерживать. Но эти затраты берёт на себя вендор, а разработчики и партнёры получают готовый инструмент, который можно использовать в проектах.
Слоёная архитектура SDK
Внутри PHP SDK устроен как слоёная архитектура:
На верхнем уровне находится приложение, которое работает с Битрикс24.
На среднем — сервисы, отражающие скоупы API: CRM, Диск, открытые линии.
На нижнем расположен core-слой. Через него можно вызывать произвольные методы API, даже если для них ещё не появилась отдельная удобная обёртка в сервисном слое. Это важно для большой платформы: API развивается быстрее, чем SDK успевает аккуратно обернуть каждый новый метод.
Если метод ещё не обёрнут сервисом, он всё равно доступен — через нижний слой, с той же обработкой ошибок и авторизацией.
$response = $b24->core->call('crm.item.list', [ 'entityTypeId' => 1036, 'filter' => ['stageId' => 'DT1036_10:NEW'], ]); $items = $response->getResponseData()->getResult(); // array $time = $response->getResponseData()->getTime(); // сколько API потратил на запрос
Это важный момент для большой платформы: покрытие сервисного слоя растёт постепенно,
но ни один метод API не оказывается недоступным — core-слой закрывает всё остальное.
В основании находятся HTTP-клиенты, которые отвечают за фактическую отправку запросов. При этом ответы API унифицированы: какой бы метод ни вызвал разработчик, нижний слой обрабатывает результат предсказуемым образом.
Сервисный слой как карта API
Самая ценная часть SDK — сервисный слой. Он превращает большую площадь REST API в набор понятных PHP-сервисов, с которыми разработчику проще работать в коде.
Сервисный слой — это проекция методов API на PHP-классы, которые позволяют разработчику говорить с вендором на одном языке. Если в Битрикс24 есть разделы CRM, Activity или Deal, то у разработчика в SDK они отражаются похожей структурой классов и папок. Так разработчик работает не с набором строковых REST-методов, а с понятной структурой сервисов, которая повторяет логику самой платформы.
Работа с большими объемами данных
Для интеграций с Битрикс24 иногда нужно получать очень много данных или записывать большие объемы данных. Для таких сценариев в SDK есть batch-режим и поддержка CRUD-операций через batch. Они помогают работать с большими наборами данных постепенно, не загружая все результаты в память сразу.
Постранично это выглядит так — и так это выглядит в SDK.
Было — ручная пагинация:
$start = 0; $deals = []; do { $response = CRest::call('crm.deal.list', [ 'order' => ['ID' => 'ASC'], 'filter' => ['>OPPORTUNITY' => 100000], 'select' => ['ID', 'TITLE', 'OPPORTUNITY'], 'start' => $start, ]); $deals = array_merge($deals, $response['result']); // всё копится в памяти $start = $response['next'] ?? null; } while ($start !== null);
Стало — генератор с постоянным потреблением памяти:
$dealsBatch = $b24->getCRMScope()->deal()->batch; foreach ($dealsBatch->list( order: ['ID' => 'ASC'], filter: ['>OPPORTUNITY' => 100000], select: ['ID', 'TITLE', 'OPPORTUNITY', 'DATE_CREATE'], limit: 500000 ) as $deal) { // сюда прилетают уже типизированные DealItemResult по одному // память не растёт с размером выборки echo $deal->ID . ' ' . $deal->TITLE . PHP_EOL; }
Запись работает так же — SDK сам нарежет массив на batch-пакеты:
$newDeals = []; for ($i = 1; $i <= 10000; $i++) { $newDeals[] = [ 'TITLE' => 'Сделка ' . $i, 'OPPORTUNITY' => 100000 + $i, 'CURRENCY_ID' => 'RUB', ]; } foreach ($dealsBatch->add($newDeals) as $addedDeal) { echo $addedDeal->getId() . PHP_EOL; // int, id созданной сделки }
В SDK также добавили поддержку событий для стабильной работы приложений: истечение срока действия токена авторизации и смену адреса портала. Два события, ради которых это сделано, — протухший токен и портал у которого в процессе работы сменили URL.
<?php declare(strict_types=1); use Bitrix24\SDK\Core\Credentials\ApplicationProfile; use Bitrix24\SDK\Core\Credentials\AuthToken; use Bitrix24\SDK\Events\AuthTokenRenewedEvent; use Bitrix24\SDK\Events\PortalDomainUrlChangedEvent; use Bitrix24\SDK\Services\ServiceBuilderFactory; use Symfony\Component\EventDispatcher\EventDispatcher; $eventDispatcher = new EventDispatcher(); // SDK сам обновит access token и сообщит об этом — остаётся сохранить его у себя $eventDispatcher->addListener( AuthTokenRenewedEvent::class, static function (AuthTokenRenewedEvent $event) use ($accountRepository): void { $accountRepository->saveToken($event->getRenewedToken()->authToken); } ); // портал сменил адрес — обновляем его в своей базе, интеграция не разваливается $eventDispatcher->addListener( PortalDomainUrlChangedEvent::class, static function (PortalDomainUrlChangedEvent $event) use ($accountRepository): void { $accountRepository->changeDomainUrl( $event->getOldDomainUrlHost(), $event->getNewDomainUrlHost() ); } ); $b24 = (new ServiceBuilderFactory($eventDispatcher, $logger))->init( new ApplicationProfile($clientId, $clientSecret, $scope), new AuthToken($accessToken, $refreshToken, $expires), 'https://your-portal.bitrix24.ru', 'https://oauth.bitrix.info' );
Ошибки API тоже разложены по типам, и это тот случай, когда catch пишется осмысленно:
use Bitrix24\SDK\Core\Exceptions\ItemNotFoundException; use Bitrix24\SDK\Core\Exceptions\MethodNotFoundException; use Bitrix24\SDK\Core\Exceptions\PaymentRequiredException; use Bitrix24\SDK\Core\Exceptions\QueryLimitExceededException; try { $deal = $b24->getCRMScope()->deal()->get(134)->deal(); } catch (ItemNotFoundException) { // сделки нет — штатная ветка бизнес-логики } catch (QueryLimitExceededException) { // упёрлись в лимит запросов портала — притормозить и повторить } catch (PaymentRequiredException) { // у портала закончился платный период } catch (MethodNotFoundException) { // метода нет на этом портале: редакция или отсутствующий скоуп }
Что дальше: SDK как основа для агентной разработки
Как выглядел процесс разработки до 2026 года
вендор релизит новые методы API + документацию к ним
-
ментейнеры релизят обновления в SDK на PHP, JS, Python
почитали доку
написали сервисы
сделали dto-объекты результатов работы сервисов
написали интеграционные тесты
собрали релиз
Что изменилось в 2026 году
опубликован MCP-сервер для работы с REST API Битрикс24
кодогенерация уходит в агентам
пробуем разные варианты ускорения процесса разработки
После нескольких экспериментов лучше всего на текущий момент зарекомендовала себя следующая конфигурация:
скилл мейнтейнера проекта;
-
детерминированная кодогенерация части файлов на основании метаданных из:
open api схемы, но к сожалению, она доступна только для api v3
документации к REST-API
реальным ответам от серверов.
написание интеграционных тестов для организации feedback loop по написанному коду.
Сейчас кодинговые агенты забрали значительный пласт рутинной работы.
Так мы освобождаем часть ресурсов и направляем их на более высокие уровни — адаптацию SDK для использования кодинг-агентами, готовые стартеры, скиллы и инструменты для разработки приложений под Битрикс24.
Так SDK становится нижним уровнем для агентной разработки. Разработчик может работать выше — формулировать прикладную задачу, собирать интеграцию или использовать стартер, где та же библиотека уже лежит под капотом.