Syrve Server API

01Быстрый старт

Четыре шага, чтобы получить первые данные с сервера.

1. Посчитать SHA1 от пароля

Сервер принимает не пароль, а его SHA1-хеш в нижнем регистре hex.

# bash
printf "myPassword" | sha1sum

# PowerShell
$p   = "myPassword"
$sha = [System.Security.Cryptography.SHA1]::Create()
$h   = $sha.ComputeHash([Text.Encoding]::UTF8.GetBytes($p))
($h | ForEach-Object { $_.ToString("x2") }) -join ""

2. Получить токен

https://localhost:8080/resto/api/auth?login=admin&pass=2155245b2c002a1986d3f384af93be813537a476

# Ответ — просто строка:
b354d18c-3d3a-e1a6-c3b9-9ef7b5055318

3. Вызвать любой метод с key

https://localhost:8080/resto/api/corporation/departments?key=b354d18c-3d3a-e1a6-c3b9-9ef7b5055318

4. Обязательно выйти

Освобождает слот лицензии. Без этого следующая авторизация может упасть с ошибкой.

02Базовые принципы

Две ветки API

Ветки сосуществуют: одна интеграция спокойно пользуется обеими. Токен общий.

Как передавать токен

• параметром key=… в query-строке — работает всегда;
• cookie с именем key — с версии 4.3 сервер сам ставит эту cookie после /auth.

Создание и изменение сущностей

• Успешное создание → HTTP 201 Created.
• Успешное обновление → HTTP 200 OK.
• Отдельная сущность — XML-документ; список сущностей — XML-документ, корневой элемент которого содержит элементы-сущности.

Форматы дат

dd.MM.yyyy в v2 формально принимается, но не рекомендуется — используйте ISO.

03Авторизация и лицензионные слоты

В ответе: строка-токен. Её нужно передавать в каждом следующем запросе — как cookie key или как параметр key.

Завершает сессию и освобождает слот лицензии. Работает и с cookie key без параметра.

Время жизни сессии

Типовой таймаут — 1 час от входа или от последнего запроса. Обновление токена в REST API v1/v2 не реализовано, поэтому после 401 просто авторизуйтесь заново.

Права доступа

Права проверяются по пользователю, под которым вы вошли. Самые частые требования:

04Ошибки

Любой метод v1 или v2 вместо ожидаемого ответа может вернуть ошибку с телом text/plain.

Как читать тело ошибки

• Тело Content-Type: text/plain — это текст ошибки. Показывайте его при 409 и всегда пишите в собственный лог.
• Тело text/html — это не ошибка Syrve. Это сетевая проблема или ошибка конфигурации: опечатка в URL, сбой DNS, настройки прокси, «пустой» Tomcat без сервера RMS/Chain; реже — рестарт сервера.
• Текст может содержать обязательные переносы строк — выводите с white-space: pre-line.
• Текст не экранирован и может содержать опасные для HTML/JS/SQL символы. Экранируйте сами.
• Логи сервера (full.log, access.csv) содержат больше, чем видит клиент API, — в частности предупреждения уровня WARN.

Сколько слотов лицензии осталось

Возвращает количество свободных слотов для конкретного лицензионного модуля, например ?moduleId=28008806. Дату окончания лицензии этот метод не возвращает.

05Ограничения и советы

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

1. Запросы — строго последовательно. Следующий отправляйте только после того, как завершился предыдущий. Параллельные вызовы не поддерживаются.
2. Период — не больше месяца. Идеально — день или неделя.
3. Отключайте итоги. Если общие итоги в OLAP не нужны — build-summary=false. Для больших сетей true может подвесить сервер. С версии 9.1.2 значение по умолчанию и так false.
4. Не больше 7 полей в построении OLAP-отчёта.
5. Сначала демо-сервер. Проверяйте запросы на демо-стенде, а не на рабочем сервере клиента.
6. Тяжёлые поля — ночью. StartBalance.* и FinalBalance.* в OLAP суммируют всю таблицу проводок за всё время работы системы. Для остатков используйте отдельное API балансов (раздел 16).

