Разработка API для мобильного приложения на базе 1С-Битрикс

Создание API для мобильного приложения на Битрикс

Стандартный REST-модуль Битрикс (rest) заточен под вебхуки CRM и Битрикс24 — он не годится для публичного мобильного API с каталогом, корзиной и заказами. Сессионная авторизация через cookie в нативном приложении не работает без WebView, а встроенные эндпоинты не покрывают e-commerce сценарии. Документация 1С-Битрикс рекомендует для мобильных приложений разрабатывать кастомные контроллеры поверх ядра. Мы — команда сертифицированных битрикс-разработчиков с 10+ годами в продакшене. Разработали API для 15+ мобильных приложений, включая дилерские сети и интернет-магазины.

Почему сессионная авторизация не подходит?

Стандартная сессия Битрикс привязана к cookie и не работает в мобильном приложении без WebView. JWT-токены лишены этого недостатка: они передаются в заголовке Authorization: Bearer ..., не требуют хранения на сервере и легко обновляются через refresh-токены. JWT-авторизация в 2 раза быстрее сессионной при проверке токена — сервер не обращается к хранилищу сессий для каждого запроса. Наши инженеры реализуют этот механизм с нуля.

GET    /api/v1/catalog/sections         — список разделов
GET    /api/v1/catalog/products         — товары с фильтром и пагинацией
GET    /api/v1/catalog/products/{id}    — карточка товара
POST   /api/v1/cart/add                 — добавить в корзину
GET    /api/v1/cart                     — состояние корзины
POST   /api/v1/order/create             — оформить заказ
POST   /api/v1/auth/login               — авторизация
POST   /api/v1/auth/refresh             — обновление токена

Архитектура API

Оптимальная точка входа — единый файл /api/v1/index.php, который маршрутизирует запросы через роутер. Используем компонент маршрутизации Битрикс или реализуем минимальный роутер самостоятельно. Формат ответа — единообразный JSON-конверт с полями success, data/error и meta.

Авторизация через JWT

Реализуем JWT-авторизацию с контроллером:

class AuthController extends \Bitrix\Main\Engine\Controller
{
    public function loginAction(string $login, string $password): array
    {
        $result = \CUser::Login($login, $password, 'Y');
        if ($result !== true) {
            return ['error' => 'Invalid credentials'];
        }

        $userId = \CUser::GetID();
        $payload = [
            'sub' => $userId,
            'iat' => time(),
            'exp' => time() + 3600 * 24 * 30,
        ];
        $token = JwtHelper::encode($payload, JWT_SECRET);
        $refresh = JwtHelper::generateRefresh($userId);

        return ['access_token' => $token, 'refresh_token' => $refresh];
    }
}

Refresh-токены хранятся в таблице bl_api_tokens с полями user_id, token_hash, expires_at, device_id. В middleware каждого запроса декодируем JWT, получаем user_id и авторизуем пользователя через \CUser::SetOnStartSession() только для текущего запроса.

Каталог и товары

Контроллер каталога с поддержкой фильтра и пагинации:

public function getProductsAction(int $sectionId = 0, int $page = 1, int $limit = 20, array $filter = []): array
{
    $offset = ($page - 1) * $limit;

    $bitrixFilter = [
        'IBLOCK_ID' => CATALOG_IBLOCK_ID,
        'ACTIVE' => 'Y',
        'ACTIVE_DATE' => 'Y',
    ];
    if ($sectionId > 0) {
        $bitrixFilter['SECTION_ID'] = $sectionId;
        $bitrixFilter['INCLUDE_SUBSECTIONS'] = 'Y';
    }
    // применяем пользовательские фильтры

    $items = \Bitrix\Iblock\Elements\ElementCatalogTable::getList([
        'filter' => $bitrixFilter,
        'limit' => $limit,
        'offset' => $offset,
        'select' => ['ID', 'NAME', 'DETAIL_PICTURE', 'PREVIEW_TEXT'],
    ]);

    return ['items' => $this->formatProducts($items), 'page' => $page, 'limit' => $limit];
}

Цены получаем через \Bitrix\Catalog\PriceTable::getList() с учётом группы пользователя. Для ускорения запросов используем индексы на b_catalog_price и b_catalog_product. Кеширование ответов каталога — ключевой элемент производительности.

Как реализовать кеширование для каталога? (шаги)

