Itecho ERP

Продуктовая логика Gigma

Gigma можно рассматривать как единый backend для коммерческих сценариев: витрины, сайты, каталоги, miniapp’ы и личные кабинеты подключаются к одному API, а Gigma держит клиентов, товары, заказы, оплаты, подписки, остатки и проектные границы.

Это не просто набор endpoint’ов. Продуктовая роль API — дать внешнему интерфейсу готовое commerce-ядро для базовых сценариев без отдельного commerce backend.

Короткая формулировка

Gigma — это единый commerce core: E-Commerce API для клиентских витрин и ERP API для внутренних операций над теми же товарами, заказами, оплатами и клиентами.

Через один backend можно подключить:

  • клиентскую авторизацию;
  • каталог товаров, услуг, тарифов, билетов и работ;
  • создание и пересчёт заказов;
  • оплату и подписки;
  • складские остатки и резервы;
  • промоакции и скидки;
  • личный кабинет клиента;
  • уведомления и интеграции во внешние системы.

Почему название ERP всё ещё релевантно

Название ERP допустимо для внутреннего продукта, потому что Gigma управляет операционной частью бизнеса: проектами, филиалами, пользователями, ролями, складами, номенклатурой, заказами и оплатами.

Но для внешнего позиционирования точнее говорить не только «ERP», а:

  • commerce API;
  • headless commerce backend;
  • commerce core для сайтов, витрин и miniapp’ов;
  • единый backend для заказов, оплат, подписок и клиентских сценариев.

ERP — это широкий зонтик. Commerce API — то, что быстрее понимает команда, которая подключает сайт или витрину.

Авторизация витрин как отдельная фича

Gigma удобно использовать как backend авторизации клиентов для внешних витрин.

Витрина не обязана хранить свою клиентскую базу и выпускать собственные токены. Она отправляет запросы в Gigma с токеном приложения, а Gigma определяет проект, создаёт или находит клиента и возвращает клиентский Counterparty token.

После этого фронт использует тот же клиентский токен для commerce-сценариев:

  • посмотреть текущего клиента;
  • создать заказ;
  • посмотреть историю заказов;
  • купить подписку;
  • выбрать способ оплаты или посмотреть платежи по подписке;
  • получить предварительный расчёт заказа;
  • работать с личным кабинетом.

Базовая модель доступа

В Gigma есть два разных контура авторизации.

КонтурДля когоЧто даёт
ERP Userсотрудники, менеджеры, владельцы бизнесадоступ к админке, настройкам, складам, заказам и управлению
Counterpartyклиент витрины, сайта или miniapp’адоступ к клиентскому API: заказы, профиль, подписки, платежи

Клиент внешней витрины не должен получать ERP User token. Для него используется только Counterparty token.

Как подключается внешняя витрина

  1. В ERP создаётся Application: конкретная витрина, сайт, лендинг или miniapp.
  2. Витрина передаёт application token в заголовке Token: {application_token} для app-scoped E-Commerce запросов и входа клиента.
  3. Gigma по application token понимает проект и доступный контекст витрины.
  4. Клиент проходит один из поддержанных способов входа.
  5. Gigma возвращает клиентский access token.
  6. Витрина передаёт клиентский token в заголовке Authorization.

Bearer token — строка доступа. Фронт отправляет её в заголовке:

Authorization: Bearer <client_access_token>

Точное поле ответа зависит от endpoint’а авторизации. У обычного login и miniapp contact auth это counterparty.access_token.value; у callback auth нужно смотреть поле access_token в ответе status endpoint.

Поддержанные способы входа клиента

На уровне продукта поддерживаются несколько способов получить клиентский токен:

  • вход по телефону или email через send_password и login;
  • callback auth через звонок;
  • miniapp contact auth по подписанному payload провайдера.

Для miniapp’ов важно: токен клиента выдаётся только после проверки подписи провайдера. Неподписанный телефон не должен быть достаточным основанием для входа.

Что обещает эта модель

  • Одна клиентская сущность внутри проекта: Counterparty.
  • Единые правила доступа для сайта, витрины, каталога и miniapp’а.
  • Проектные границы берутся с backend по Application, а не из тела запроса.
  • Деньги и итоговые суммы считаются на backend.
  • После авторизации клиент попадает в тот же commerce-контур, где уже живут заказы, подписки, оплаты и сохранённые расчёты.

Что не обещаем

Эта модель не означает, что Gigma уже закрывает любой возможный вид коммерции.

Отдельного проектирования всё ещё требуют:

  • маркетплейс с несколькими продавцами и сплит-платежами;
  • сложная логистика и доставка;
  • полноценная бухгалтерия и закрывающие документы;
  • POS-касса офлайн-точки;
  • B2B-договоры, лимиты, отсрочки и согласования;
  • вход по телефону без доказательства, что номер действительно принадлежит клиенту.

Правильная формулировка: Gigma уже является расширяемым commerce-ядром для витрин, заказов, оплат, подписок и клиентской авторизации.

Где смотреть API

© 2026 Itecho ERP