06Ревизии и синхронизация

Почти каждый метод-«список» поддерживает параметр revisionFrom. Это главный механизм инкрементальной синхронизации: вместо того чтобы каждый раз тянуть весь справочник, вы забираете только то, что изменилось.

Правильный цикл синхронизации

1. Первый запрос: revisionFrom=-1 — получаете всё.
2. Из ответа запоминаете поле revision — это максимальная ревизия, доступная для выгрузки на момент запроса.
3. Следующий запрос: revisionFrom={сохранённая revision} — приходят только изменения.
4. Повторяете.

Поддержка revisionFrom в большинстве методов v1 появилась в версии 6.4, в методах v2 — с самого начала.

07Структура предприятия

Иерархия подразделений

Версия 3.9 · параметр revisionFrom с 6.4 · ответ: corporateItemDto

Поля corporateItemDto

Склады

Все склады торговых предприятий в виде corporateItemDto

Группы отделений и точки продаж

Версия 4.3 · ответ: groupDto

В группе отделений может быть несколько точек продаж, но главная касса (pointOfSaleDto/main = true) подключается только к одной. В Syrve Chain информация о кассе точки продаж (cashRegisterInfo) может отсутствовать.

Режим обслуживания группы — groupServiceMode: FAST_FOOD, TABLE_SERVICE, PETROLEUM.

Терминалы

Версия 4.3 · ответ: terminalDto (id, name, computerName, anonymous, groupInfo, restaurantSectionIds)

Обычно интересны только фронтовые терминалы. Они различаются по полю anonymous: у касс — false, у бэк-офисов и системных терминалов — true.

Поиск

Все code и name — регулярные выражения. Если передать просто строку, ищется любое ее вхождение с учетом регистра. Поиск заведения по коду имеет смысл преимущественно в Syrve Chain: в пределах одного RMS сущность типа DEPARTMENT только одна.

Настройки предприятия

Версия 6.2 · требуется право B_ADM

{ "vatAccounting": "VAT_INCLUDED_IN_PRICE" }

VAT_INCLUDED_IN_PRICE — НДС включен в закупочную цену; VAT_NOT_INCLUDED_IN_PRICE — не включен. Это определяет, как считать суммы в накладных.

08Справочники и счета

Универсальный метод справочников

Версия 5.0 · rootType можно передавать несколько раз

Параметры

Формат ответа

Дополнительные поля по типам

GET /resto/api/v2/entities/list?rootType=DiscountType&rootType=PaymentType&includeDeleted=false

[
  { "id":"97ab68db-…","rootType":"DiscountType","deleted":false,"code":null,"name":"Скидка 20%" },
  { "id":"09322f46-…","rootType":"PaymentType", "deleted":false,"code":"CASH","name":"Наличные" },
  { "id":"9e250341-…","rootType":"PaymentType", "deleted":false,"code":null,  "name":"Безналичный расчет" }
]

Только идентификаторы

Версия 9.1 · возвращает плоский массив GUID. Принимает includeDeleted и revisionFrom. Пример: /resto/api/v2/entities/Account/ids?includeDeleted=false&revisionFrom=10

Счета

Параметры: includeDeleted (с 5.4), revisionFrom (с 6.4)

Метод возвращает только справочную информацию: без балансов и без материально ответственных лиц. Балансы — в разделе 16.

09Номенклатура

Требуется право B_EN «Редактирование номенклатурных справочников» — и на чтение, и на запись.

Элементы номенклатуры

Версия 6.1

Основные поля

Модификатор — ChoiceBindingDto

Фасовка — ContainerDto

Создание элемента

Версия 6.1 · тело — JSON

Обязательные поля тела

Редактирование, удаление, восстановление

Тело — то же, что и для save, плюс id элемента. Параметры URL: overrideFastCode, overrideNomenclatureCode (оба по умолчанию false)