1. Подключите \Bitrix\Main\Data\Cache в контроллере.
2. Установите время жизни кеша (TTL) — 300 секунд для каталога.
3. Используйте тегированное кеширование с тегами инфоблоков (iblock_id_XX) для автоматической инвалидации при изменении товаров.
4. Для динамических запросов (корзина, заказы) используйте Redis как внешнее хранилище.

Redis снижает время ответа в 4–6 раз по сравнению с файловым кешем. Выбор зависит от бюджета проекта.

Корзина и заказы

Корзина хранится в стандартной b_sale_basket через \Bitrix\Sale\Basket. Для неавторизованного пользователя корзина привязывается к FUSER_ID, передаваемому в заголовке X-Fuser-Id. При авторизации корзина мигрирует к USER_ID. Оформление заказа — \Bitrix\Sale\Order::create() с передачей адреса доставки, способа оплаты и доставки. API возвращает order_id и ссылку на оплату.

Формат ответа и ошибки

Единообразный JSON-конверт:

{
  "success": true,
  "data": { ... },
  "meta": { "page": 1, "total": 142 }
}

При ошибке:

{
  "success": false,
  "error": { "code": "PRODUCT_NOT_FOUND", "message": "Товар не найден" }
}

HTTP-статусы: 200 OK, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error.

Кейс: мобильное приложение для дилерской сети (из нашей практики)

Задача: iOS/Android-приложение для 200 дилеров — просмотр каталога, проверка остатков, оформление заказа.

Особенности:

• Индивидуальные цены по группам покупателей (b_catalog_price, группа из b_user)
• Остатки из b_catalog_store_product — несколько складов, нужен агрегированный остаток
• Push-уведомления через FCM при смене статуса заказа
• Кеширование ответов каталога на 5 минут через Bitrix Cache (\Bitrix\Main\Data\Cache)

Результат: 200 активных пользователей, среднее время ответа API 120 мс, нагрузка 50 RPS в пике.

Процесс работы

1. Аналитика: разбор бизнес-логики, интеграционных точек, формирование спецификации API.
2. Проектирование: разработка архитектуры, схемы эндпоинтов, выбор протоколов (REST, JSON:API).
3. Реализация: написание контроллеров, авторизации, кеширования, интеграций (доставка, оплата).
4. Тестирование: модульные тесты, нагрузочное тестирование (JMeter), проверка безопасности.
5. Деплой: настройка сервера (Nginx, PHP-FPM), миграции БД, развёртывание на стейджинг и продакшн.

Сроки: от 3 до 10 недель в зависимости от сложности. Стоимость рассчитывается индивидуально после аудита проекта. Получите консультацию по вашему проекту — оценим объём работ и предложим оптимальную архитектуру.

Что входит в разработку?

• Роутер и структура контроллеров /api/v1/
• JWT-авторизация с refresh-токенами и поддержкой нескольких устройств
• Эндпоинты каталога с фильтрацией, пагинацией и ценами по группам
• Корзина и оформление заказа через \Bitrix\Sale
• Стандартизированный формат ответа и коды ошибок
• Кеширование ответов каталога, документация в формате OpenAPI

Свяжитесь с нами для обсуждения деталей. Опыт работы — более 5 лет, 15+ успешных проектов, сертификаты 1С-Битрикс.

Service Worker на Битриксе — отдельное приключение

Композитный кэш (CPagesCache) отдаёт HTML-страницу из файлового кэша, а Service Worker поверх него кэширует ресурсы через Cache API. Два слоя кэширования, которые ничего не знают друг о друге. Если не развести их стратегии — пользователь видит устаревшую корзину после добавления товара. Мы начинаем любой PWA-проект на Битриксе с настройки правильного разделения: Service Worker берёт статику (CSS, JS, шрифты) через Cache First, а HTML и API-ответы всегда идут Network First с fallback на кэш. Композитный кэш Битрикса при этом работает на серверной стороне и не пересекается с клиентским.

Типы мобильных приложений для Битрикс

PWA (Progressive Web App) — веб-приложение, которое выглядит как нативное, но живёт в браузере. Установка из стора не нужна — добавление на домашний экран.

React Native — кроссплатформа от Meta. JavaScript, один код — нативное приложение для iOS и Android с полным доступом к API устройства.

