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, якщо треба ловити видалення.

Типові помилки інтеграцій