Тело: {"items":[{"id":"…"},{"id":"…"}]}. У restore есть параметр overrideNomenclatureCode (с 6.4): если артикул восстанавливаемого продукта совпадает с действующим, будет сгенерирован новый.

{
  "result": "SUCCESS",
  "errors": null,
  "response": [ { "id":"fcdf4324-…", "deleted":true, "name":"test API-6", … } ]
}

Номенклатурные группы

Версия 6.2 · параметры списка: includeDeleted, ids, parentIds, nums и codes (с 6.2.3), revisionFrom (с 6.4)

Поля ProductGroupDto повторяют поля продукта в части id, deleted, name, description, num, code, parent, плюс настройки отображения группы на кассе.

Пользовательские категории

Шкала и размеры

Версия 6.4 · шкала размеров и привязка размеров к продуктам

Изображения

GUID загруженного изображения подставляется в поле frontImageId элемента номенклатуры.

Быстрое меню

Требуется право B_QMENU

Быстрое меню состоит из трех страниц, каждая — сетка 3 × 8. В ячейке — либо элемент номенклатуры, либо группа.

10Технологические карты

Все техкарты за период

Инкрементально: только то, что изменилось после knownRevision

Дерево техкарты — с раскладкой полуфабрикатов

Свернутая («собранная») техкарта

Вхождение товара в блюдо

Версия 3.9 · обратный поиск: в какие блюда входит этот ингредиент

11Цены, приказы, расписания

Ценовые категории

Версия 7.8 · параметры списка: includeDeleted, id (список), revisionFrom

{
  "result": "SUCCESS",
  "errors": [],
  "response": [
    { "id":"95035a38-…", "name":"Доставка",  "deleted":false, "code":"3",
      "assignableManually":true,  "pricingStrategy":{ "type":"PERCENT", "percent":-5 } },
    { "id":"67a54111-…", "name":"Плюс 100 грн", "deleted":false, "code":"2",
      "assignableManually":false, "pricingStrategy":{ "type":"ABSOLUTE_VALUE", "delta":100 } }
  ],
  "revision": 187420
}

Приказы об изменении прейскуранта

Версия 7.8 · именно этим документом задаются цены продажи

MenuChangeDocumentDto

MenuChangeDocumentItemDto

Редактировать приказ можно только пока его статус NEW. Если id не задан — создается новый документ; если задан — редактируется существующий.

Расписания (периоды действия)

Версия 7.8 · параметры: includeDeleted, id (список), revisionFrom

{
  "id": "598ce53a-…",
  "name": "Рабочий обед",
  "deleted": false,
  "periods": [ { "begin":"16:00", "end":"17:00", "daysOfWeek":[1,2,3,4,5] } ]
}

12Складские документы

Документы разделены на два поколения: старые XML-методы /resto/api/documents/… и новые JSON-методы /resto/api/v2/documents/…. Новые появились в 7.9.3 и покрывают акты списания и внутренние перемещения.

Приходная накладная

Версия 3.9, редактирование с 5.2 · Content-Type: application/xml · тело: incomingInvoiceDto · ответ: documentValidationResult

Позиция накладной

<document>
  <items>
    <item>
      <num>1</num>
      <product>0F22AA60-E8AE-4C8E-80CD-F1E00B88FEC6</product>
      <supplierProduct>BF1DA0F2-B511-431E-BC7D-F2A68715054B</supplierProduct>
      <amount>3.00</amount>
      <actualAmount>3.00</actualAmount>
      <price>10.00</price>
      <sum>30.00</sum>
      <vatPercent>20.00</vatPercent>
      <store>1239d270-1bbe-f64f-b7ea-5f00518ef508</store>
    </item>
  </items>
  <documentNumber>dn-7</documentNumber>
  <dateIncoming>17.12.2025</dateIncoming>
  <useDefaultDocumentTime>true</useDefaultDocumentTime>
  <defaultStore>1239d270-1bbe-f64f-b7ea-5f00518ef508</defaultStore>
  <supplier>3F08E41C-AA25-4573-B1E0-60B3B8A09F6A</supplier>
  <dueDate>27.12.2025</dueDate>
