REST API Reference

REST API TIQQET — программный доступ ко всем функциям системы учёта заявок. Создавайте заявки из внешних систем мониторинга, синхронизируйте данные с 1С или CRM, стройте кастомные дашборды, автоматизируйте любые сценарии. Общая настройка — в документации, описание модулей — в функционале.

Мы спроектировали API так, чтобы типичная интеграция с внешней системой занимала часы, а не недели. REST-эндпоинты, стандартный JSON, предсказуемые коды ответов, понятные названия полей. Никаких XML-конвертов, SOAP или экзотических форматов — всё по канонам современных REST API. Поддержка версионирования через URL-префикс, обратная совместимость в рамках мажорной версии, чёткий changelog при каждом обновлении. Любой backend-разработчик начнёт писать интеграцию по этому референсу без дополнительных вводных.

Типичные сценарии использования API: автоматическое создание заявок из системы мониторинга (Zabbix, Prometheus Alertmanager, Nagios), регистрация обращений из корпоративного портала или мобильного приложения заказчика, двусторонняя синхронизация с CRM (Bitrix24, amoCRM), выгрузка данных для аналитики в BI-системы (Power BI, Superset, Metabase), создание персональных уведомлений через Telegram-ботов. Любой внешний процесс, который нужно связать с автоматизацией техподдержки, реализуется через API.

Авторизация

API использует JWT Bearer Token. Получите токен через эндпоинт авторизации и передавайте его в заголовке каждого запроса.

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
POST/api/auth/loginПолучение JWT-токена

Тело запроса:

{ "email": "sales@tiqqet.ru", "password": "your-password" }

Ответ:

{ "token": "eyJhbGciOiJIUzI1NiIs...", "user": { "id": 1, "name": "Иван Петров", "role": "OPERATOR" } }

Заявки

GET/api/ticketsСписок заявок

Параметры запроса:

ПараметрТипОписание
statusstringФильтр по статусу: NEW, IN_PROGRESS, WAITING, POSTPONED, DONE, CLOSED
prioritystringФильтр по приоритету: LOW, MEDIUM, HIGH, CRITICAL
assigneeIdnumberID исполнителя
serviceIdnumberID услуги
pagenumberНомер страницы (по умолчанию 1)
limitnumberКоличество на странице (по умолчанию 20)
POST/api/ticketsСоздание заявки
{ "subject": "Не работает принтер", "description": "Принтер HP в кабинете 305 не печатает", "priority": "MEDIUM", "serviceId": 3, "assigneeId": 5 }
GET/api/tickets/:idДетали заявки
PUT/api/tickets/:idОбновление заявки
POST/api/tickets/:id/commentsДобавить комментарий
{ "text": "Заменил картридж, проблема решена" }
PUT/api/tickets/:id/statusСмена статуса
{ "status": "DONE", "comment": "Проблема решена" }

Пользователи

GET/api/usersСписок пользователей
GET/api/users/:idДанные пользователя

Услуги

GET/api/servicesКаталог услуг

Оборудование

GET/api/equipmentСписок оборудования
GET/api/equipment/:idДетали оборудования
POST/api/equipment/qr/:codeПоиск по QR-коду

Аналитика

GET/api/dashboardДанные дашборда
GET/api/analytics/ticketsАналитика по заявкам
ПараметрТипОписание
fromdateНачало периода (ISO 8601)
todateКонец периода
groupBystringГруппировка: day, week, month
Rate limiting: API ограничен 100 запросами в минуту на токен. При превышении возвращается HTTP 429.

Коды ошибок

КодОписание
400Некорректный запрос — проверьте параметры
401Не авторизован — невалидный или просроченный токен
403Доступ запрещён — недостаточно прав
404Ресурс не найден
429Превышен лимит запросов
500Внутренняя ошибка сервера

Сценарии интеграции

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

Автоматическое создание заявок из мониторинга

Классический сценарий: когда Zabbix, Prometheus Alertmanager или Nagios фиксирует инцидент на сервере — заявка автоматически создаётся в TIQQET и попадает к дежурному инженеру. В Alertmanager настраивается webhook-приёмник, который вызывает POST /api/tickets с заранее прописанным шаблоном: тип INCIDENT, приоритет CRITICAL, услуга из каталога «Серверная инфраструктура», назначение на команду операторов. Комментарий с деталями алерта — хост, метрика, значение, timestamp. Когда алерт разрешается — тот же webhook переводит заявку в статус «Выполнена» через POST /api/tickets/:id/action с действием complete.

Двусторонняя синхронизация с CRM

Если клиенты компании обращаются через CRM (Bitrix24, amoCRM, Salesforce) и при этом ожидают контроля SLA — удобно проксировать обращения в TIQQET. Из CRM по webhook создаётся заявка в TIQQET с внешним идентификатором сделки/лида в extraFields. Когда оператор TIQQET меняет статус заявки — хук в обратную сторону обновляет карточку в CRM. Таким образом менеджер продаж видит в CRM актуальное состояние запроса клиента, а технические специалисты работают в привычной программе для техподдержки.

Выгрузка данных в BI-системы