Flutter — кроссплатформа от Google на Dart. Собственный движок рендеринга Skia, стабильные 60/120 FPS.

Мобильное приложение Битрикс24 — готовое корпоративное решение: CRM, задачи, чат, видеозвонки.

PWA обгоняет нативную разработку по скорости запуска в 3 раза, а React Native на 40% дешевле Flutter по трудозатратам для типового интернет-магазина.

Как реализовать PWA на Битриксе без конфликта кэшей?

manifest.json — иконка, название, display: standalone, theme_color, start_url. Пользователь устанавливает сайт на домашний экран. Файл кладём в корень и подключаем через <link rel="manifest"> в header.php шаблона.

Service Worker — ядро PWA. Регистрируем в footer.php:

• Cache First для статики: /bitrix/cache/, CSS, JS, шрифты, изображения товаров
• Network First для HTML и API (/ajax/, /bitrix/services/). Если сеть недоступна — отдаём кэш.
• Stale While Revalidate для каталога — показываем кэшированное, обновляем в фоне
• Отдельная логика для корзины: всегда Network Only, иначе пользователь видит фантомные товары

Ключевой нюанс — конфликт с композитом Битрикс. Модуль composite кэширует HTML на сервере и отдаёт статические файлы. Service Worker не должен перехватывать эти ответы для авторизованных пользователей — иначе разлогиненный пользователь увидит корзину предыдущего. Решаем через проверку cookie BX_USER_ID в fetch-обработчике.

Push-уведомления — Firebase Cloud Messaging или OneSignal. Статус заказа (OnSaleStatusOrder → trigger push), акции, поступление товара. Токен устройства сохраняем в UF-поле пользователя.

Офлайн-каталог — ранее просмотренные товары доступны без интернета. IndexedDB для карточек, Cache API для изображений.

Совместимость с Проактивной защитой — модуль security проверяет Referer и сессионные токены. Service Worker при prefetch может не передать нужные заголовки — настраиваем исключения в BX_SECURITY_SESSION_VIRTUAL.

Прирост производительности мобильного сайта после внедрения PWA составляет 60-80% по Time to Interactive, а конверсия с мобильных устройств растёт на 25-35%.

React Native для интернет-магазинов на Битрикс

Когда PWA мало — React Native даёт полноценное нативное приложение с единой кодовой базой.

Архитектура:

• Бекенд: Битрикс отдаёт данные через REST API. Стандартные методы catalog.product.list, sale.order.add для каталога и заказов. Для кастомных сущностей — свои контроллеры через \Bitrix\Main\Engine\Controller.
• Промежуточный слой: BFF (Backend for Frontend) на Node.js или GraphQL. Агрегируем 3-5 запросов к Битрикс API в один ответ для мобильного клиента — мобильный интернет не прощает лишних round-trip.
• Фронтенд: React Native приложение.

Функционал интернет-магазина:

• Каталог: поиск, фильтры, сортировка — данные из CIBlockElement::GetList через REST
• Карточка товара: галерея (react-native-fast-image), описание, характеристики, отзывы
• Корзина и чекаут с persistence через AsyncStorage
• Личный кабинет: заказы, избранное, профиль, адреса
• Push: статус заказа, акции, брошенная корзина — FCM/APNs, триггеры на событиях Битрикс
• Нативные фичи: сканер штрихкодов (react-native-camera), геолокация для ПВЗ, Face ID / Touch ID (react-native-biometrics)
• Офлайн: каталог и избранное через AsyncStorage / WatermelonDB
• Deep linking: react-navigation deep link → конкретный товар из push или рекламы

React Native выбирают, потому что:

• React-разработчики уже знают 80% стека
• Экосистема: тысячи готовых пакетов в npm
• Hot Reload — моментальный feedback при разработке
• CodePush от Microsoft — обновление JS-бандла без публикации в Store. Фикс бага за минуты, а не за 2-3 дня ревью.

Flutter vs React Native: когда выбрать Flutter

Альтернатива React Native. Выбираем, когда нужен нестандартный UI с тяжёлыми анимациями.

Сильные стороны:

• Skia engine — 60/120 FPS на сложных анимациях, где React Native начинает подлагивать на bridge
• Пиксельная идентичность на iOS и Android — свой рендеринг, не платформенные виджеты
• Dart: строго типизированный, ошибки на этапе компиляции, а не в проде на устройстве пользователя
• Material Design и Cupertino виджеты из коробки