</document>

Ответ — documentValidationResult

Расходная накладная

Версия 4.4 · Content-Type: application/xml · тело: outgoingInvoiceDto

Распроведение накладных

Версия 7.7 · тело — та же структура документа · ответ — documentValidationResult

Выгрузка накладных

Версия 5.4 · даты YYYY-MM-DD, обе включительно (время не учитывается) · supplierId можно повторять; без него возвращаются все накладные за период · revisionFrom с 6.4

Другие документы (XML)

Акт приготовления · версия 3.9 · поля: storeFrom, storeTo, dateIncoming, documentNumber, status, items[] с product, amount, amountUnit, containerId, num

Акт реализации · версия 3.9 · поля: accountToCode (по умолч. 5.01), revenueAccountCode (по умолч. 4.01), items[] с productId, storeId, amount, sum, discountSum

Возврат поставщику · версия 4.4 · ключевые поля: incomingInvoiceNumber и incomingInvoiceDate — исходная приходная накладная, counteragentId

<documentValidationResult>
    <valid>false</valid>
    <warning>false</warning>
    <errorMessage>Cannot find document of type INCOMING_INVOICE by number
                   'TAKT0001' and date '2016-05-01'</errorMessage>
</documentValidationResult>

Инвентаризация

Версия 5.1 · тело: incomingInventoryDto · ответ: incomingInventoryValidationResult

Версия 5.1 · тот же документ, но без проведения — сервер только считает расхождения и возвращает их

Это самая полезная пара методов для мобильного приложения инвентаризации: сначала check, показываете кладовщику расхождения, и только после подтверждения — import.

<incomingInventoryValidationResult>
    <valid>true</valid>
    <store><id>1239d270-…</id><code>1</code><name>Основной склад</name></store>
    <date>2016-07-03T00:26:00+03:00</date>
    <items>
        <item>
            <product><id>c6d6c2f2-…</id><code>00001</code><name>Товар</name></product>
            <expectedAmount>13.600000000</expectedAmount>
            <expectedSum>535.370000000</expectedSum>
            <actualAmount>29.450</actualAmount>
            <differenceAmount>15.850000000</differenceAmount>
            <differenceSum>623.930000000</differenceSum>
        </item>
    </items>
</incomingInventoryValidationResult>

В позиции передается productId, amountContainer (количество в фасовке) и, при необходимости, containerId и comment. Один и тот же товар можно указать несколько раз с разными фасовками — сервер просуммирует.

Акты списания (v2)

Версия 7.9.3 · JSON · параметры выборки: dateFrom и dateTo (обязательные, yyyy-MM-dd), status, revisionFrom

Обязательные поля при создании: dateIncoming, status, storeId, accountId и минимум одна позиция. В позиции обязательны productId и amount. Если documentNumber не задан — сгенерируется автоматически. Редактировать можно только документ со статусом NEW.

POST /resto/api/v2/documents/writeoff
{
  "dateIncoming": "2026-08-16T23:00",
  "status": "NEW",
  "comment": "Порча",
  "storeId":   "7954d76d-6177-402c-ba2a-cc0ff16486fa",
  "accountId": "8c46f55a-0698-4e3f-8703-8bb36b24e8ac",
  "items": [ { "productId": "50cedffc-04e9-aa79-016b-d1f9c56122e8", "amount": 1 } ]
}

Внутренние перемещения (v2)

Версия 7.9.3 · обязательные: dateIncoming, status, storeFromId, storeToId и минимум одна позиция

{
  "dateIncoming": "2026-08-15T06:00",
  "status": "NEW",
  "storeFromId": "05a407d4-d7c6-4bc2-a578-6ad5de99d468",
  "storeToId":   "370620fe-c789-46db-9d92-33bec29b82a3",
  "items": [
    { "productId": "ccdada6c-…", "amount": 5, "containerId": "e2e67737-…" },
    { "productId": "8972b757-…", "amount": 5, "containerId": "84d13550-…" }
  ]
}