Корпоративные BI-системы (Power BI, Superset, Metabase, Yandex DataLens) читают данные по расписанию. Эндпоинт GET /api/analytics отдаёт агрегированные данные за период в JSON, который легко импортируется в дашборды. Для сырых данных используется GET /api/tickets?limit=1000&from=2025-01-01 с пагинацией. Это позволяет строить корпоративные отчёты, сравнивать метрики сервисной службы с другими подразделениями, анализировать тренды.

Мобильное приложение заказчика

Компании, которые обслуживают конечных клиентов (управляющие компании, интернет-провайдеры, сервис-центры), часто имеют собственное приложение для клиентов. Через API они интегрируют приём обращений: клиент в приложении заполняет форму → она создаёт заявку в TIQQET через POST /api/tickets → клиент видит статус и комментарии оператора через GET /api/tickets/:id. Фактически — ваше приложение как фронтенд, TIQQET как бэкенд системы обработки обращений.

Telegram-уведомления для операторов

Простейшая автоматизация, которую операторы обожают: Telegram-бот на node-telegram-bot-api или aiogram, который раз в 30 секунд спрашивает GET /api/tickets?assignee=me&status=NEW_ASSIGNED и пушит новые заявки в чат. Оператор реагирует из мобильного в любой момент, не загружая полный интерфейс TIQQET. Нужно пометить заявку — одной командой в боте.

Импорт оборудования из 1С

Если учёт основных средств ведётся в 1С, а TIQQET используется для сервисного обслуживания — разовая или периодическая выгрузка списка единиц в TIQQET через POST /api/equipment. Серийный номер, инвентарный, локация, привязка к сотруднику. После этого операторы могут сразу начинать работу с актуальным справочником, не перенабирая тысячи позиций вручную.

Best practices для интеграций

Несколько практических рекомендаций, которые сэкономят вам время и нервы.

  • Используйте сервисные учётки, а не живых пользователей. Создайте в TIQQET отдельную учётную запись с ролью OPERATOR специально для интеграции (например, integration@company.ru). Токен этой учётки используйте в API. Если разработчик интеграции уйдёт — ничего не сломается.
  • Храните токены в секретах. Vault, AWS Secrets Manager, переменные окружения деплой-системы. Никогда не коммитьте токены в репозиторий. При компрометации — немедленно отзывайте через API, генерируйте новый.
  • Обрабатывайте ошибки правильно. HTTP 429 — ждите и повторяйте с экспоненциальным backoff. HTTP 5xx — логируйте, повторяйте. HTTP 4xx — не повторяйте, разбирайтесь с параметрами запроса.
  • Используйте идемпотентные операции. Если ваша интеграция создаёт заявки по внешним событиям — предусмотрите защиту от дублей: храните external_id на вашей стороне или ищите существующую заявку через GET /api/tickets?search=... перед созданием новой.
  • Логируйте на своей стороне. Сохраняйте тело запроса, ответа, timestamp — при расследовании инцидентов эти логи спасут часы времени.
  • Не опрашивайте слишком часто. 30–60 секунд между пулл-запросами обычно достаточно. Если нужна реальная реактивность — свяжитесь с нами по поводу webhooks, мы прорабатываем этот механизм для будущих версий.
  • Тестируйте на стейдж-окружении. Разверните отдельный инстанс TIQQET для тестов. Ломайте его как хотите. Продакшен трогайте только после того, как всё отлажено.

Планы развития API

API TIQQET развивается вместе с продуктом. В ближайших планах:

  • Webhooks — подписка на события (создание заявки, смена статуса, комментарий, нарушение SLA) с PUSH-доставкой на ваш endpoint. Позволит строить реактивные интеграции без поллинга.
  • GraphQL endpoint — для клиентов, которым нужна гибкая выборка данных с минимизацией объёма ответа. Будет сосуществовать с REST.
  • OpenAPI / Swagger-спецификация — автогенерация клиентов для популярных языков (Python, Go, Java, C#) и интерактивной документации.
  • Bulk-операции — создание, обновление нескольких заявок одним запросом для массовых импортов.
  • Расширенные фильтры в аналитике — группировки, pivot-таблицы, кастомные метрики.

Если вам нужна функциональность, которой пока нет в API — напишите на sales@tiqqet.ru. Мы приоритизируем развитие API исходя из реальных запросов клиентов. Часто нужная вам возможность уже в планах — просто ждёт голосов.

SDK и клиентские библиотеки

На текущий момент TIQQET не публикует официальные SDK — но с REST API легко работать напрямую из любого языка: встроенными HTTP-клиентами Python (requests), Node.js (fetch, axios), Go (net/http), Java (OkHttp, HttpClient), C# (HttpClient). Готовые примеры — в документации. Сообщество постепенно формирует wrapper-библиотеки — если вы написали свою и готовы поделиться, свяжитесь с нами, мы упомянем её в этой секции.

Мы используем файлы cookies и сервис Яндекс.Метрика для анализа посещаемости и улучшения качества сайта. Продолжая использование сайта, вы соглашаетесь с Политикой конфиденциальности.