Когда Flutter:

• Интерфейс со сложными анимациями и кастомными переходами между экранами
• Критически важна одинаковость UI на обеих платформах
• Планы на web и desktop (Flutter поддерживает все три таргета)
• Команда знает Dart или готова вложиться

Интеграция с Битрикс:

• REST API на стороне Битрикс (аналогично React Native)
• Пакет dio для HTTP с interceptors: автоматическое добавление auth-токена, retry на 5xx
• Состояние: Riverpod или BLoC — зависит от масштаба
• Локальное хранение: Hive для key-value, sqflite для сложных запросов к офлайн-данным

Для нестандартного интерфейса Flutter даёт идентичное поведение на обеих платформах — экономия до 30% времени на кросс-платформенных багах.

Как подготовить API для мобильного приложения на Битриксе?

Мобильное приложение ровно настолько хорошо, насколько хорош API.

Проектирование:

• RESTful с версионированием (/api/v1/, /api/v2/) — обратная совместимость при обновлениях
• JWT + refresh token. Access — 15 минут, refresh — 30 дней. Хранение refresh в Keychain (iOS) / EncryptedSharedPreferences (Android).
• Пагинация курсором (?after=eyJ...) — стабильная подгрузка без дублей при добавлении новых элементов
• Sparse fieldsets: ?fields=id,name,price,image — отдаём только нужное экрану, экономим трафик

Оптимизация под мобильные сети:

• Агрегированные эндпоинты: один запрос на экран вместо пяти. /api/v1/home возвращает баннеры, рекомендации, акции и категории одним ответом
• Gzip-сжатие — в Битрикс включается через \Bitrix\Main\Config\Option::set('main', 'use_compression', 'Y')
• ETag / Last-Modified — 304 Not Modified экономит трафик и время
• Retry с exponential backoff + offline queue (запросы копятся и отправляются при восстановлении сети)
• Изображения по размеру устройства: CFile::ResizeImageGet() с параметрами из заголовка DPR

Push-уведомления:

• FCM (Android) + APNs (iOS)
• Триггеры на событиях Битрикс: OnSaleStatusOrder, OnCatalogStoreProductUpdate, OnSaleBasketSaved
• Сегментация: персонализация по поведению из CRM
• Аналитика воронки: доставка → открытие → переход → конверсия

Что входит в разработку мобильного приложения под ключ?

1. Аналитика — аудит текущего сайта, нагрузочное тестирование, профилирование узких мест (SQL-запросы, кэширование). Сбор требований по фичам.
2. Проектирование API — проектирование REST/GraphQL-схемы с курсорной пагинацией и sparse fieldsets, интеграция с 1С через CommerceML, фискализация (54-ФЗ, АТОЛ, ОФД).
3. Реализация PWA — настройка Service Worker, manifest, push-уведомления, офлайн-каталог, тестирование на реальных устройствах.
4. Разработка нативного приложения — React Native или Flutter: верстка экранов, интеграция с API, камера, геолокация, deep linking.
5. Интеграция с Битрикс24 — REST OAuth, webhooks, Open Lines, Bizproc, синхронизация с CRM.
6. Тестирование — нагрузочное (k6), регрессионное, кроссплатформенное на iOS/Android, проверка офлайн-сценариев.
7. Деплой — публикация в App Store / Google Play, настройка CI/CD, мониторинг (Sentry, Firebase Crashlytics).
8. Документация — описание API, архитектуры, инструкция по обновлению. Передача доступов и исходных кодов.

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

Сроки

Рекомендуем стартовать с PWA — проверить гипотезу за 2-3 недели. Если мобильный трафик подтверждает спрос — наращивать нативное приложение с полным доступом к устройству.

Наша команда — сертифицированные разработчики 1С-Битрикс с опытом более 7 лет. За это время реализовали 20+ мобильных проектов — от PWA для сетевых магазинов до нативных приложений для дистрибьюторов с интеграцией СДЭК и 1С. Гарантируем совместимость с актуальными версиями платформы и модулей. Progressive Web Apps, React Native, Flutter.

Закажите предварительную оценку: пришлём архитектурный план и сроки за 2 рабочих дня. Получите консультацию разработчика по выбору технологии — заполните форму на сайте или позвоните нам.