В ответе на создание приходит конверт {"result":"SUCCESS","errors":[],"response":{…}} с заполненными num, measureUnitId и cost.

13Поставщики

Версия 3.9 · revisionFrom с 6.4 · ответ — структура employees (поставщик в Syrve — это разновидность контрагента)

Поиск по id не выполняется. Доступные поля:

Прайс-лист поставщика

Версия 3.9 · {code} — это код поставщика, не GUID · без параметра date возвращается последний прайс-лист

14Касса и кассовые смены

Список смен

Смена по идентификатору

Второй метод возвращает документ принятия кассовой смены

Платежи, внесения и изъятия за смену

Версия 5.4

Запись проводки — info

Рядом с info есть actualSum и originalSum: первая — сумма из документа закрытия смены (если он её скорректировал), вторая — сумма самой проводки. Аналогично editedPayAccountId и originalPayAccountId.

Типы внесений и изъятий

Требуется право B_APIO

Выполнить изъятие

Версия 6.0 · требуется право F_APIO · Content-Type: application/json;charset=UTF-8

{
  "payOutTypeId": "114c757f-bac4-422c-a184-0935923b60b8",
  "payOutDate":   "2026-08-13",
  "counteragent": "d244cb85-9115-4b4d-8e02-a4f7fdd8ec15",
  "departmentSumMap": { "372f68b4-8e7a-bae1-015f-0f9c638f000d": 4500.00 },
  "comment": "Аванс поставщику"
}

# Ответ
{ "result": "SUCCESS", "errors": null, "payOutSettings": { … } }

При ошибке result = ERROR, а errors содержит список объектов с кодом и текстом ошибки.

Платёжные ведомости

Версия 6.0 · даты yyyy-MM-dd, включительно · есть includeDeleted

Возвращает payrollId, dateFrom, dateTo, department, documentNumber, status (NEW/PROCESSED/DELETED), comment.

15Сотрудники

Список и поиск

Версия 4.0 · includeDeleted с 5.0 · revisionFrom с 6.4

Поиск работает по любому текстовому или булевому полю DTO — регулярным выражением: address, cardNumber, cellPhone, client, code, email, employee, firstName, lastName, login, mainRoleCode, middleName, name, note, phone, supplier. Без параметров возвращает всех активных.

В Syrve RMS byDepartment идентичен обычному списку; разница появляется только в Syrve Chain.

Создание и редактирование

Полная замена. Новый id → 201 Created. Существующий id → 200 OK и все поля перезаписываются: не указали необязательное поле — оно сбросится

Частичное обновление. Поля, не указанные в запросе, остаются без изменений. Content-Type: application/x-www-form-urlencoded

Создание нового сотрудника. Учитывается только код, переданный в теле PUT-запроса. employeeCode попадает в поле «Табельный номер»

Пустой ответ, если сотрудник удалён (или уже был удалён). Entity of class User not found by id — если GUID не существует

Ключевые поля employee

<r><entry><key>crm_id</key><value>18734</value></entry></r>

Должности

revisionFrom с 6.4

Оклады

Третий вариант — оклад на конкретную дату. Установка оклада — POST на /resto/api/employees/salary

Смены и расписания

Даты YYYY-MM-DD. withPaymentDetails=true добавляет расчёт оплаты. Есть варианты byDepartment/{code} (по коду подразделения) и department/{id} (по GUID), а также комбинация с byEmployee

Явки

Последний метод — доступность сотрудников (пожелания по графику)

Бригады официантов

assignments — назначения официантов в бригады

16Остатки и отчёты

Остатки на складах

Версия 5.2 · основной способ получить остатки — быстрый, в отличие от OLAP

GET /resto/api/v2/reports/balance/stores?timestamp=2026-08-18T23:10:10

