API для мобільного додатку на 1С-Бітрікс: повний гайд

Посібник: створення API для мобільного додатку на 1С-Бітрікс

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

Чому сесійна авторизація не підходить?

Стандартна сесія Бітрікс прив'язана до 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 дилерів — перегляд каталогу, перевірка залишків, оформлення замовлення. Наш клієнт — дилерська мережа з 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 (каталог+кошик+замовлення) — від $8,000, економія до 40% за рахунок повторного використання компонентів. Вартість розраховується індивідуально після аудиту проекту. Отримайте консультацію по вашому проекту — оцінимо об'єм робіт і запропонуємо оптимальну архітектуру. Для інтеграцій використовується Бітрікс24 REST API, а кешування API Бітрікс реалізується на Redis. Маємо 10+ років досвіду та 15+ реалізованих проектів.

Що входить в розробку?

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

Зв'яжіться з нами для обговорення деталей. Досвід роботи — понад 10 років, 15+ успішних проектів, сертифікати 1С-Бітрікс.