Basic scenario
Let's walk through the basic scenario of integrating with the LSS.Monitor service and working with it operationally.
All methods and operations described below are available both through the API and in the web interface of the platform.
Ready-made wave datasets for checking individual capabilities of the service are collected in the Examples section.
Step by step
Prerequisites
Authorization
To perform any requests to the service, you must first generate an access token through the authorization service.
Creating crews
To sign in to the mobile application, you need to create crews - accounts with limited access permissions.
Creating crews requires the CREWMANAGER role.
Crews are created once and can then be reused many times in different planning waves.
You can add crews in two ways:
Planning
Before starting monitoring, you have to calculate the trips using the Universal service.
-
Run planning for your dataset.
-
Build a dataset from the planning source data and the trips to upload it into Monitor.
Data import
To import a dataset, follow these steps:
-
Create a folder using the create a new folder method.
-
Create a wave inside this folder using the create a file method.
-
Upload the dataset into the created wave using the data import method.
An example of how the folder and file structure can be organized:
├── Leningrad Region
└── Moscow Region
├── 2026-01
├── 2026-02
├── 2026-03
└── 2026-04
├── 23
│ ├── 08:00
│ ├── 12:00
│ ├── 16:00
│ └── 20:00
├── 24
│ ├── 08:00
│ ├── 12:00
│ ├── 16:00
│ └── 20:00
└── ...
Launching trips
To launch a trip, follow these steps:
-
To assign a crew to a trip, you need to create a deal.
-
Once the crews are distributed, launch the trips into work. You can launch either all trips of the wave or select them one by one.
-
To process facts and replan trips automatically, you need to enable the autopilot.
Trip execution
This is the active phase of the work, when the crews are already on their routes. Trip execution is built on close interaction between the performer's mobile application and the Monitor server side.
The execution of the launched trips is split into several key stages:
-
The performer signs in to the mobile application; after signing in, the list of active deals (trips) assigned to them becomes available automatically. All received trips change their status to
TRIP_RECEIVED. -
The performer confirms readiness for the trips by moving them to the
TRIP_CONFIRMEDstatus (readiness can be confirmed for several trips at once). When the driver actually starts moving, they take a specific trip into work by moving it to theTRIP_EXECUTINGstatus.
Important: only one trip can be in work (TRIP_EXECUTING) at any given moment.
For the active trip, the application starts recording facts continuously and sending GPS coordinates to the Monitor server to track the geoposition.
-
At every stop, the performer records the order events in the application, which sends them to the Monitor server. The data passed to the system covers the start of the work, the order status (completed/cancelled) and payment acceptance.
-
The work of the Monitor server side. While the work is in progress, the autopilot is called periodically. It matches the planned arrival times at a stop against the actual GPS data and the performer's marks on the orders. After every recalculation, the system updates the estimated time of arrival (ETA) at the following stops, rebuilds the route to minimize delays, and passes the corrected data back to the driver's application and to the logistician's web interface.
-
All the data on how the route was passed, stored on the Monitor server, becomes available for import into your company's internal accounting system through the integration module.
Retrieving performers' results
While the tasks are being executed, the system continuously accumulates actual data from the performers' mobile applications.
This data is needed to upload the work results into the internal accounting master system.