[
  { "store":"657ded9f-…", "product":"f464e4d4-…", "amount":123,   "sum":64083 },
  { "store":"1239d270-…", "product":"c6d6c2f2-…", "amount":29.45, "sum":1159.3 }
]

amount — количественный остаток, sum — денежный, в гривнах.

Балансы по счетам и контрагентам

Версия 5.2 · параметры: timestamp (обязательный), account, counteragent, department — все можно повторять

[
  { "account":"657ded9f-…", "counteragent":null, "department":"ef9461e9-…", "sum":64083 },
  { "account":"8a11a460-…", "counteragent":null, "department":"ef9461e9-…", "sum":-50 }
]

Это готовый ответ на вопросы «сколько мы должны поставщику» и «сколько денег на счёте» на конкретный момент.

Складские отчёты

Версия 3.9 · ответ: storeReportItemDto

Список преднастроенных складских отчётов, сохранённых в бэк-офисе

Расход продуктов по продажам · параметры: department, dateFrom, dateTo, hourFrom, hourTo (по умолчанию -1 — всё время)

Отчёт по выручке · дополнительно: dishDetails (разбивка по блюдам, по умолч. false) и allRevenue (true — все типы оплат, false — только выручка)

План по выручке за день · department, dateFrom, dateTo

Отчёты по доставке

У всех методов этой группы общие параметры: department (код или GUID в формате department={code="005"}; без него — по всем подразделениям в Chain), dateFrom, dateTo (DD.MM.YYYY или YYYY-MM-DD).

Сводный отчёт: средний чек, количество блюд, количество заказов по дням. Дополнительный параметр writeoffAccounts — счета списания

Отчёт по курьерам. Целевые показатели: targetCommonTime (по умолч. 30 мин), targetOnTheWayTime, targetDoubledOrders, targetTripledOrders, targetTotalOrders. Тип метрики: AVERAGE, TARGET, MAXIMUM

Цикл заказа. Целевые: targetPizzaTime, targetCuttingTime, targetOnShelfTime, targetInRestaurantTime, targetOnTheWayTime, targetTotalTime

Получасовой детализированный отчёт

Отчёт по регионам: среднее время доставки, процент доставленных, максимум заказов за день

Лояльность: новые гости, заказов на гостя. Дополнительно metricType: AVERAGE, MINIMUM, MAXIMUM

17OLAP v1

Простая GET-версия OLAP: все поля передаются параметрами URL. Для новых интеграций рекомендуется v2 (раздел 18), но v1 удобен для быстрых проверок и разовых выгрузок.

Версия 3.9

https://localhost:8080/resto/api/reports/olap
  ?key=ec621550-afae-133e-80c8-76155db2b268
  &report=SALES&from=01.08.2026&to=18.08.2026
  &groupRow=WaiterName&groupRow=OpenTime
  &agr=fullSum&agr=OrderNum

Самые используемые поля отчёта «Продажи»

Самые используемые поля отчёта «Проводки»

Отчёты по доставке — поля

Группа Delivery.*: Delivery.Number номер доставки, Delivery.Courier курьер, Delivery.Address, Delivery.City, Delivery.Street, Delivery.Region район, Delivery.Phone, Delivery.Email, Delivery.CustomerName, Delivery.CustomerComment, Delivery.DeliveryComment, Delivery.MarketingSource реклама, Delivery.SourceKey источник, Delivery.CancelCause причина отмены, Delivery.ServiceType (PICKUP / COURIER), Delivery.ExpectedTime, Delivery.ActualTime, Delivery.SendTime, Delivery.CloseTime, Delivery.BillTime, Delivery.Delay опоздание в минутах, Delivery.WayDuration время в пути.

18OLAP v2

Рекомендуемая версия. Запрос — JSON в теле POST, а перечень доступных полей можно получить с самого сервера.

Какие поля доступны

Версия 4.1 · устаревшие (deprecated) поля не выводятся

