Gigma

Управление магазином из кода

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

Витрина при этом не меняется: она читает готовый каталог по App Token — см. обзор раздела и быстрый старт.

Ниже <employee_token> — Bearer сотрудника, полученный при входе; это серверный секрет, во фронтенд он не попадает.

1. Склад и приложение

Каталог собирается со складов, привязанных к приложению, и от настройки склада зависит цена на витрине. Склад и привязку готовят в интерфейсе платформы; что это меняет и как проверить — в разделе «Управление складом».

2. Товар

POST /api/nomenclatures HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Content-Type: application/json

{
	"name": "Кофе в зёрнах, 1 кг",
	"kind_id": 2,
	"category_id": 5,
	"price": "1290.00",
	"pieces_per_pack": 6
}

Обязательны только name и kind_id; для физического товара это 2, услуга — 1, значения берите из GET /api/nomenclature_kinds. category_id формально необязателен, но товар без категории витрина не покажет — это первая причина пустого каталога. pieces_per_pack нужен приложениям с оптовым режимом: количество в заказе должно быть кратно упаковке. Контракт — создание товара.

3. Цена и остаток на складе

POST /api/inventories HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Content-Type: application/json

{
	"nomenclature_id": 34786,
	"warehouse_id": 7,
	"price": "1290.00",
	"quantity": 40,
	"markup": 15,
	"discount": 10
}

Одна запись — это товар на конкретном складе с его ценой и количеством. Массовая заливка идёт через импорт: файлом накладной или массивом items[]. Контракт — создание остатка.

4. Категории и бренды витрины

POST /api/applications/12/categories HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Content-Type: application/json

{ "category_id": 5 }

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

5. Проверить витриной

GET /api/counterparty/products HTTP/1.1
Host: api.gigma.ru
Token: <application_token>
Accept: application/json

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

6. Заказы

GET /api/orders?order_status_id[]=1 HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <employee_token>
Accept: application/json

Заказ, созданный витриной, дальше ведут из платформы: список и карточка, состав заказа, файлы, история и заявка на возврат.

Смена статуса — исключение: PUT /api/orders/{id} принимает реквизиты заказа (менеджер, доставка, адрес, договор), но не статус. Проводить заказ по этапам можно только в интерфейсе платформы; в коде на это рассчитывать нельзя.

Все методы

ОбъектМетодыКонтракт
ТоварыGET/POST /api/nomenclatures, GET/PUT /api/nomenclatures/{id}, импорт и экспорт — /import и /exportкаталог
Остатки и ценыGET/POST /api/inventories, GET/PUT /api/inventories/{id}, загрузка файла — /api/inventories/uploadостатки
Складысписок, карточка и настройки склада — контракты на странице разделасклады
Витрина приложенияPUT /api/applications/{id}, POST /api/applications/{id}/categories и /brands, порядок — /up и /downприложения
ЗаказыGET /api/orders, GET /api/orders/{id}, POST /api/orders, PUT /api/orders/{id}, состав — /nomenclaturesзаказы
РезервыGET /api/tables/reservations; снимается удалением позиции заказа DELETE /api/orders/{order}/nomenclatures/{id}резервы

В карте только те операции, у которых есть описанный контракт. Ресурсы объявлены целиком, поэтому в backend отвечают и DELETE /api/nomenclatures/{id}, DELETE /api/inventories/{id} и плоский GET /api/warehouses — но их карточек в документации пока нет, а значит, нет их и в openapi.json. Пользуйтесь ими на свой риск и сверяйтесь с поведением стенда. Отдельно про остатки: InventoryController не подключает authorizeResource, поэтому чтение, правка и удаление находят запись по переданному id без проверки проекта. Устаревший id молча отдаст чужие цену и количество или изменит их — сверяйте id и не показывайте такой ответ клиенту как свой.

Что учесть

  • Статус заказа через API не меняется — контракт обновления его не принимает. Автоматизация «оплачен → собран → выдан» на API платформы сейчас не строится.
  • Удаления заказа в API нет: маршрут не объявлен, остаются создание, чтение и обновление реквизитов.
  • Складские правила — в своём разделе. Цена по настройке склада и свободный остаток разобраны в управлении складом.
  • Категория товара и категория витрины — разные вещи. Первая решает, попадёт ли товар в каталог; вторая — появится ли фильтр у клиента.

© 2026 Gigma