Использование эндпоинтов скоринга
Обзор
Система предоставляет несколько типов эндпоинтов для получения скоринговых данных по ваучерам. Каждый эндпоинт оптимизирован для определенных сценариев использования. Правильный выбор эндпоинта позволяет получать данные в 10-100 раз быстрее и значительно снижает нагрузку на систему.
Основная проблема: Многие запрашивают данные за каждую смену отдельно через эндпоинт сырых данных, хотя для большинства задач достаточно агрегированных данных по дням. Это приводит к неоправданно долгому ожиданию результатов и перегрузке системы интеграции.
Сравнение эндпоинтов скоринга
| Эндпоинт | Тип данных | Назначение | Производительность | Масштабируемость |
|---|---|---|---|---|
| GetVoucherTable | Агрегаты + статусы | Обзор автопарка со статусами и аномалиями | ⚡ 1-5с | 1000+ ваучеров |
| GetStatisticSummingGlobalByVoucherId | Агрегаты | Превью-скоринг за все время | ⚡ 50-200мс | 1 ваучер |
| GetStatisticSummingMonthAllByVoucherId | Агрегаты | Данные по месяцам | ⚡ 200мс - 2с | 1 ваучер |
| GetStatisticSummingDayByVoucherId | Агрегаты | Данные по дням | ⚡ 100мс - 5с | 1 ваучер |
| GetStatisticSummingPeriodByVoucherId | Сырые поездки | Данные по произвольным периодам | ⚠️ 5с - 5мин | 1 ваучер |
Описание эндпоинтов
Обзор автопарка со статусами
GetVoucherTable - основной эндпоинт для получения комплексной информации по всему автопарку. Содержит превью-скоринг, статусы ваучеров, информацию об аномалиях устройств и активности ТС.
Когда использовать:
- Первичный запрос при работе с автопарком
- Общий обзор использования ТС для страховых отчетов
- Определение активных ваучеров перед запросом детальных данных
- Выявление проблемных ТС с критическими аномалиями
- Дашборды и отчеты по всему автопарку
⚠️ Важно: Рекомендуется сначала запросить и сохранить эту информацию на время сессии, чтобы избежать неэффективных запросов детальных данных по неактивным ваучерам или ТС с критическими аномалиями.
Превью-скоринг одного ваучера
GetStatisticSummingGlobalByVoucherId - самый быстрый способ получить общую оценку использования конкретного транспортного средства за все время. Возвращает готовые агрегированные показатели без детализации.
Когда использовать:
- Общий обзор использования ТС для страховых отчетов
- Детальная карточка конкретного автомобиля
- Быстрая оценка перед запросом детальных данных
Данные по месяцам
GetStatisticSummingMonthAllByVoucherId - предоставляет скоринговые данные с разбивкой по месяцам. Данные предварительно агрегированы для максимальной производительности.
Когда использовать:
- Долгосрочная аналитика (полгода, год и более)
- Сравнение сезонных показателей
- Отчеты для страховых компаний
- Анализ трендов по кварталам
Данные по дням
GetStatisticSummingDayByVoucherId - предоставляет скоринговые данные по дням (00:00 - 23:59 UTC), когда ТС использовалось. Работает по принципу пагинации записей в базе данных (skip/limit), а НЕ по календарным дням.
Почему skip/limit вместо календарных периодов
- Для агрегации данных используется колоночная СУБД (оптимизирована для аналитики)
- Система берет N записей подряд из индекса (мгновенно)
- Скоринг формируется в режиме батч-операции (несколько мс)
- Общее время: 100-300мс (в 100 раз быстрее, чем при обычном подходе)
Как это работает
1 день с данными = 1 запись в БД:
Система хранит только дни, когда ТС фактически использовалось. Дни без активности не сохраняются.
Календарь: [01.08] [02.08] [03.08] [04.08] [05.08]
Данные в БД: [01.08] - [03.08] - [05.08]
Позиции: [ 0 ] [ 1 ] [ 2 ]Логика параметров:
daysCount - сколько записей взять (LIMIT),
skipDaysCount - сколько записей пропустить с начала (OFFSET)
Пример:
Сегодня 05.08.2025, но последние данные в БД:
Позиции: [0] [1] [2]
Даты: [03.08] [01.08] [30.07]При skipDaysCount=1, daysCount=1 получите данные за 01.08, а не за "вчера" (04.08).
Данные по произвольным периодам
GetStatisticSummingPeriodByVoucherId - обрабатывает сырые данные поездок для получения данных за короткий временной период. Данные не агрегированы.
⚠️ Технические ограничения:
- Минимальный период: 1 час - скоринг требует достаточной экспозиции для корректного нормирования показателей. Короткие периоды не дают статистически значимых результатов.
- Обработка в реальном времени - система обрабатывает каждую поездку в цикле, что значительно медленнее батч-операций, используемых в агрегированных данных.
Когда использовать:
- Анализ конкретной смены с точными временными рамками
- Анализ периодов использования продолжительностью несколько часов
- Случаи, когда важны точные временные границы, не совпадающие с календарными днями
❌ Когда НЕ использовать:
- Регулярные ежедневные смены (используйте дневной эндпоинт)
- Долгосрочная аналитика (недели/месяцы)
- Отчеты для страховых компаний
- Периоды менее 1 часа активной езды
Разница в обработке данных
АГРЕГИРОВАННЫЕ ДАННЫЕ (батч-обработка):
┌─────────────────────────────────────────────────────────┐
│ Месяц данных: 1000 поездок │
├─────────────────────────────────────────────────────────┤
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌──────┐ │
│ │День1│ │День2│ │День3│ ... │День30│ ───────┐ │
│ └─────┘ └─────┘ └─────┘ └──────┘ │ │
└─────────────────────────────────────────────┼───────────┘
│
┌─────────────────────────▼─────────────────────────┐
│ БАТЧ-ОПЕРАЦИЯ │
│ • Все данные обрабатываются одним батчем │
│ • Предрассчитанные агрегаты │
│ ⚡ Время: 200мс-5с │
└───────────────────────────────────────────────────┘
СЫРЫЕ ДАННЫЕ (циклическая обработка):
┌─────────────────────────────────────────────────────────┐
│ Тот же месяц: 1000 поездок │
├─────────────────────────────────────────────────────────┤
│ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌─────┐ │
│ │П1│ │П2│ │П3│ │П4│ │П5│ ... │П1000| │
│ └─┬┘ └─┬┘ └─┬┘ └─┬┘ └─┬┘ └─┬───┘ │
└───┼────┼────┼────┼────┼────────┼────────────────────────┘
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────┐
│ ЦИКЛ ОБРАБОТКИ │
│ FOR каждая_поездка: │
│ • Получить из базы данных │
│ • Извлечь данные для скоринга │
│ ⚠️ Время: 5с-5мин (в 100+ раз медленнее) │
└─────────────────────────────────────────────────────┘Рекомендуемый алгоритм работы
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ Шаг 1: Обзор │ │ Шаг 2: Фильтр │ │ Шаг 3: Детали │
│ автопарка │───▶│ активных ТС │───▶│ по активным │
│ │ │ │ │ ваучерам │
│ GetVoucherTable │ │ deviceStatus=2 │ │ GetSummingDay/ │
│ │ │ anomalySeverity<4│ │ GetSummingPeriod│
└─────────────────┘ └──────────────────┘ └─────────────────┘
│ │ │
▼ ▼ ▼
Все ваучеры Только активные Только нужные
+ статусы ваучеры данные
+ аномалии (экономия времени 50-70%) Шаг 1: Получение обзора автопарка
Начните работу с запроса общей информации по всем ваучерам:
Базовый табличный запрос
curl -X GET "https://dev.api.exodrive.ai/api/v2/Voucher/table?Page=1&PerPage=100" \
-H "Authorization: Bearer YOUR_TOKEN"Пример ответа:
{
"total": 150,
"items": [
{
"voucherObjectId": "voucher123",
"voucherNumber": 12345,
"deviceStatus": 2,
"contractStatus": 1,
"score": 78.5,
"anomalySeverity": 0,
"anomalyCode": 0,
"isActiveAnomaly": false,
"vehicleRegNumber": "A123BC45"
}
]
}Шаг 2: Фильтрация активных ваучеров
Сохраните полученные данные на время сессии и отфильтруйте:
// Пример фильтрации активных ваучеров без критических проблем
const activeVouchers = voucherData.items.filter(voucher =>
voucher.deviceStatus === 2 && // Активирован
voucher.contractStatus === 1 && // Договор открыт
voucher.anomalySeverity < 4 && // Нет критических и серьёзных аномалий
!voucher.isActiveAnomaly // Нет активных аномалий
);Шаг 3: Запрос детальных данных
Только для отфильтрованных ваучеров запрашивайте детальные данные:
# Для каждого активного ваучера
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=30" \
-H "Authorization: Bearer YOUR_TOKEN"
# Найти нужную дату/период в ответе по полям day/month/yearФильтрация на клиенте:
// Определяем календарный период (последние 7 дней)
const endDate = new Date();
const startDate = new Date();
startDate.setDate(endDate.getDate() - 6); // 7 дней включая сегодня
// Функция проверки вхождения в период
function isInWeekPeriod(item) {
...
}
// Получили данные от API (последние 10 дней активности для перекрытия)
const response = await api.get('/StatisticSummingDay?voucherId=voucher123&daysCount=10');
// Фильтруем только дни, входящие в нужную календарную неделю
const weekData = response.items.filter(isInWeekPeriod);
// weekData теперь содержит только те дни из последних 10 активных,
API вернул 10 дней активности: [07.08, 05.08, 04.08, 02.08, 01.08, 30.07, 28.07, 27.07, 25.07, 24.07]
Календарная неделя: 01.08 - 07.08
После фильтрации: [07.08, 05.08, 04.08, 02.08, 01.08] (5 дней)
Отброшены: [30.07, 28.07, 27.07, 25.07, 24.07]Преимущества такого подхода:
- Исключаете бессмысленные запросы по неактивным ваучерам
- Избегаете проблем с ваучерами, имеющими критические аномалии устройств
- Сокращаете количество запросов в 2-3 раза
Схема выбора эндпоинта
┌─────────────────────┐
│ Какая задача стоит? │
└──────────┬──────────┘
│
┌──────────────────────────────┼──────────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│Обзор парка │ │Долгосрочная │ │Отчёты по │
│(статусы + │ │аналитика │ │водителю/ │
│превью) │ │по парку │ │ваучеру │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌─────────────┐
│GetVoucherTable| │> 6 месяцев? │ │Регулярные │
│ │ │GetSummingMonth| │смены/дни? │
│⚡ 1-5с │ │⚡ 200мс-2с │ │GetSummingDay│
└───────────────┘ └──────┬────────┘ │⚡ 100мс-5с │
│ └──────┬──────┘
▼ │
┌─────────────┐ ▼
│1-30 дней? │ ┌─────────────┐
│GetSummingDay│ │Нестандартные│
│⚡ 100мс-5с │ │периоды/ │
└─────────────┘ │смены? │
│GetSummingPeriod
│⚠️ 5с-5мин │
└──────┬──────┘
│
▼
┌─────────────┐
│Глубокая │
│интеграция? │
│(собственная │
│агрегация) │
│Гибридно:
|GetSummingPeriod
│+ GetSummingDay
└─────────────┘Получение превью-скоринга
Для одного ваучера
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingGlobal?voucherId=voucher123" \
-H "Authorization: Bearer YOUR_TOKEN"Пример ответа:
{
"voucherId": "voucher123",
"totalDays": 45,
"score": 78.5,
"totalDistanceSum": 2150.3,
"totalTimeRunningSum": 152400
}Для всего автопарка
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingGlobal/table?Page=1&PerPage=100" \
-H "Authorization: Bearer YOUR_TOKEN"Преимущества массового запроса:
- Один запрос вместо сотен отдельных
- Ускорение в 100+ раз
- Целостность данных в одной транзакции
Получение агрегированных данных
Данные по месяцам
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingMonth/all?voucherId=voucher123" \
-H "Authorization: Bearer YOUR_TOKEN"Пример ответа:
{
"items": [
{
"scoring": 82.3,
"totalDistance": 3250.7,
"totalHoursRunning": 142.5,
"month": 12,
"year": 2023,
"stdRegularity": 85
}
]
}Данные по дням
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=30" \
-H "Authorization: Bearer YOUR_TOKEN"Запрос за конкретный период
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=7&skipDaysCount=2" \
-H "Authorization: Bearer YOUR_TOKEN"С включением рекомендаций
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=30&includeRecommendations=true" \
-H "Authorization: Bearer YOUR_TOKEN"Пример ответа:
{
"items": [
{
"scoring": 85.2,
"totalDistance": 145.7,
"totalHoursRunning": 8.5,
"unixTimeDay": 1704067200,
"day": 1,
"month": 1,
"year": 2024
}
],
"recommendations": {
"totalPotentialImpact": 12.5,
"overallPercentile": 65
}
}Получение данных по произвольным периодам
Подготовка временных меток
Используйте Unix timestamp в UTC:
// JavaScript пример
const from = Math.floor(new Date('2024-01-15T08:00:00Z').getTime() / 1000); // 1705305600
const to = Math.floor(new Date('2024-01-15T20:00:00Z').getTime() / 1000); // 1705348800Запрос данных за смену
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingPeriod?Id=voucher123&From=1705305600&To=1705348800" \
-H "Authorization: Bearer YOUR_TOKEN"С включением данных об авариях
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingPeriod?Id=voucher123&From=1705305600&To=1705348800&IncludeCrashData=true&IncludeRecommendations=true" \
-H "Authorization: Bearer YOUR_TOKEN"Пример ответа:
{
"scoring": 82.1,
"numBraking": 15,
"numAcceleration": 8,
"numCornering": 22,
"crashData": {
"numCrash": 0,
"numMiniCrash": 1
}
}Практические сценарии использования
Сценарий 1: Дашборд автопарка
Задача: Отобразить карточки всех транспортных средств с базовыми показателями и статусами
# Один запрос для получения полной картины автопарка
curl -X GET "https://dev.api.exodrive.ai/api/v2/Voucher/table?Page=1&PerPage=100" \
-H "Authorization: Bearer YOUR_TOKEN"Время выполнения: 1-5 секунд для 100 ваучеров Результат: Превью-скоринг + статусы + аномалии для каждого ТС
Сценарий 2: Еженедельный отчет по парку
Задача: Построить график скоринга активных автомобилей за последние 7 дней
Временная линия выполнения:
❌ НЕЭФФЕКТИВНЫЙ ПОДХОД:
0с ────┬─── 30с ────┬─── 60с ────┬─── 90с ────┬─── 120с ───┬─── 150с ───┬─── 180с
│GetPeriod │GetPeriod │GetPeriod │GetPeriod │GetPeriod │GetPeriod
│День 1 │День 2 │День 3 │День 4 │День 5 │День 6
▼ ▼ ▼ ▼ ▼ ▼
⚠️ Запрос ⚠️ Запрос ⚠️ Запрос ⚠️ Запрос ⚠️ Запрос ⚠️ Запрос
└─────── 210с: День 7 ──────────┘
▼
⚠️ Запрос
ИТОГО: 3.5 минуты для 1 ваучера
✅ ЭФФЕКТИВНЫЙ ПОДХОД:
0с ────┬─── 1с
│GetSummingDay (daysCount=7)
▼
⚡ Один запрос
ИТОГО: 1 секунда
Ускорение в 210 раз!# Сначала получаем обзор автопарка
curl -X GET "https://dev.api.exodrive.ai/api/v2/Voucher/table" \
-H "Authorization: Bearer YOUR_TOKEN"
# Затем для каждого активного ваучера без критических аномалий:
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=7" \
-H "Authorization: Bearer YOUR_TOKEN"
# Затем для массива дней отфильтровать нужный период, поскольку daysCount возвращает последние данные по количеству дней с данными, а не календарные
Время выполнения: 100мс - 1 секунда на ваучер (только для активных)
Сценарий 3: Анализ конкретной смены
Задача: Детальный разбор использования ТС во время конкретной смены с 09:00 до 18:00
# Предварительно убедиться, что ваучер активен (из обзора автопарка)
# Если за сутки автомобилем управлял только один водитель то запросить скоринг за день
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=7" \
-H "Authorization: Bearer YOUR_TOKEN"
# Если водителей было больше одного, то запросить данные за смену
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingPeriod?Id=voucher123&From=1705305600&To=1705338000" \
-H "Authorization: Bearer YOUR_TOKEN"Время выполнения: 0.5-60 секунд в зависимости от выбора эндпойнта
Сценарий 4: Годовой отчет для страховой компании
Задача: Подготовить детальный отчет об использовании активных ТС за год с разбивкой по месяцам
# Получить список ваучеров со статусами
curl -X GET "https://dev.api.exodrive.ai/api/v2/Voucher/table" \
-H "Authorization: Bearer YOUR_TOKEN"
# Для каждого активного ваучера запросить годовые данные по месяцам
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingMonth/all?voucherId=voucher123" \
-H "Authorization: Bearer YOUR_TOKEN"Время выполнения: 200мс - 2 секунды на активный ваучер
Сценарий 5: Детальный месячный отчет по дням
Задача: Подготовить детальный отчет об использовании ТС за месяц с разбивкой по дням
# Для детальной разбивки конкретного месяца по дням
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=30&includeRecommendations=true" \
-H "Authorization: Bearer YOUR_TOKEN"Время выполнения: 1-5 секунд на активный ваучер
Правила работы с временными форматами
Unix Timestamp (для периодных запросов)
// Начало дня в UTC
const startOfDay = new Date('2024-01-15T00:00:00Z').getTime() / 1000; // 1705276800
// Конец дня в UTC
const endOfDay = new Date('2024-01-15T23:59:59Z').getTime() / 1000; // 1705363199Учет часовых поясов
// Конвертация из MSK в UTC
const moscowTime = new Date('2024-01-15 09:00:00'); // Местное время
const utcTimestamp = Math.floor(moscowTime.getTime() / 1000) - (3 * 3600); // MSK = UTC+3Типичные ошибки и их решения
Ошибка 1: Запрос каждой смены отдельно для автомобиля с одним водителем
❌ НЕЭФФЕКТИВНО: 30 отдельных запросов
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Смена 1 │ │ Смена 2 │ │ Смена 3 │ ... │Смена 30 │
│ 3с │ │ 5с │ │ 6с │ │ 4с │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
│ │ │ │
└───────────┼───────────┼───────────────┘
▼
Общее время: 1-5 минут
✅ ЭФФЕКТИВНО: 1 запрос за месяц
┌─────────────────────────────────────────────────┐
│ Месяц данных │
│ 1-5с │
└─────────────────────────────────────────────────┘
│
▼
Ускорение в 100+ раз❌ Неэффективно:
# 30 запросов для 30 ежедневных смен одного ТС
for day in range(30):
GET /api/v2/StatisticSummingPeriod?Id=voucher123&From=shift_start&To=shift_end✅ Эффективно:
# Один запрос за месяц использования
GET /api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=30Пояснение: Если вам нужны данные за регулярные смены (например, ежедневные смены с 9:00 до 18:00, или с 9:00 до 8:59 следующего дня), используйте дневные агрегаты. Система использует батч-обработку для агрегированных данных, что на несколько порядков быстрее циклической обработки каждой поездки отдельно. Период-эндпоинт нужен только для анализа нестандартных временных рамок или коротких периодов, когда использовать другие эндпойнты не представляется возможным.
Ошибка 2: Запросы слишком коротких периодов
❌ Неправильно:
# Запрос данных за 30 минут
GET /api/v2/StatisticSummingPeriod?Id=voucher123&From=start&To=start+1800✅ Правильно:
# Минимум 1 час активной езды для корректного скоринга
GET /api/v2/StatisticSummingPeriod?Id=voucher123&From=start&To=start+3600Пояснение: Скоринг требует достаточной экспозиции для нормирования показателей. Короткие поездки не дают статистически значимых результатов - система не может корректно рассчитать качество вождения.
Ошибка 3: Неправильные временные зоны
❌ Неправильно:
# Местное время без конвертации в UTC
GET /api/v2/StatisticSummingPeriod?From=1672534860&To=1672621260✅ Правильно:
// Конвертация в UTC перед отправкой
const utcFrom = localTimestamp - timezoneOffsetSeconds;Ошибка 4: Использование период-эндпоинта для долгосрочной аналитики
❌ Неэффективно:
# Период-эндпоинт для месячного отчета
GET /api/v2/StatisticSummingPeriod?From=monthStart&To=monthEnd✅ Эффективно:
# Дневной эндпоинт для месячного отчета
GET /api/v2/StatisticSummingDay?voucherId=voucher123&daysCount=30Пояснение: Период-эндпоинт обрабатывает каждую поездку в цикле и предназначен для коротких периодов с точными временными рамками. Для анализа за недели/месяцы всегда используйте соответствующие агрегаты, которые обрабатываются батч-операциями и доступны мгновенно.
Оптимизация производительности
Кэширование на стороне клиента
// Пример простого кэширования
const cache = new Map();
async function getScoringData(voucherId, days) {
const cacheKey = `${voucherId}_${days}`;
if (cache.has(cacheKey)) {
return cache.get(cacheKey);
}
const data = await api.get(`/StatisticSummingDay?voucherId=${voucherId}&daysCount=${days}`);
cache.set(cacheKey, data);
return data;
}Пагинация для больших автопарков
# Обработка автопарка частями по 100 ваучеров
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingGlobal/table?page=1&perPage=100" \
-H "Authorization: Bearer YOUR_TOKEN"Фильтрация данных
# Фильтрация по конкретным ваучерам
curl -X GET "https://dev.api.exodrive.ai/api/v2/StatisticSummingGlobal/table?Filter=voucherNumber~contains~ABC" \
-H "Authorization: Bearer YOUR_TOKEN"Возможные ошибки
- Таймаут запроса - используется неподходящий эндпоинт для объема данных
- Неверный формат времени - не учтен часовой пояс или неправильный формат timestamp
- Превышение лимитов запросов - слишком частые обращения к API
- Неполные данные - запрос слишком свежих данных, которые еще не обработались
- Ошибки валидации - некорректные параметры периода (From > To)
Мониторинг и метрики
Рекомендуемые метрики для отслеживания:
- Время отклика: < 5 секунд для дневных данных, < 2 минут для периодных
- Частота запросов: Не более 60 запросов в минуту для одного ваучера
- Успешность запросов: > 95% успешных ответов
Признаки неэффективного использования:
- Время отклика > 5 минут
- Частые ошибки 429 (Too Many Requests)
- Множественные запросы с перекрывающимися периодами
Примечания
- Агрегированные данные (любые) обновляются моментально при получении "отстающих" данных от устройства
- Для периодных запросов минимальный период должен составлять не менее 1 часа
- Данные за текущий день могут быть неполными до окончания суток
- При работе с большими автопарками используйте фильтрацию и пагинацию
- Всегда передавайте время в UTC для избежания ошибок с часовыми поясами