"FieldName": {
  "name": "Название в бэк-офисе",
  "type": "MONEY",
  "aggregationAllowed": true,
  "groupingAllowed": false,
  "filteringAllowed": false,
  "tags": ["Оплата"]
}

Построение отчёта

Версия 4.1 · Content-type: application/json; charset=utf-8

{
  "reportType": "SALES",
  "buildSummary": false,
  "groupByRowFields": ["OpenDate.Typed", "DishName"],
  "groupByColFields": [],
  "aggregateFields":  ["DishDiscountSumInt", "DishAmountInt"],
  "filters": {
    "OpenDate.Typed": {
      "filterType": "DateRange",
      "periodType": "CUSTOM",
      "from": "2026-08-01T00:00:00.000",
      "to":   "2026-08-31T00:00:00.000"
    },
    "OrderDeleted": { "filterType": "IncludeValues", "values": ["NOT_DELETED"] }
  }
}

Фильтр по значению

Для полей типа ENUM и STRING.

"DeletedWithWriteoff": {
  "filterType": "ExcludeValues",
  "values": ["DELETED_WITH_WRITEOFF", "DELETED_WITHOUT_WRITEOFF"]
}

IncludeValues — берутся только перечисленные значения; ExcludeValues — все, кроме перечисленных.

Фильтр по диапазону

Для INTEGER, PERCENT, AMOUNT, MONEY.

"SessionNum": { "filterType": "Range", "from": 758, "to": 760, "includeHigh": true }

includeLow по умолчанию true, includeHigh — false.

Фильтр по дате

"OpenDate.Typed": {
  "filterType": "DateRange",
  "periodType": "CUSTOM",
  "from": "2026-08-01T00:00:00.000",
  "to":   "2026-08-03T00:00:00.000",
  "includeLow": true,
  "includeHigh": false
}

Для всех типов, кроме CUSTOM, остальные параметры игнорируются — кроме from: его передавать обязательно, значение может быть любым.

Структура ответа

{
  "data": [
    { "OpenDate.Typed":"2026-08-01", "DishName":"Борщ",
      "DishDiscountSumInt":2450.00, "DishAmountInt":35 }
  ],
  "summary": [
    [ {}, { "DishDiscountSumInt":184300.00, "DishAmountInt":2610 } ],
    [ { "OpenDate.Typed":"2026-08-01" },
      { "DishDiscountSumInt":6120.00, "DishAmountInt":88 } ]
  ]
}

• data — линейные данные отчёта, по строке на запись. Одна запись = одна строка в гриде бэк-офиса.
• summary — список блоков из двух структур. Первая — поля группировки, по которым собран промежуточный итог (пустая — это общий итог по отчёту). Вторая — сами итоги по полям агрегации.
• При buildSummary: false массив summary будет пустым.

Преднастроенные отчёты

Версия 4.2 · presetType: stock, sales, transactions, deliveries

19Журнал событий

Нужны: лицензионный модуль 2200 (он же API_EVENTS(2200), «iikoAPI (ApiEvents)») и право B_VTJ «Просматривать журнал событий».

Список событий

Версия 3.9 · ответ: eventsList

В штатном режиме одно и то же событие повторно с разными ревизиями не приходит, но гарантии этого нет. GUID события уникален — используйте его как ключ дедупликации.

Фильтр по типам событий и номерам заказов

Версия 5.0 · тело application/xml

<eventsRequestData>
  <events>
    <event>orderCancelPrecheque</event>
    <event>orderPaid</event>
  </events>
  <orderNums>
    <orderNum>175658</orderNum>
  </orderNums>
</eventsRequestData>

Дерево типов событий

Версия 3.9 (GET) и 5.0 (POST с фильтром) · ответ: groupsList

Возвращает иерархию событий — аналог дерева журнала событий в бэк-офисе. Поле <id> группы или типа — это то, что вы подставляете в <type> события. Структура также определяет список атрибутов, специфичных для каждого события, и severity (0 — низкая, 1 — средняя, 2 — высокая).

