Как сделать приложение из сайта на Битрикс

Приложение из магазина на Битрикс — это отдельный клиентский интерфейс, который получает согласованные данные и выполняет операции через защищённый серверный слой. Копировать базу каталога в телефон и считать её вторым независимым магазином обычно неудобно: цены, остатки и статусы начнут расходиться. Сначала определите владельца каждого типа данных.

Оболочка сайта и интегрированное приложение — не одно и то же

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

Наличие API платформы Битрикс не означает, что у конкретного магазина уже готов безопасный публичный API для приложения. Требуется проверить версию, редакцию, модули, доработки и правила доступа. Административные ключи не встраивают в клиентскую сборку.

Составьте карту данных и операций

Для каждого поля нужен один согласованный источник. Например, 1С ведёт цены, Битрикс применяет правила витрины, приложение показывает результат для текущего покупателя. Это пример архитектуры, а не обязательный порядок для любого проекта.

Учебный пример: повтор B2B-заказа

Покупатель повторяет заказ из пяти строк. Одна позиция снята с продажи, для второй изменена упаковка, третья доступна только на другом складе. Приложение не должно молча перенести старый состав и стоимость. Сервер возвращает актуальный расчёт и причины изменений, покупатель подтверждает новый вариант.

В приёмке отдельно проверьте двойное нажатие «Оформить». Один и тот же повторяемый запрос не должен создавать два независимых заказа. При новом содержимом корзины правила уже другие: нельзя ошибочно принять новое обращение за технический дубль. Общая логика разобрана в карточке идемпотентности.

Как подготовить интеграцию

1. Зафиксируйте основной сценарий и источник каталога.
2. Опишите контракт API: поля, ошибки, права и версионирование.
3. Подготовьте стенд и обезличенные контрольные данные.
4. Проверьте авторизацию и запрет доступа к чужим заказам.
5. Пройдите весь путь от выбора варианта до обновления статуса.
6. Согласуйте журнал ошибок, повторную доставку и порядок сопровождения.

Платёжные данные и секреты остаются в предназначенных для них системах. Наличие HTTPS не заменяет проверки полномочий. Событие «заказ принят» также нельзя показывать только на основании анимации кнопки: нужно подтверждение сервера.

Ссылки и переходы между каналами

Покупатель может открыть товар из письма или уведомления. Документация Android по deep links помогает отделить обычную ссылку от подтверждённого перехода в приложение. Для проекта согласуйте поведение при установленном клиенте, без установки и после входа в аккаунт.

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

Проверка интеграции до публикации

Разберите расчёт корзины как отдельный контракт

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

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

Учтите разные версии клиента

Сайт можно обновить централизованно, а часть покупателей продолжит пользоваться прежней сборкой приложения. При изменении API нужно определить совместимость, понятное сообщение и способ восстановления работы. Не удаляйте используемое поле только потому, что новая версия клиента уже опубликована.

Приёмка включает доступный старый сценарий и ожидаемый отказ для неподдерживаемого. Если сервер не может выполнить действие, пользователь должен понять, принят ли заказ и требуется ли повтор. Без этого обычное обновление превращается в источник повторных заявок и обращений в поддержку.

Зафиксируйте эксплуатационную проверку

В журнале достаточно технического идентификатора операции, времени, результата и безопасного описания причины. Пароли, платёжные секреты и полные персональные данные не нужны для обычного разбора ошибки. Уточните срок хранения и круг сотрудников, которые видят журнал.

После выпуска проверьте не только появление заказа в приложении, но и его дальнейший путь: смену статуса, изменение состава, отмену и возврат подтверждения. Если источник данных временно недоступен, согласованный порядок повтора должен сохранять смысл операции. Успешный экран клиента без подтверждённого состояния в учётной системе не является законченной интеграцией.

Ошибки, которые дороже исправлять после запуска

• Хранить администраторский токен внутри приложения.
• Вести два независимых справочника клиентов.
• Доверять присланной с телефона итоговой цене без серверного расчёта.
• Не учитывать старую версию клиента после изменения API.
• Проверять обмен только на одном доступном товаре.

Частые вопросы

Приложение обязано напрямую подключаться к 1С?

Нет. Источник и путь обмена выбирают под действующие процессы. Важно не создавать конкурирующие правила расчёта и не открывать учётную систему клиентским устройствам без необходимой защиты.

Можно сохранить текущий сайт?

Да, если его данные и операции подходят для общего использования. Сначала проводят диагностику API и каталога, затем оценивают необходимые доработки.

Как заказать оценку?

Для интеграции приложения с сайтом пришлите ссылку, описание обмена с 1С и нужные сценарии. Начальная стоимость — от 500 000 ₽; объём серверных работ фиксируется отдельно.