Введение

> СерверККМ V4 > REST API
Дата обновления: 12 июня 2026 г.

Для чего нужен HTTP API Сервера ККМ

РБ-Софт:Сервер ККМ 4.0 — служба, которая принимает команды печати и управления кассовой техникой от учётных систем (в первую очередь — конфигураций 1С) и выполняет их на подключённых ККТ.

HTTP API — основной способ интеграции «извне»: внешняя программа отправляет JSON-запросы на сервер, сервер ставит задание в очередь или выполняет его сразу и возвращает результат (фискальные реквизиты, статус ККТ, ошибки и т.д.).

Типовые сценарии:

регистрация и печать фискальных чеков (продажа, возврат, коррекция);
открытие/закрытие смены, X- и Z-отчёты;
внесение и изъятие наличных, работа с денежным ящиком;
нефискальная печать (слипы, рекламные шаблоны, картинки);
проверка кодов маркировки, фискализация, администрирование устройств.

Документация в этом разделе описывает REST API. Тексты запросов и ответов приведены по коллекции Postman «РБ-Софт-Сервер ККМ 4.0» — её можно использовать для быстрой проверки методов.

Базовый адрес и протокол

Базовый путь к веб-сервису:

/PrintService/api/v4

Сервис работает по протоколу HTTP. TCP-порт по умолчанию: 4398.

Пример базового URL:

http://localhost:4398/PrintService/api/v4

К конкретному методу добавляется путь, например: .../api/v4/check, .../api/v4/kkt/list.

Переменная {{HTTPRoot}} в примерах ниже соответствует этому базовому адресу (без завершающего слэша).

Связанные разделы документации

Авторизация — получение токена и управление пользователями API
Служебные — ping, версия, статус заданий
Администрирование — настройки службы и управление ККТ
Работа с ККМ — смены, чеки, касса, маркировка, очередь и др.

Как устроена документация

Каждый метод описан по одному шаблону:

Запрос — имя операции в коллекции Postman.
URL — путь относительно {{HTTPRoot}}; параметры в фигурных скобках ({device}, {id}) подставляются при вызове.
Параметры запроса — query-параметры для GET, DELETE и части POST (таблица: имя, обязательность, пример, описание).
Тело запроса — сначала пример JSON, затем таблицы полей (для POST, PUT и др.).
Тело ответа — успешный пример (200 OK) и блок «Примеры ошибок».

Синхронные и асинхронные операции

Часть методов имеет вариант .../async (печать чека, открытие смены, Z-отчёт и др.). Такой вызов сразу возвращает идентификатор задания, а выполнение идёт в очереди.

Для контроля используйте:

GET task/status?id={id} — статус задания;
GET queue, GET queue/task — очередь и отдельное задание.

Подробнее: раздел «Служебные», раздел «Очередь».

Общая структура ответа

Все методы (кроме отдельных служебных исключений) возвращают JSON:

Поле	Тип	Назначение
Result	зависит от метода	Полезная нагрузка ответа (при успехе)
Code	int	Код ошибки; `0` — успех
Description	string	Текстовое описание результата
Success	bool	Признак успешного выполнения

Успешный и ошибочный ответ

Успех: Code: 0, Success: true, в Result — данные операции.
Ошибка: Success: false, Code ≠ 0 (или ошибка внутри Result у внешних сервисов, например Честный Знак). Description содержит текст для пользователя или лога. Поле Result может отсутствовать.

В описании каждого метода приведены примеры успешного ответа (200 OK) и блок «Примеры ошибок» — из сохранённых ответов Postman или типовой шаблон, если отдельный пример в коллекции не задан.

Авторизация (кратко)

GET user/token — Basic Auth (логин/пароль из панели управления). В Result приходит tokenId.
Все остальные методы (кроме ping) — заголовок API KEY: поле api_key со значением токена.

Подробнее: раздел «Авторизация».