Запись собственных событий

Версия 8.0.3 · тело — eventsList

<eventsList>
  <event>
    <date>2026-08-28T19:24:29.033+03:00</date>
    <type>externalDelivery</type>
    <departmentId>2</departmentId>
    <attribute>
      <name>userName</name><value>Администратор</value>
      <type>java.lang.String</type>
    </attribute>
    <attribute>
      <name>success</name><value>1</value>
      <type>java.lang.Boolean</type>
    </attribute>
  </event>
</eventsList>

Тип события может быть любой строкой до 255 символов. Но если этот тип зарегистрирован в events.xml, событие должно содержать все обязательные для него атрибуты.

Кассовые смены из журнала событий

Версия 5.0 · время открытия и закрытия, менеджер, номер смены, номер кассы, операционный день

20Репликация

Методы имеют смысл только на Syrve Chain. На отдельном RMS первые два вернут ошибку.

Версия 5.0 · список статусов последних репликаций всех подключённых к Chain серверов RMS

Статус репликации конкретного заведения. Ошибка, если в Chain нет заведения с таким GUID

Тип сервера: CHAIN, REPLICATED_RMS, STANDALONE_RMS. Работает везде — удобно как первая проверка того, с чем вы вообще соединились

21Коды базовых типов

Эти строковые константы используются и в параметрах запросов, и в ответах, и как значения enum-фильтров в OLAP. Переводу не подлежат.

Типы документов

Типы проводок

Счета

Номенклатура и контрагенты

Заказы и оплаты

22Готовые рецепты

PowerShell: авторизация, запрос, выход

$host_   = "https://localhost:8080"
$login   = "admin"
$passRaw = "myPassword"

function Get-Sha1Hex([string]$s) {
  $sha = [System.Security.Cryptography.SHA1]::Create()
  $b   = $sha.ComputeHash([Text.Encoding]::UTF8.GetBytes($s))
  ($b | ForEach-Object { $_.ToString("x2") }) -join ""
}

$pass  = Get-Sha1Hex $passRaw
$key   = Invoke-RestMethod "$host_/resto/api/auth?login=$login&pass=$pass"

try {
  # Остатки на складах на текущий момент
  $ts   = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ss")
  $bal  = Invoke-RestMethod "$host_/resto/api/v2/reports/balance/stores?key=$key&timestamp=$ts"
  $bal | Select-Object -First 10 | Format-Table store, product, amount, sum
}
finally {
  # Освобождаем слот лицензии, даже если запрос упал
  Invoke-RestMethod "$host_/resto/api/logout?key=$key" | Out-Null
}

curl: OLAP v2 с фильтром по дате

KEY=$(curl -s "https://localhost:8080/resto/api/auth?login=admin&pass=$SHA1")

curl -s -X POST "https://localhost:8080/resto/api/v2/reports/olap?key=$KEY" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "reportType": "SALES",
    "buildSummary": false,
    "groupByRowFields": ["OpenDate.Typed","DishName"],
    "aggregateFields":  ["DishDiscountSumInt","DishAmountInt"],
    "filters": {
      "OpenDate.Typed": {
        "filterType":"DateRange","periodType":"CUSTOM",
        "from":"2026-08-01T00:00:00.000","to":"2026-08-08T00:00:00.000"
      }
    }
  }'

curl -s "https://localhost:8080/resto/api/logout?key=$KEY"

Инкрементальная синхронизация номенклатуры

# 1. Первый проход
GET /resto/api/v2/entities/products/list?key=…&revisionFrom=-1
# → сохраняем revision = 187420

# 2. Каждые N минут
GET /resto/api/v2/entities/products/list?key=…&revisionFrom=187420
# → приходят только изменённые; обновляем сохранённую revision

# 3. Удалённые элементы не исчезают — они приходят с deleted:true,
#    поэтому передавайте includeDeleted=true, если нужно отлавливать удаления.

Типичные ошибки интеграций